Why your churn rate is actually 3 different numbers (and how to use each one)
A subscription-app founder asks their team “what’s our churn rate this month?” Three people in the room answer with three different numbers. All three are right. They are also all measuring different things, and choosing the wrong one for a given decision will quietly send the strategy in the wrong direction.
In MENA the gap between these three numbers is wider than in Western markets, because the payment infrastructure is more fragmented and card-decline rates with local banks and processors are structurally higher. A team that reports a single “churn rate” without saying which one is hiding meaningful information from itself.
Here are the three churn rates that matter, what each one is for, and the MENA pattern that makes them diverge.
1. Customer churn (count-based)
What it measures: the percentage of paying customers who cancelled in a period.
Formula: (customers lost during period) / (customers at start of period)
What it’s for: intuitive board reporting, product-quality questions (“are users leaving the product itself?”), and headline retention storytelling.
What it misses: customer churn treats a user paying $99/month and a user paying $9.99/month identically. If your high-LTV users churn at a different rate than your low-LTV ones — and they almost always do — customer churn will mislead you about the revenue impact.
A 5% customer churn rate can hide a 12% revenue churn rate if your churning customers are disproportionately your high-value ones, or a 2% revenue churn rate if your churning customers are mostly entry-tier. The number alone, without the revenue split, is not enough to act on.
2. Revenue churn (MRR-based)
What it measures: the percentage of monthly recurring revenue lost in a period, before counting any expansion.
Formula: (MRR lost from cancellations and downgrades) / (MRR at start of period)
What it’s for: financial forecasting, board-pack revenue projections, LTV calculations, and any decision that involves money rather than headcount.
What it misses: revenue churn does not distinguish between “users decided to cancel” and “their card got declined and we couldn’t recover it.” Both reduce MRR. But they have very different operational interpretations — one is a product or pricing problem, the other is a payment infrastructure problem.
This is especially true in MENA because of the next number.
3. Involuntary churn (payment-failure-based)
What it measures: the percentage of MRR lost specifically because a renewal payment failed and could not be recovered through retries — separate from users who actively decided to cancel.
Formula: (MRR lost to failed/declined renewals after retry windows) / (MRR at start of period)
What it’s for: payment infrastructure decisions, processor and retry-policy tuning, and isolating “real” churn (users leaving on purpose) from “operational” churn (users leaving by accident).
Why it matters more in MENA: card-decline rates on subscription renewals are materially higher with Iyzico-processed Turkish cards, with Egyptian-issued cards on international rails, and with Mada-issued Saudi cards routed through international processors than they are with US-issued cards on Stripe. We see involuntary churn run 1.5 to 3x the global baseline in MENA subscription apps with default retry settings.
A MENA subscription app with 8% revenue churn might be running 3% voluntary + 5% involuntary. The team interprets the 8% as “the product is not retaining well enough” and starts shipping retention features. The actual problem is that the retry policy gives up after one failed attempt instead of three, and a payment-rail fix would close most of the gap with no product work needed.
How the three diverge in a real MENA cohort
A simplified example to make the math concrete (numbers chosen for illustration, not from a specific account):
- 100 paying customers at start of month
- 8 customers lost → 8% customer churn
- Of those 8: 5 are entry-tier ($5/month), 3 are top-tier ($25/month). Total MRR lost: $100 out of $1,000 starting MRR → 10% revenue churn
- Of those 8: 5 actively cancelled, 3 had a failed renewal that the system gave up on after one retry. Those 3 represent $30 of the $100 lost → 3% involuntary churn (and 7% voluntary)
Three valid numbers. Three different operational stories. The board pack number is 10% (revenue churn). The “what to fix” number is the 3% involuntary, because closing that gap is the highest-leverage move available.
How to model each in your forecast
The mistake teams make is forecasting “churn” as a single line. The right way to forecast is to model each component separately because they respond to different levers:
Customer churn trends with product-fit and onboarding quality. It shifts on monthly to quarterly timescales as you ship product changes. Forecast it by user-tier and cohort-age, not as a single number.
Voluntary revenue churn (the part of revenue churn that comes from active cancellations) trends with the same product-fit signal but weighted by LTV. If your high-LTV users are leaving faster than your low-LTV ones, the voluntary revenue churn line will diverge from the customer churn line — that divergence is the leading indicator that your highest-value cohorts are unhappy.
Involuntary revenue churn trends with payment infrastructure decisions: retry policy, card-update prompts, payment-rail diversity. It can be cut by 30-60% in a single sprint with a retry-policy refactor, and that improvement is mostly permanent — unlike product-driven retention work, which has to keep being maintained as the user base evolves.
Forecast each line separately. Set targets per line. When the three lines move together, your product is the lever. When they move apart, your product or your payments is the lever — and which one tells you exactly where the work is.
The signal Madar surfaces here
When Madar AI connects to your subscription data, the first thing it does is split your reported churn into these three components and flag which one is moving. We routinely see MENA subscription apps with a “churn problem” that turns out to be 60-70% involuntary — a payment infrastructure problem dressed up as a product problem.
If you want to see this split on your real data, the live demo does it in the first 10 minutes.