Customer Lifetime Value

What LTV estimates

Lifetime value models the economic value a customer generates across their entire relationship with a product. It is the ceiling against which every acquisition cost gets judged: spend below LTV (with margin to spare) and growth compounds; spend above it and scale just accelerates losses. The structure: acquisition cohort → retention and monetization over time → value accumulated.

Two definitional choices matter before any math:

• Revenue or margin? Revenue-based LTV flatters everything. The decision-grade version uses contribution margin — net of platform fees (the 15–30% store cut on in-app purchases), COGS, payment processing, and refunds. A "3x LTV/CAC" in revenue terms can be breakeven in margin terms.
• Over what horizon? True lifetime is unknowable in advance, so practical LTV is horizon-bounded: D30, D90, D365 LTV. The honest statement is "expected margin per user through day N," with N chosen to match how long you can wait for payback.

How LTV is calculated

The cohort method (the foundation). Group users by start month or campaign, then track cumulative value per user over time. A cohort table — rows of cohorts, columns of age, cells of cumulative margin per user — is the LTV measurement; everything else is curve-fitting on top. This is also where the most common error lives: an immature cohort's curve is still rising, and reading it as final undervalues everything recent.

The formula shortcut (subscriptions). For stable subscription businesses:

LTV ≈ ARPU per period × margin % ÷ churn rate per period

A $10/month product at 70% margin and 5% monthly churn: 10 × 0.7 ÷ 0.05 = $140. The formula assumes constant churn, which real products violate (churn is usually front-loaded) — treat it as an order-of-magnitude check, not a forecast.

Predictive extrapolation. Fit retention and monetization curves on early cohort behavior to project D365 from D30 data. This is how UA teams act on CPI decisions without waiting a year — accepting model risk in exchange for speed. The discipline that keeps it honest: back-test projections against cohorts that have since matured, and recalibrate when the gap drifts.

In apps, the inputs come from the MMP (channel attribution), product analytics (Firebase, GA4), and the billing system; the LTV table that matters joins all three by cohort and channel.

LTV against acquisition cost

The ratio everyone quotes — LTV:CAC, with 3:1 as folk wisdom — hides the variable that actually constrains growth: payback period. A customer worth 5x acquisition cost over four years still bankrupts you if cash runs out in month eight. The operating questions:

1. At what cohort age does cumulative margin cross acquisition cost?
2. Can your cash position fund that gap at the planned spend level?
3. Is the marginal cohort (the next dollar of spend) still above water, or only the average?

Channel-level LTV is where the metric earns its complexity: channels deliver users whose retention curves differ several-fold, so a unified LTV applied to all channels systematically over-funds cheap-install sources. The pairing with ROAS closes the loop — short-horizon ROAS validates measurement, LTV-based targets steer spend.

Common mistakes

• Using revenue instead of margin. The store's cut alone turns many "profitable" app cohorts negative; refunds and payment costs finish the job.
• Assuming immature cohorts are complete. Reading a 60-day-old cohort's value as its LTV undervalues every recent acquisition decision and panics teams out of working channels.
• Applying one average to every segment. LTV differs by channel, geography, platform, and acquisition season; the blended number is an accounting artifact, not a bidding input.
• Survivorship in the model. Fitting curves only on users who stayed long enough to measure inflates everything; cohort denominators must include the users who vanished on day one.
• Optimizing LTV upward by excluding costs. Each excluded cost (support, infrastructure per user, reactivation spend) moves the number further from the decision it exists to inform.
• Letting the model ossify. Pricing changes, feature launches, and mix shifts invalidate old curves; a quarterly back-test of projection error against matured cohorts is the minimum maintenance.

FAQ

What's a good LTV:CAC ratio? The folk benchmark is 3:1, but the number is meaningless without the horizon and margin basis attached. A margin-based 3:1 with 6-month payback is excellent; a revenue-based 3:1 with 3-year payback may be uninvestable. State all three terms or the ratio says nothing.

How long should the LTV horizon be? Match it to your payback tolerance and cash cycle: bootstrapped products often need D90–D180 horizons; funded companies optimizing for durable growth use D365+. Always label the horizon — unlabeled "LTV" comparisons are how teams talk past each other.

How do I calculate LTV with very little data? Start with the cohort table even if it's short, use the subscription formula as a sanity bound, and borrow curve shapes (not levels) from category benchmarks. Wide error bars honestly stated beat precise fiction; let early retention (D1/D7/D30) drive decisions until monetization data accumulates.

Is LTV different from CLV? Same concept, different communities: "LTV" dominates app and subscription analytics, "CLV" academic and retail marketing. Definitions vary more within each label (revenue vs. margin, finite vs. infinite horizon) than between them.

Predicted LTV in ad platforms — should I use it? Platform pLTV optimization (value-based bidding, predicted-value audiences) can work, but you're optimizing toward their model of value. Feed it your real margin data where supported, and audit against your own cohort outcomes; the app user acquisition path covers wiring value signals into bidding.