How to see which product behaviors lead to paid customers with PostHog, Stripe

You see which product behaviors lead to paying customers by putting two records side by side: what each person did in your product, which PostHog holds, and whether that person paid, which Stripe holds. PostHog stores every event your product sends, such as a project created or a teammate invited, against a person with their properties and distinct IDs. Stripe stores each customer with their email, metadata, subscriptions, invoices, and charges. Once each PostHog person is linked to the right Stripe customer, you can compare the people who paid with the people who didn't and look for the actions that separate them.

PostHog offers two built-in routes. First, its data warehouse can import your Stripe account, so customers, subscriptions, invoices, and charges become tables you can query next to your events with SQL. PostHog can tie those Stripe customers to people when your app saves the PostHog distinct ID in the Stripe customer's metadata. Second, if your product already sends a payment event into PostHog, such as "subscription started", you can build a funnel that ends on it and turn on correlation analysis. PostHog then lists the events and person properties most associated with reaching that step or dropping off before it.

Both routes give you the data, but neither one decides which behaviors deserve your attention. Correlation analysis ranks everything that travels with payment, and much of it comes after payment or because of it. Inviting a teammate may be the top result simply because only paid plans allow invites. Visiting the billing page is near the top because everyone who pays visits it. A rare event that ten people did can show a huge effect by chance. None of these tells you what to put in front of new users next week.

That's the real work in this job. A good result is a short list of actions that people took before paying, early enough that you could steer new users toward them. Each action should be common enough to matter, and it should hold up across signup months and channels. It should also come with plain numbers: how many signups did it, what share of them paid, and what share of everyone else paid.

Kite does this work for you. It links your PostHog people to your Stripe customers, decides who really paid and when, and compares what payers and non-payers did before that moment.

Start by asking Kite what your paying customers did first:

"Which things do people do in the product in their first two weeks that make them more likely to pay in Stripe?"

Kite is an AI marketer. It researches your business, builds a growth strategy, and ships the work that brings you new customers. By the time you ask, it already knows your plans, your pricing, whether you offer a free plan or a trial, and which features each plan includes, from its research on your business. That lets it propose the signup period, the early window to study, and what counts as a paying customer without a long brief. Confirm the plan or adjust it, and Kite starts.

You'll need to connect two accounts. Connect PostHog through OAuth and choose the project that holds your product events. Connect Stripe through OAuth so Kite can read your customers and their payments. If you'd also like the Stripe data inside PostHog for your own charts, Kite can set up PostHog's Stripe import and sends you a secure link to authorize it.

This job reads from both tools. Kite runs the analysis and posts what it found, and it doesn't change any billing records. It saves the charts and cohorts it builds in PostHog so your team can open them.

Kite starts in Stripe, because the date of each person's first real payment decides which of their behavior counts. It reads your customers, subscriptions, invoices, and charges, and it counts a customer as paying only when Stripe shows real money changing hands. For a subscription, that's an invoice with a paid status and a total above zero. For a one-time purchase, it's a successful charge or a completed checkout session that wasn't fully refunded.

Several things look like payment without being one, and Kite keeps them out:

• A subscription that is still in its trial
• An invoice covered entirely by a 100 percent discount coupon
• A charge that was fully refunded
• A failed payment, even if a retry is still pending

For each paying customer, Kite records the first payment date, the plan and price, and the amount. It reads trial dates to learn your trial length, which helps it choose a fair window later.

Kite links people using the most reliable identifier your two tools share. It reads the metadata on Stripe customers and the client reference ID on checkout sessions to see whether your app saves a PostHog distinct ID or your own user ID there. When it does, Kite matches on that ID directly. When there's no shared ID, it matches the email on the Stripe customer with the email property on the PostHog person, treating addresses that differ only in capital letters as the same.

Email matching has gaps, and Kite handles the common ones. One person can end up as several Stripe customers after starting checkout twice, so Kite groups those under the one PostHog person. Some people pay with a company billing address instead of their signup email. When a Stripe customer shares a company domain with an unmatched PostHog person from the same period, Kite lists the pair as a possible match for you to confirm, and it leaves the pair out of the count until you do.

