From PostHog Signups to Stripe Revenue: What You Can and Cannot Connect

The clean answer to which channel brings paying customers needs a user ID on both sides. Without one, you can still answer most of it, honestly, by month and by channel.

To connect PostHog signups to Stripe revenue, compare them at the same grain, by calendar month and by acquisition channel, since a per-user join needs a shared ID that these two sources usually do not give you. PostHog supplies signups, paid signups and the first-touch channel by signup cohort; Stripe supplies new MRR and new subscriptions by month. Allow for the lag between signup and first payment, reconcile the two paid counts, and treat any revenue-by-channel figure as an estimate. Quiriz reads both sources, which are in beta, and answers each at that grain. It does not link individual people.

The problem: two systems, no shared key

Product analytics knows who visited, signed up and did what. The payment system knows who paid, how much, and when. The question that joins them, which channel brings customers who actually pay, sounds simple. It is simple when every paying customer can be traced to the person who signed up, through a user ID stored in both systems.

Many teams do not have that, or have it only for some customers. The honest options are then to set up the shared ID going forward, which is the right long-term fix, or to answer at a coarser grain from what each system holds. This post is about the second option, which is available today.

What each side exposes

From PostHog, through Quiriz: the [PostHog] Signup cohorts dataset has one row per signup week and first-touch channel with signups, people who activated within 7 days, people who did the paid event, weeks observed, and retention counts. The paid event is the one you choose in the connector's Events panel; the PostHog paid signups metric counts cohort members who ever did it. The connector copies no events, people or identifiers.

From Stripe, through Quiriz: payments, balance transactions, subscriptions, invoices, MRR by month, and customers. The metrics include MRR, New MRR (by month-end, from subscriptions paying for the first time), expansion, contraction and churned MRR. The customer dataset carries name and country, with no email, phone or address, and Stripe has no channel field.

So the shared dimensions are time, and nothing else. Channel exists only on the PostHog side. That shapes the method.

Step one: signups to new revenue by month

Sum PostHog cohort signups by calendar month, and put Stripe new MRR and the number of new subscriptions beside them. An illustration with made-up numbers:

Read across, not down. New MRR per new subscription is about $70 each month. Paid signups run close to new subscriptions, which is reassuring. September's gap, 31 against 36, is the kind of thing to investigate rather than average away.

Step two: the lag

People who signed up in August may pay in September. If your product has a trial, the month-by-month ratio of new subscriptions to signups will wobble because of timing alone. Two practical remedies: compare signups with new subscriptions in the same month and the following month, and use the PostHog paid signups cohort figure, which attaches the payment to the signup week, as the cleaner conversion rate. The PostHog paid conversion rate metric (paid signups over cohort signups) is that figure. Remember that recent cohorts are still maturing, so the newest weeks will understate it.

Step three: reconcile the counts

The PostHog paid count and the Stripe new subscription count are measuring the same thing from two sides. Compare them every month. Typical reasons for a gap, each worth checking: the paid event fires on the pricing page click instead of on payment; customers pay without passing through the tracked flow, for example via an invoice; a trial converts months later; a signup came from before the event existed. A gap is information about tracking, and it is better found by a reconciliation than by a board meeting.

Step four: revenue by channel, as an estimate

PostHog gives paid signups by first-touch channel. Stripe gives the average new MRR per new subscription. Multiply them, and you have an estimate of new MRR by channel. An example, again illustrative: if search brought 18 paid signups in a month and the average new subscription was $70 of MRR, the estimate is about $1,260 of new MRR from search.

Say it is an estimate whenever you show it. It assumes every channel's customers pay the same average amount, which is often false: a channel that brings annual-plan customers has a higher average. It also relies on the first-touch channel, which is a rule, not a truth. For a decision on ad spend, pair this with a real cost figure; the customer acquisition cost post covers the arithmetic, and Quiriz for paid media covers the ad side.

How Quiriz answers this

Quiriz is an AI business analyst. The PostHog and Stripe connectors are both in beta, read-only, refreshing daily, and included in paid plans. You ask each source its own question at the same grain:

• Which channel brings the most signups, and which channel converts best? (PostHog traffic and cohorts)
• What percent of signups did the paid event, by signup week and first channel? (PostHog paid conversion rate)
• What was New MRR each month this year, and how many new subscriptions? (Stripe)

The answers show their sources and filters, so a reader can see that the channel split came from PostHog and the dollars from Stripe. An admin can define a shared metric such as new MRR per new subscription once in Company Context, so the estimate is calculated the same way for everyone. Stripe's home-currency flag matters here: amounts in other currencies are not converted, so do not add currencies together.

Limits

• No per-person join. PostHog copies no person identifiers and Stripe customers carry no email, so Quiriz cannot say which person from which channel paid.
• Channel is a PostHog dimension only. Stripe revenue has no channel, which is why the channel figure is an estimate.
• PostHog cohorts cover the last 26 weeks, and the traffic window is 13 months, so older cohorts are out of range.
• Immature cohorts understate paid conversion. Wait for them to age before judging them.
• Cookieless PostHog projects give approximate counts, and the signup and paid columns are zero until the events are chosen.
• The durable fix is a shared ID. If you can add the user ID to Stripe metadata or the Stripe customer ID to PostHog, do it, and the per-customer question becomes answerable at the source.

For the related question on the marketing-site side, see PostHog AI, and for how definitions drift between teams, why AI gives different numbers.

Frequently asked questions