Retention vs Churn: difference and formulas
Contents:
Why this question keeps showing up
If you have done more than a handful of product-analyst loops, you have answered some version of "what is the difference between retention and churn" — at Netflix, Stripe, DoorDash, or any subscription business it is essentially a screening question. The reason it keeps appearing is not because the math is hard. It is because the definitions drift between teams, and a candidate who blurts "they are opposites, just 1 − retention" usually fails the follow-up.
The honest answer is that retention is a cohort metric and churn is a period metric, and the two only line up cleanly when you force them onto the same denominator. The rest of this post walks through both formulas, shows the SQL you would write on a whiteboard, and points at the specific spots where candidates burn the interview.
Load-bearing trick: retention is computed per signup cohort; churn is computed per calendar period. Mixing the denominators is the #1 reason your numbers stop matching the finance team's deck.
What retention actually measures
Retention tells you the share of users from a given cohort (usually signup date) who came back N days later. The three most common cuts are Day 1, Day 7, and Day 30 retention for consumer apps, and Month 1 through Month 12 for SaaS. The denominator is fixed: it is the original cohort size. The numerator shrinks over time.
Here is a Day 7 retention query that any data-analyst interviewer at a B2C company will recognize:
-- Day 7 retention: share of a signup cohort that returned exactly on day 7
WITH cohort AS (
SELECT user_id,
DATE(MIN(created_at)) AS signup_date
FROM events
GROUP BY user_id
)
SELECT c.signup_date,
COUNT(DISTINCT c.user_id) AS cohort_size,
COUNT(DISTINCT e.user_id) AS returned,
ROUND(100.0 * COUNT(DISTINCT e.user_id)
/ COUNT(DISTINCT c.user_id), 1) AS retention_d7_pct
FROM cohort c
LEFT JOIN events e
ON e.user_id = c.user_id
AND DATE(e.created_at) = c.signup_date + INTERVAL '7 days'
GROUP BY c.signup_date
ORDER BY c.signup_date;If 1,000 users signed up on March 1st and 250 of them logged an event on March 8th, Day 7 retention for that cohort is 25%. Notice that the denominator does not change as time passes — that is the defining property of a cohort metric. Rolling retention, where you count "returned at least once by day 7", is a different beast and tends to inflate the number by 5-10 points.
What churn actually measures
Churn is the share of active customers at the start of a period who are gone by the end of it. For subscription products you read it directly off the billing system — anyone whose subscription state flipped from active to canceled (or past_due for involuntary churn) counts. For free products you have to define "active" first, otherwise the metric is meaningless.
-- Monthly churn for a subscription book of business
WITH active_start AS (
SELECT DATE_TRUNC('month', d.month) AS month,
COUNT(DISTINCT s.user_id) AS active_users
FROM (SELECT DISTINCT DATE_TRUNC('month', created_at) AS month
FROM subscriptions) d
JOIN subscriptions s
ON s.created_at < d.month
AND (s.canceled_at IS NULL OR s.canceled_at >= d.month)
GROUP BY 1
),
churned AS (
SELECT DATE_TRUNC('month', canceled_at) AS month,
COUNT(*) AS churned_users
FROM subscriptions
WHERE canceled_at IS NOT NULL
GROUP BY 1
)
SELECT a.month,
a.active_users,
COALESCE(c.churned_users, 0) AS churned_users,
ROUND(100.0 * COALESCE(c.churned_users, 0)
/ NULLIF(a.active_users, 0), 2) AS churn_rate_pct
FROM active_start a
LEFT JOIN churned c USING (month)
ORDER BY a.month;If you had 5,000 active subscribers on April 1st and 200 of them canceled during the month, monthly churn is 4.0%. Annualize it crudely with 1 − (1 − 0.04)^12 ≈ 39% — most finance decks present the annual figure.
Side-by-side comparison
The table below is the one I would draw on the whiteboard if asked "compare retention and churn":
| Dimension | Retention | Churn |
|---|---|---|
| What it answers | "How many from this cohort came back?" | "How many active users left during this period?" |
| Denominator | Original cohort size (fixed) | Active users at start of period (moves) |
| Unit of analysis | Signup cohort | Calendar period |
| Time direction | Forward-looking from signup | Backward-looking from period close |
| Healthy benchmark (B2C mobile) | Day 30: 5–15% | Monthly: 5–10% |
| Healthy benchmark (B2B SaaS) | Month 12: 80–95% | Monthly: 1–3% |
| Primary use | Onboarding, PMF, A/B testing | Revenue forecasting, LTV, retention saves |
The benchmarks are not made up — they roughly match what levels.fyi-tier companies publish in S-1 filings and what you will see on Glassdoor case-study leaks. Numbers outside these ranges are not automatically bad, but they need a story.
When to lead with retention vs churn
Lead with retention when your product is freemium, ad-supported, or pre-monetization. DAU and MAU are downstream of retention, and so is your ability to run a powered A/B test — if Day 7 retention is 5%, you do not have enough returning users to test anything. Retention curves also let you spot the flatten point: the day after which the curve stops decaying. A flat curve at 20% is a much better PMF signal than a curve that starts at 60% and bleeds to 3%.
Lead with churn when the product is a subscription, when revenue and renewals matter more than DAU, or when you need to plug a number into the LTV formula LTV = ARPU / churn_rate. Churn also unlocks revenue retention metrics: gross dollar retention (GDR) caps at 100% and ignores upsell, while net dollar retention (NDR) can exceed 100% when expansion outweighs cancellations. A best-in-class B2B SaaS will quote NDR 120% with GDR 92%.
Sanity check: if your churn calculation produces the same number two months in a row to three decimal places, you almost certainly have a SQL bug. Real churn fluctuates.
Common pitfalls
The most common mistake is conflating cohort retention with period retention. A signup cohort retention of 30% at day 30 does not mean monthly churn is 70%. The first is "of users who signed up exactly 30 days ago, how many came back this week"; the second is "of users active at the start of last month, how many are gone now." These produce different numbers on the same data, and interviewers love to ask "why don't these reconcile" to see if you can spot the denominator mismatch. The fix is to never compute one from the other — pull each from its native definition and let them disagree.
A close second is computing churn on free users without defining "active" first. If your users table has a last_seen_at column and you write COUNT(*) FILTER (WHERE last_seen_at < NOW() - 30 days) / COUNT(*), you have not computed churn — you have computed the share of all-time users who are currently inactive, which goes up forever and tells you nothing about this month. The fix is the two-CTE pattern: define an active_start set for last month, an active_end set for this month, and take the set difference. Activity threshold matters: "any session" produces a much lower churn than "completed a paid action."
The third trap is double-counting voluntary and involuntary churn. When a credit card expires and the user fails to update it, most billing systems mark the subscription past_due, then canceled 7-14 days later. If you count both events you inflate churn; if you count neither you under-report. Stripe's recommendation, which most analytics teams follow, is to count the final cancellation event only, and split voluntary (user_canceled) from involuntary (payment_failed) in a separate breakdown — they have different fixes.
The fourth trap is mixing weekly cohorts with monthly retention reports. Weekly cohorts have 4-5× more noise per data point than monthly cohorts. If you A/B test a feature and read out "Day 7 retention is up 3 points week-over-week", you are looking at noise. Either move to monthly cohorts or compute a confidence interval with at least 5,000 users per arm before you call anything significant.
The fifth, sneakier trap is survivorship bias in your retention curve. If you only include users who installed the app from a paid channel, your curve looks great because organic users were excluded. Always segment by acquisition channel before declaring a number "healthy" — Day 30 retention of 12% blended could mean 25% organic and 3% paid, which is a completely different business than 12% across the board.
Interview-style questions
How is retention different from churn? Retention is a cohort metric — you fix a signup date, then count returns. Churn is a period metric — you fix a calendar window, then count exits divided by the active base at window open. Mathematically they look related but they sit on different denominators, so do not derive one from the other on a real interview.
How do you compute LTV from churn? The standard recipe is LTV = ARPU / churn_rate when churn is stable. If ARPU is $15/month and monthly churn is 5%, LTV is 15 / 0.05 = $300. The formula breaks when churn is non-stationary — for a startup with falling churn, use a Kaplan-Meier survival curve instead and integrate.
What's a good Day 1 retention? For B2C mobile apps, 25-40% is normal; for games, 30-50%; for utility apps with weekly use cases, 15-25% is fine because the next session is not expected on day 1. Below 20% on a daily-use app means your onboarding is broken.
Churn is climbing — what do you do? Segment first, fix second. Cut by acquisition cohort, channel, plan, geography, and device. The signal is almost never "churn is up everywhere" — it is "churn is up in the trial-to-paid segment that came in via the Facebook campaign that scaled last month." Then look at session traces in that segment to find the drop-off step.
Can churn be negative? Yes — net revenue churn can be negative when expansion revenue from existing customers exceeds lost revenue from cancellations. This is called net negative churn and is the holy grail for B2B SaaS. User-count churn cannot be negative; you cannot un-cancel more users than you lose.
Related reading
- Churn rate formula
- How to calculate cohort retention in SQL
- How to calculate D1 D7 D30 retention in SQL
- How to calculate LTV in SQL
- SQL for cohort retention
If you want to drill questions like this on real interview SQL every day, NAILDD is launching with 500+ analyst problems across exactly this pattern.
FAQ
Do retention and churn always sum to 100%?
For a single cohort over a single period with the same definition of "active", yes — by construction. In practice the two numbers come from different shops: retention from product analytics on a signup cohort, churn from billing on a calendar month. Direct addition is almost always wrong, and finance and product reporting different numbers for "user loss" is a sign of definition drift, not a math error.
How do I compute retention for a product without registration?
Use an anonymous identifier — device ID, hashed cookie, or a fingerprint. Define "first visit" as the date of the first event for that identifier, then run the standard cohort query. The catch is that a single human can produce multiple IDs (new device, cleared cookies, incognito mode), which inflates the denominator and depresses retention by 5-15% versus a registered-user count. Most teams accept this and call it out in the methodology footnote.
Is retention or churn more important to track?
It depends on monetization. For subscription products — Netflix, Spotify, any B2B SaaS — churn drives the LTV and the cash forecast, so it is the headline number. For freemium and ad-monetized products — TikTok, Duolingo's free tier — retention is more load-bearing because DAU and ad inventory depend on it directly. A growth-stage company usually tracks both, with one as the company-wide north star.
What's a normal monthly churn for SaaS?
For B2B SaaS, 1-3% monthly is healthy (roughly 12-30% annual), and best-in-class enterprise products quote sub-1% logo churn. For B2C subscriptions like streaming, 5-10% monthly is the norm because the cancel button is one tap away. If your monthly churn is consistently above 10% on B2C or above 5% on B2B, the problem is probably in onboarding or pricing, not in retention saves.
Can I use retention curves to predict churn?
You can fit a Weibull or exponential decay to the retention curve and read off implied long-run churn, but treat the result as directional. The curve is built on past behavior, and any product change — pricing, onboarding redesign, a new core feature — invalidates the fit. Use it for ballpark LTV when you do not have enough subscription history to compute churn directly, and revisit the fit every quarter.
How long should my retention measurement window be?
For consumer mobile, the standard window is D1, D7, D30, with D30 as the headline. For SaaS, monthly retention through Month 12 is the minimum, and Month 24 is better if you have the data. Shorter windows under-measure the long tail; longer windows are limited by how long the product has existed and by structural changes that make old cohorts non-comparable.