Combining PostHog analytics with Stripe revenue, properly

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

The fastest way to combine PostHog and Stripe is to join them on a shared key — usually the customer's email or a user ID you pass into both systems — then look at behavior and revenue side by side instead of merging raw data. For most solo founders, that means either using PostHog's own Stripe data warehouse integration for deep event-level joins, or pulling both into a lightweight metrics layer for a portfolio-level view. Which one you need depends on whether you're debugging a single product's funnel or trying to see revenue trends across several.

Why PostHog and Stripe don't talk to each other by default

PostHog is an event store: pageviews, clicks, feature flags, session recordings, funnels. Stripe is a ledger: subscriptions, invoices, charges, refunds. They have no native concept of each other. A user in PostHog is identified by a distinct ID you set client-side. A customer in Stripe is identified by a customer ID, usually tied to an email. Nothing forces those two identifiers to be the same person unless you explicitly wire it up at signup — passing the PostHog distinct ID into Stripe metadata, or vice versa, when the checkout session is created.

If you skipped that step (most people do, early on), you can still join after the fact on email address, but it's fuzzier — trial signups, marketing emails, and test purchases all add noise.

Two real options, and when each makes sense

Option 1: PostHog's Stripe integration (event-level, single product). PostHog can pull Stripe data directly and let you build insights that combine product events with subscription status — for example, "retention of users who hit the onboarding checklist vs. users who didn't, split by paying/free." This is the right tool when you're debugging one product's activation funnel and want to know exactly which features correlate with conversion. It requires connecting each Stripe account separately per PostHog project, and it's built for depth on one product, not breadth across many.

Option 2: A portfolio metrics layer (aggregate-level, multiple products). If you're running more than two or three products, you usually don't need per-event joins for daily decision-making — you need to see "which of my seven apps had rising MRR and falling activation last week" without opening seven dashboards. That's a different job: less about individual user journeys, more about spotting which product needs attention this week. This is the layer where a tool like SoleOS sits — it connects to both Stripe and PostHog per project and shows revenue and product metrics next to each other across your whole portfolio, without you writing a join query. Disclosure: SoleOS is our product and this post is written from that angle, so take the framing with that in mind.

Neither option replaces the other. If you need to know why a specific cohort churned, you're back in PostHog with session recordings and funnels. If you need to know which app to spend your Friday afternoon on, aggregate metrics answer that faster than raw events do.

What to actually put side by side

Once you have both sources reachable, the useful comparisons are narrower than people expect:

• Activation rate vs. trial-to-paid conversion. If PostHog says 40% of signups complete your core action but Stripe says only 8% convert to paid, the gap is your pricing or paywall placement, not your onboarding.
• Feature usage vs. plan tier. Are the features you gated actually the ones power users touch, based on session data? If low-usage features are gating your highest-priced plan, that's worth knowing before you rebuild pricing.
• Weekly active users vs. weekly new MRR. These should move together with a lag. If WAU is flat but MRR keeps climbing, you're likely riding expansion revenue or annual renewals, not new adoption — good to know before you assume growth is healthy.
• Churned users' last session vs. cancellation date. A big gap (canceled a month after last login) points to a billing-reminder problem, not a product problem.

For exact definitions of things like activation rate or trial conversion, check the metrics dictionary so you're comparing apples to apples across your own products rather than reinventing formulas per app.

Where the AI layer fits in — and where it doesn't

If you're using an AI summary layer on top of these numbers (SoleOS includes one), it's worth knowing what it can and can't see. In SoleOS's case, the AI provider only receives aggregated project metrics and project names — never raw PostHog events, never Stripe credentials, never end-user identities. That means it can tell you "Product B's MRR grew while WAU declined — check for expansion vs. new signups" but it can't tell you which specific user session caused a bug, because it never sees session-level data. For that kind of debugging you're still in PostHog directly. Details on scope are in how SoleOS uses AI.

When you don't need any of this

If you run one product and check it daily, a native PostHog dashboard with the Stripe integration is genuinely enough — don't add a second tool just to look at the same two numbers from a different angle. Similarly, if you're pre-revenue or pre-signup, there's no revenue data to join yet; focus on the funnel first. And if your portfolio is two apps you can mentally track without a dashboard, a spreadsheet might cover you for another few months before a dedicated layer earns its subscription cost.

The case for a portfolio tool gets stronger as your project count climbs — past four or five active products, manually checking PostHog and Stripe per project starts eating an hour you don't have. That's also roughly when tracking Stripe and RevenueCat together becomes relevant if you sell subscriptions on mobile too.

Frequently asked questions

Can PostHog show Stripe revenue natively?

Yes, PostHog has a data warehouse feature that can sync Stripe data and let you build insights combining product events with subscription and payment data. It works per PostHog project connected to one Stripe account, and is strongest for single-product, event-level analysis rather than portfolio-wide views.

Do I need a data warehouse to join PostHog and Stripe myself?

Not necessarily. For simple joins (e.g., "which paying customers used feature X"), PostHog's built-in Stripe sync avoids needing a separate warehouse. A custom warehouse (BigQuery, Snowflake) makes sense once you need to join many sources — Stripe, PostHog, app store data, ad spend — at the row level, which is a bigger lift than most solo founders need for weekly decisions.

What's the minimum I should track if I only have 20 minutes a week?

MRR and churn from Stripe, plus weekly active users and activation rate from PostHog, per product. Everything else is detail you add once those four numbers raise a question worth chasing.

Does connecting PostHog and Stripe to a third-party tool expose customer data?

It depends entirely on what scopes you grant and what the tool does with the data. Read the specific permissions before connecting — for SoleOS's connectors, the scopes and revocation process are listed at what SoleOS connects to, and the broader approach is in the security overview.

Is a portfolio dashboard overkill if I only run two products?

Often yes. Two products is usually manageable by checking each one's native dashboards directly. The value of a combined view shows up around four-plus active products, when context-switching between tabs becomes the actual bottleneck. You can see the difference in practice in real numbers from a 10-app portfolio.