Churn: Why Most Teams Get It Wrong - Issue 292
How to build accurate churn reporting for your product, plans, and revenue model.
I wrote on churn earlier (The Ultimate Guide On Churn Reporting (And Its Technicalities)), but I need to bring it up again because almost no one gets it right. And I’m not just talking about data or analytics engineers who typically have no concept of recurring billing or product abandonment (and ironically are responsible for your reporting). The bigger issue is the tools themselves.
Most subscription platforms misreport churn. Every tool provides a generic churn metric meant to work for SaaS, enterprises, big and small B2B, products with subscriptions, ads, and one-off transactions. And that’s exactly why it breaks.
Here’s the churn report from RevenueCat, for example:
And here’s the real churn rate for the same app:
Same story with Chargebee, ChartMogul, Recurly, and Baremetrics (I’ve had the pleasure of fixing reporting after all of them). It’s not that these tools misread your data or can’t segment it correctly. They’re built to deliver a one-size-fits-all churn number (unless you have an exclusive plan with them, allowing customizations).
You have to make a call whether to trust that plug-and-play metric and bet your growth and budget on it, or build something accurate in-house - something designed for your product, your subscription plans, your grace periods, and your trials.
Below, I’ll recap how to approach churn reporting, how to work with churn vendor data, and how to know your churn data is accurate.
Making sense of vendor data
I want to be clear: I’m not saying you shouldn’t use tools like Chargebee (though this one I personally wouldn’t), Baremetrics, or ChartMogul. Most of them are solid and genuinely helpful. I rely on RevenueCat data every day, and their scheduled exports are often the main source of my reporting. I use ChartMogul in my data audit a lot, and I also like Baremetrics subscription reports.
The issue is that data reporting is not the primary feature of these tools. Their dashboards are add-ons, not analytics platforms. We should treat them that way, instead of opening support tickets every time a number looks off in a freemium UI.
Depending on your product, you may not want to ingest Apple Pay, Google Play, Stripe, and PayPal data yourself or run servers to capture and store every event. That’s expensive to store and maintain. But at the same time, proper analytics requires more than aggregated totals with no user_id - this is exactly what payment stores deliver via API by default.
This is where subscription tools help. They process payment-store data for you, consolidate it, map it to a user, segment it, and send it back in a clean, consumable format. They do the heavy lift, and it’s great that we can take advantage of it.
What you should do is own the metric definitions inside your database, built on top of the raw ingested data from these tools. What you build might not match their dashboards, and that’s fine. But it lets you narrow TTP (Trial-to-Paid) to your actual trial length (which they can’t do), segment subscriptions across all 20 plans you offer (which they do poorly, especially if you use Stripe), and exclude lifetime plans or free offers from ending contracts, so your retention is accurate.
Building churn reporting the right way
The hardest part of building an accurate churn metric is deciding what it’s for. Making it timely and actionable is one thing. Using it for benchmarking is completely different.
You will need to develop 2-3 variations of the same KPI:
Churn for the board and executives for benchmarking.
Churn for leadership to develop a strategy and run forecasts.
Churn for product and marketing teams to act on and measure their initiatives against.
The logic, formulas, and calculations behind these 3 are not the same. Vendor dashboards usually give you something close to #1. That’s what they use for their monthly and quarterly benchmark reports.
But what you actually need is #2 and #3 - and you need them to be as close to each other as possible.
💡I often notice how people share their preference for the “right” KPI calculation and debate which one is more accurate or appropriate - for example, bounded or unbounded retention, excluding new users from DAU or including them, excluding trials from churn rate, or including them. The truth is that we need all of these KPI variations for different use cases.
1. Churn for benchmarking:
Metric: A simple consolidated blended churn, merging all plans and reflecting your overall loss this month, one for revenue and one for customers.
Report frequency: Monthly and quarterly.
This is exactly what subscription tools do.
For example, here is RevenueCat’s churn formula:
([Churned Actives] / [Actives]) × 100 = Churn Rate
The problem is that not all “Actives” are actually “Ending.” RevenueCat notes that Ending customers differ from Beginning customers, but they don’t remove from the Ending group the customers who aren’t up for renewal this month. That means the denominator includes subscriptions that won’t expire and can’t expire, which artificially lowers the churn rate.
That’s one issue. Another is plan migration. If a customer switches plans, many tools count the original plan as “churned,” even though the user is still paying under a different plan. This inflates the churn, and so on.
What you should do instead is narrow “active customers” to only those who are actually up for renewal this month. Exclude new subscribers (they can’t renew) and include only monthly plans plus the small slice of 3-month, 6-month, and annual plans that expire this month. That group becomes your denominator. This is the only way your blended churn rate will be accurate.
