Customer Lifetime Value

What LTV is trying to estimate

LTV puts one number on a stream of future gross profit: everything a customer will pay, minus what it costs to serve them, for as long as they stay. It exists because acquisition decisions need a ceiling. If you cannot say roughly what a customer is worth, you cannot say what you are willing to pay to win one, and every channel argument collapses into an argument about opinions.

That framing matters more than the arithmetic. Nothing in your billing data is called lifetime value. It is a projection built on assumptions about behaviour that has not happened yet, and it should be presented with the assumptions attached.

Why the ARPU-over-churn formula is fragile

The standard formula assumes a constant hazard rate: every customer, in every month, carries exactly the same probability of cancelling. That single assumption is what licenses turning a churn percentage into an average lifetime of 1 ÷ churn.

Real retention curves do not behave that way. Cancellation is almost always front-loaded — badly fitting customers leave in the first few months — and the survivors then churn far more slowly than the population average. The curve flattens; the geometric model behind the formula never does. So the direction of the error depends entirely on which churn rate you feed it. A blended rate dominated by early cancellations undervalues a durable base. A rate measured only on mature cohorts prices every new signup as though they were already a two-year customer.

It breaks entirely at low churn

Because lifetime is 1 ÷ churn, the formula is a hyperbola. At 2% monthly churn the implied lifetime is 50 months. At 1% it is 100 months. At 0.5% it is over 16 years — longer than most SaaS companies have existed and longer than most products will survive in a recognisable form. At zero churn it is undefined, and in a month where a small base happens to lose nobody, that is exactly what your dashboard will try to compute.

The fix is to stop projecting to infinity. Cap the horizon at something you would genuinely underwrite — 24 or 36 months is common — and report the figure as 36-month gross profit per customer. You lose nothing real, because the tail beyond three years was never evidence, and you gain a number two people can disagree about on the same terms.

Only the margin-adjusted version is worth acting on

Revenue LTV, with no margin applied, is the most commonly quoted version and the least useful one. Acquisition costs are not paid with revenue. They are paid with the gross profit left after hosting, payment processing, third-party APIs and the support hours a customer consumes. If gross margin is 78%, the revenue version overstates what the customer can actually repay by 28%, and every metric built on it — LTV:CAC, CAC payback — inherits the error.

What to do when you have real data

Once you have cohorts with a year or more of history, stop modelling and start measuring. Sum the actual cumulative gross profit each signup cohort has delivered to date, fit a curve to the observed retention tail, and extrapolate only to your capped horizon. Do it per segment: a self-serve plan and an annual enterprise contract share nothing except a currency symbol, and one blended LTV describes neither.

One more correction. If your net revenue retention is above 100%, the simple formula is structurally too low, because it holds ARPA flat while your real accounts grow. Ignoring expansion makes the expansion motion look worthless in every model you build.