Average Customer Lifetime Is Not 1 Divided by Your Churn Rate (2026)

If you calculate customer lifetime as 1 divided by your churn rate, you are asserting that a customer's risk of leaving is the same in month 1 as in month 30. That assumption is false for almost every subscription business, and the error is not small or symmetric: depending on which month you sampled the churn rate from, the same book of business yields "average lifetime" figures that differ by a factor of four. Report a survival curve and a horizon-bounded value instead of a single lifetime number.

Reliability engineering made this exact mistake at industrial scale, gave it a name - the MTBF fallacy - and spent decades unwinding it. The correction transfers cleanly.

The formula, and the assumption hiding inside it

The standard identity is:

Expected lifetime = 1 / monthly churn rate
LTV = ARPU x expected lifetime = ARPU / churn rate

At 5 percent monthly churn: 1 / 0.05 = 20 months.

That is the mean of a geometric distribution, and it is correct if and only if the churn probability is constant across tenure. In reliability terms, it holds for Pattern E - "constant probability of failure at all ages (exponential survival distribution)" - which described 14 percent of the items in the United Airlines analysis discussed in our churn hazard curve guide. For the other 86 percent, the single number is not an approximation of the right answer. It is an answer to a different question.

The same mistake, sixty years earlier

Mean Time Between Failures is the most misread number in engineering. A component with a 50,000-hour MTBF is routinely described as lasting 50,000 hours - about six years. It does not. Under a constant hazard, MTBF is the inverse of the failure rate, and roughly 63 percent of units fail before reaching it. MTBF is a rate expressed in time units, not a service life.

Nowlan and Heap were unusually direct about the underlying confusion. Discussing the practice of speaking about "the 'life' of an item," they write: "This statement has no meaning unless a probability of survival is associated with it" (Reliability-Centered Maintenance, 1978, p. 26).

They are equally hard on the summary statistic itself: "it should also be apparent by now why the failure rate plays a relatively unimportant role in maintenance programs: it is too simple a measure. Although the frequency of failures is useful in making cost decisions it tells us nothing about what tasks are appropriate."

Substitute "churn rate" for "failure rate" and "retention program" for "maintenance program" and the sentence needs no other edits. A churn rate is adequate for costing. It is not adequate for deciding what to do, and 1/churn does not rescue it - it launders a rate into a duration and adds false precision on the way.

Two fixes, biased in opposite directions

This is where the problem gets genuinely awkward, and why "just collect more data" does not converge on the truth.

Fix 1: use a recent churn rate. Your blended monthly churn is 5 percent, but that is dominated by the month-1 spike. So you use a mature-cohort rate instead - accounts past month 12, churning at 1.5 percent. Now 1 / 0.015 = 67 months.

Fix 2: average the observed tenure of churned customers. You query every account that has ever cancelled and average how long they lasted. You get 9 months.

Fix 3: keep the blended rate. 1 / 0.05 = 20 months.

Same book of business. Three defensible methods. 9, 20, and 67 months.

Fix 2 is the most common query written by analysts and the most wrong. It conditions on having already churned. Your best accounts - the four-year ones - contribute nothing to the average until they leave, which means the number can only be dragged upward slowly and is guaranteed to understate. Its bias is structurally identical to the survivorship problem, inverted: instead of only seeing survivors, you are only seeing casualties.

Note the asymmetry. More time does not fix Fix 2, because new short-lived accounts keep entering the numerator. More data does not fix Fix 1, because the problem is not sampling error - it is that the estimand does not exist as a single number.

Why the mature-cohort rate is the seductive one

Fix 1 with mature cohorts feels rigorous. It is the one most likely to reach a board deck, and it is the most dangerous, because it usually rests on a misreading of the sorting effect.

As covered in the hazard-curve guide, aggregate retention improves with tenure even when no individual gets more loyal, simply because high-risk accounts leave first. Fader and Hardie's finding is that "even when aggregate retention rates are monotonically increasing, the individual-level churn probabilities are unlikely to be declining over time," and that "accounting for cross-sectional heterogeneity is more important than accounting for any individual-level dynamics in churn propensities" (Fader, Hardie, Liu, Davin and Steenburgh, 2018).

So the low mature-cohort rate is a property of who is left, not a property of what happens to accounts as they age. Applying it to a new cohort assumes the new cohort will be composed like the surviving one. It will not be - it still contains all the high-risk accounts that have not churned out yet.

Their earlier paper introduced the shifted-beta-geometric model precisely to project retention properly from short histories, and demonstrated that it can be run in a spreadsheet (Fader and Hardie, "How to Project Customer Retention," Journal of Interactive Marketing, 2007). The barrier to doing this correctly has never been mathematical difficulty.

What to report instead

Three rules make this practical:

1. Bound the horizon. "Expected revenue per account over 24 months" is a defensible number. "Lifetime" is not, because it depends on extrapolating past every month you have observed.
2. Never quote a mean without a survival probability. This is Nowlan and Heap's requirement stated in commercial language. "20 months" means nothing; "median 11 months, 30 percent still active at 24 months" means something.
3. Segment before you summarise. If two segments have materially different hazards, a blended LTV is an average over a mixture and describes neither.

This is the same discipline our guide to levels of assurance in research applies to qualitative claims: state what the number is licensed to support.

Where research closes the gap

None of the above tells you why the hazard has the shape it has, and no amount of modelling will. A survival model is a description. It can tell you that month-19 accounts are leaving at a rising rate; it cannot tell you that the rate is rising because a permissions model that worked at 40 seats becomes unworkable at 200.

This is where Koji fits, and the honest framing is that it supplies the term the formula is missing:

• Interview by tenure band, in parallel. Recruit from the hazard chart, not from a churn list. Koji fields AI-moderated interviews across several bands simultaneously, so the expensive part - talking to enough accounts in each band for the comparison to mean anything - stops being the constraint.
• Reach still-active accounts, which is where censoring hides the answer. The accounts that most distort your tenure average are the ones still paying you. They are also the only ones who can describe the wear-out mechanism before it completes. Exit interviews structurally cannot reach them.
• Quantify alongside the qualitative. Koji's six structured question types - open_ended, scale, single_choice, multiple_choice, ranking, and yes_no - let one study produce both the narrative and the countable distribution. A ranking question across tenure bands shows whether the top-ranked frustration actually changes with age, which is the empirical test of whether your regimes are real.
• Refresh continuously. Hazard shape moves whenever onboarding, pricing, or ICP changes. A standing study keeps the denominator of your LTV honest instead of annually re-litigated.

Traditional survey platforms can collect a satisfaction score by tenure. They cannot run a probing conversation with a month-22 account about a degradation that account has not consciously articulated - which is exactly the input a survival curve cannot generate and a finance model most needs.

A working checklist

1. Find every place 1/churn or ARPU/churn is used in your models and label it with its assumption.
2. Plot survival instead. Report 12- and 24-month survival probabilities.
3. Never compute mean tenure from churned accounts only. If you must, state the censoring explicitly.
4. Check whether your churn rate falls with tenure - and whether it still falls after segmenting on a signup-time attribute.
5. Switch reporting to a bounded horizon: expected revenue over 24 months.
6. Quote a median and a survival probability, never a bare mean.
7. Segment LTV wherever hazards differ materially between segments.
8. Pair every survival estimate with a study that explains the shape.

Frequently asked questions

Is LTV = ARPU / churn rate ever correct?

Only when the churn probability is genuinely constant across tenure and roughly uniform across customers. That combination is rare - it corresponded to 14 percent of items in the classic reliability study, and subscription businesses almost always have a pronounced early-tenure spike. If your hazard curve is flat after segmenting, the formula is defensible for that segment.

What is the MTBF fallacy and how does it apply to customers?

MTBF (Mean Time Between Failures) is an inverse failure rate, not a service life, yet it is habitually read as "how long the unit lasts." Under a constant hazard about 63 percent of units fail before reaching the MTBF. The customer version is reading 1/churn as "how long a customer stays," when it is just the churn rate rewritten in months.

Why is average tenure of churned customers biased?

Because it excludes every account that has not churned yet, and the accounts that have not churned yet are disproportionately the long-lived ones. This is right-censoring. The estimate is guaranteed to understate true lifetime, and it does not self-correct with more time, since new short-lived accounts keep entering.

Should I use a cohort-specific churn rate instead of a blended one?

It is better than blended, but it introduces the opposite error if you apply a mature cohort's rate to new accounts. The low rate reflects a population that has already been filtered of high-risk accounts. Project with a model that accounts for heterogeneity, such as the shifted-beta-geometric, rather than reusing a survivor rate.

What should I put in the finance model if not lifetime value?

Expected revenue over a fixed horizon you can observe - 24 months is a common choice - plus the survival probability at that horizon. It is a bounded, checkable claim. If a longer horizon is genuinely needed, fit a survival model and present the projection with its uncertainty rather than a point estimate.

How does this relate to immortal time bias?

They are different errors that often appear together. Immortal time bias is a time-alignment mistake that flatters an adopter group. The MTBF mistake is a distributional one: using a mean that only describes a constant-hazard world. A cleanly aligned dataset can still be summarised with the wrong statistic.

Related Resources

• The Churn Hazard Curve - why one churn rate hides three problems
• Immortal Time Bias in Retention Analysis - the time-alignment error next door
• Survivorship Bias in Customer Research - the mirror-image sampling problem
• Structured Questions Guide - the six question types and when to use each
• Levels of Assurance in Research - stating what a number is licensed to support
• Cohort Analysis Guide - reading retention tables properly