Kite also removes people who would distort the comparison. It leaves out PostHog's test accounts, signups from your own company's email domain, Stripe test-mode customers, and any staff accounts you name. It tells you what share of paying customers it linked, because that share decides how much the results can say.

Kite chooses candidate behaviors from the events your product already tracks in PostHog, and it leaves out the ones that can't explain payment. It reads your event definitions and properties and the actions your team has defined, then sorts them into three groups.

• Meaningful product actions. These are the steps where someone gets value, such as creating a first project, connecting a data source, publishing something, or inviting a colleague on a plan that allows it. Kite tests these.
• Actions only paid plans allow. Kite matches events to the features in each plan from its research and from your Stripe products and prices. A behavior that's locked behind payment can't cause payment, so Kite leaves it out or tests only the attempt, such as clicking a locked feature.
• Steps in the payment itself. Visiting the billing page, opening checkout, and entering a card are part of paying, not a reason for it. Kite keeps them out of the candidate list.

Kite also tests how often and how soon, not just whether. Someone who created three reports in their first week may pay at a very different rate from someone who created one, and someone who connected a data source on day one may differ from someone who did it on day ten. When raw autocaptured clicks are all you have, Kite can define a PostHog action that turns a specific click or pageview into a named event, so the behavior can be counted.

Kite compares everyone who signed up in the same period, and it counts only what each person did in the same early window after signup, before any payment. A window such as the first 14 days keeps the comparison fair. A person who signed up last week hasn't had the same chance to act or pay as someone who signed up in June, and a payer's behavior after paying says more about the paid plan than about what led to it.

Kite chooses the window from your trial length and from how long your paying customers actually took to pay. If most paid within a week, a seven-day window captures the behavior that came first. If many paid after a month, Kite uses a longer window and checks the results at more than one length.

For each candidate behavior, Kite queries your PostHog events with SQL and works out these numbers:

• How many signups did it within the window, as a count and a share
• The share of those people who went on to pay
• The share of everyone else who went on to pay
• How long payers typically took to reach the behavior, and how long from there to their first payment

The gap between those two paid rates is what matters, together with how many people the behavior covers. An action that 60 percent of signups take and that doubles the paid rate is worth more attention than one that triples it for a handful of people. When a behavior has too few people behind it to trust, Kite says so instead of ranking it.

Kite checks each promising behavior against the explanations that could fake it. It repeats the comparison for each signup month, so a pattern that appeared only during one launch doesn't pass as a habit. It splits the results by the UTM source and campaign PostHog recorded at signup, because a behavior can look powerful when it really just marks people from a channel that sends better buyers. Where your PostHog persons carry properties such as company size or role, it checks those too.

The result is still a pattern, not proof that the behavior causes payment. Kite labels it that way and tells you which behaviors are strong enough to test. The test is to push more new users toward the action and see whether more of them pay.

When the analysis is done, Kite posts a summary in the conversation where you asked, in the Kite web app or in Slack. It names the few behaviors that most separate payers from everyone else, gives the two paid rates and the share of signups behind each one, and says how many days in payers usually reach it. It also says what share of Stripe customers it linked to PostHog and which behaviors it left out and why. The full table comes with the summary, and when the results need more room, Kite can publish them as a report with charts you can share by link.

Kite also leaves the work where your team already looks. It saves the funnels and charts it built as PostHog insights on a dashboard. It creates a static cohort of the paying customers it linked, so anyone on your team can break down a PostHog chart by who paid. It creates a dynamic cohort of recent signups who haven't reached the key behavior yet, which updates on its own as people join and act.

That cohort is where the next piece of work starts. Kite can write the onboarding emails and in-app copy that point new users toward the behavior, or set up a PostHog experiment that tests a change to onboarding, and it asks for your approval before anything reaches real users. If your team wants to know when a free user reaches the behavior, Kite can watch for it in PostHog and tell you. To keep the findings current, ask Kite to run the analysis every month, and it will post each new report where you choose.

When Kite finishes, you have a short, ranked list of the early product behaviors that set paying customers apart, with the numbers behind each one and cohorts your team can act on.