What replaced PostHog Revenue Analytics after its deprecation?

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

Nothing "replaced" PostHog Revenue Analytics in the sense of a single successor product — PostHog changed how the feature is packaged and positioned, and most founders who relied on it moved the revenue side of their tracking to the source of truth (Stripe or RevenueCat) and kept PostHog for product analytics only. The practical fix is to stop asking PostHog to be your billing dashboard and let it do what it's good at: events, funnels, and behavioral analytics.

If you landed here because a PostHog dashboard you built stopped updating or the numbers look off, this post walks through why that happened and what to do about it.

What actually changed with PostHog Revenue Analytics

PostHog built Revenue Analytics as a way to pull Stripe (and later other billing) data into the same interface as your product events, so you could see MRR, churn, and revenue trends next to sign-ups and feature usage without leaving PostHog. That's a genuinely useful idea — revenue and behavior in one place.

But PostHog is, at its core, a product analytics and event pipeline company. Revenue tracking has different requirements: it needs to reconcile currencies, proration, refunds, trial conversions, and subscription state changes with the precision billing systems expect, not the sampling and eventual-consistency tolerances that are fine for click funnels. Maintaining that correctly across every Stripe edge case is a full-time job on its own, which is roughly what companies like Baremetrics and ChartMogul exist to do.

So rather than compete head-on as a billing-grade revenue tool, PostHog scaled back Revenue Analytics as a dedicated standalone feature and shifted it toward being a lighter overlay on top of your existing event and (optionally) Stripe data — useful for correlating revenue with product usage, less suited to being your primary source of MRR truth. If you were using it as your only revenue dashboard, that's the gap you need to fill.

The three realistic replacements

1. Go back to the source: Stripe or RevenueCat directly. If your product is web-based and billed through Stripe, Stripe's own reporting (or the Stripe dashboard's revenue recognition views) is the ground truth. If you sell subscriptions through app stores, RevenueCat is the ground truth for entitlements, trials, and cross-platform subscription state. Neither of these needs PostHog in the loop to give you accurate MRR — they're the systems actually processing the transactions.

2. A dedicated subscription analytics tool like Baremetrics or ChartMogul, which read from Stripe (and sometimes RevenueCat) and specialize in exactly the reconciliation problem PostHog stepped back from. These are solid if revenue is your only tracking need and you're running one product. We've written a more detailed comparison in SoleOS vs Baremetrics if you're evaluating that route.

3. A portfolio-level dashboard that pulls from Stripe, RevenueCat, and your analytics tools at once — useful specifically if you run more than one product and don't want a separate revenue tool per app. This is the category SoleOS sits in, and it's worth naming the trade-off honestly: disclosure — this section is written by SoleOS, a company in this space, about its own category.

Why the "product analytics does revenue too" model tends to break down

The deeper issue isn't specific to PostHog. Any tool that's primarily an event pipeline will struggle to keep revenue numbers trustworthy for the same reason spreadsheets do at scale: revenue events are messy. A subscription can be upgraded, downgraded, paused, refunded, and reactivated within a single billing cycle, and every one of those needs to be reflected correctly in MRR, not just counted as a raw event.

If you're already tracking Stripe and RevenueCat together, you've probably noticed the two rarely agree exactly — Stripe reports gross payments processed, RevenueCat reports subscriber-level entitlement state, and reconciling them requires understanding what each number actually measures, not just displaying both. A general-purpose event tool bolting revenue on top adds a third interpretation layer, which is exactly where drift creeps in.

How to decide what to move to

Ask yourself three questions before picking a replacement:

• Do I need revenue and product behavior correlated in one view, or can they live separately? If you genuinely need to see "which cohort came from which feature and how much they're worth," a combined tool matters more. If you mostly need "what's my MRR this month," you don't need that correlation at all.
• Am I running one product or several? A single-product founder is well served by Stripe's native reporting or a tool like Baremetrics. Once you're running 3, 5, or 10 apps, checking a separate dashboard per product for a five-minute revenue glance stops being worth the login overhead — that's the case for a portfolio view, which we go into in real numbers from a 10-app portfolio.
• Do I need this to be free, or is a small monthly cost acceptable for reliability? PostHog's free tier was part of its appeal. If budget is the binding constraint, a spreadsheet fed by CSV exports from Stripe is a legitimate option — see SoleOS vs a spreadsheet for where that stops scaling.

Where you don't need a dedicated revenue tool at all

If you have one product, low transaction volume, and you check revenue less than weekly, Stripe's built-in dashboard is genuinely enough. Don't add a tool — including SoleOS — just because PostHog took something away. The right response to a deprecation is to re-evaluate what you actually need, not to reflexively replace a feature with an equivalent feature elsewhere.

SoleOS makes sense specifically once you're juggling more than one product's revenue and don't want to reconcile Stripe, RevenueCat, and app store payouts by hand across every app. It connects to Stripe, RevenueCat, and other sources read-only, and shows portfolio-wide MRR alongside product analytics without asking you to trust a single event stream for both. You can see how it lays that out in the live demo with sample data, no sign-up needed. Pricing and plan sizes (by number of connected projects) are on the pricing page.

Frequently asked questions

Is PostHog Revenue Analytics completely gone?

No — PostHog didn't remove Stripe or billing integrations outright, but it de-emphasized Revenue Analytics as a standalone, billing-grade feature. Check PostHog's current docs for the exact state of the feature in your account, since product packaging changes over time and this post isn't a substitute for their release notes.

Can I still use PostHog for revenue tracking at all?

You can still correlate revenue-adjacent events with product usage in PostHog if you're piping that data in yourself, but for anything you'd report as official MRR or use for financial decisions, treat Stripe or RevenueCat as the source of truth and use PostHog for behavioral analysis around it.

Does switching mean I lose my PostHog event history?

No. Moving your revenue tracking elsewhere doesn't affect your PostHog project or event data — you're just changing where you look for MRR and churn numbers, not removing PostHog from your stack.

What's the fastest way to check if my Stripe and RevenueCat numbers already disagree?

Pull MRR from both for the same month and compare. Differences usually come from Stripe counting gross charges versus RevenueCat tracking active entitlements — see the metrics dictionary for exact formula definitions if you want to know which number a given dashboard is actually showing you.

Is a portfolio dashboard overkill if I only run one or two apps?

For one app, probably — Stripe's dashboard or RevenueCat's charts cover most needs. Once you're regularly logging into two or more separate revenue dashboards to get a full picture, that's usually the point where a combined view starts saving more time than it costs.