Customer Lifetime Value Formula for Subscription Apps
Calculate subscription customer lifetime value with a worked cohort ledger. Separate realized revenue, contribution, forecasts, CAC, and payback.
Customer lifetime value (LTV or CLV) measures the value associated with a customer relationship. For a subscription app, start with a calculation you can reproduce: revenue or contribution from a defined customer cohort, through a stated age, divided by the original cohort size. Keep that observed result separate from a forecast of the rest of the relationship.
A useful report says “five-month revenue per first-paying customer,” rather than presenting a short history as a completed lifetime. This guide gives you a worked ledger, explains the common revenue-per-customer divided by churn shortcut, and shows how to use the result alongside acquisition cost.
The customer lifetime value calculation formula depends on the question
| Question | Calculation | What the answer means |
|---|---|---|
| What has a cohort generated so far? | Revenue after refunds through age H ÷ original cohort size | Observed revenue per customer at that horizon |
| What has it contributed toward acquisition and overhead? | (Revenue after refunds − transaction costs − defined incremental service costs) ÷ original cohort size | Observed contribution per customer; fixed overhead is still outside this calculation |
| What might a customer generate under stable renewal assumptions? | Revenue per paying customer per period ÷ customer churn probability per period | A conditional, undiscounted revenue forecast |
H is the measurement horizon: for example, five completed months after first payment. The first two calculations are a measurement contract for this guide. A billing dashboard can use a different customer definition, refund rule, or cohort date. The third calculation requires assumptions that we will make explicit.
Use revenue LTV when discussing revenue. Use a clearly defined contribution measure when comparing value with acquisition spend. Neither revenue nor contribution before overhead is the same as final company profit.
Define the cohort before exporting a number
Write down five choices before calculating:
- Customer identity: deduplicate people or accounts across devices and transactions. Do not silently switch to counting subscriptions.
- Entry event: choose first app use, first trial, or first successful payment. These answer different questions.
- Age and inclusion: freeze the opening cohort and use the same elapsed horizon for every member. Retain customers who stop renewing in the denominator.
- Money basis: state the currency, refund timing, taxes, transaction fees, and costs included. Keep ledger amounts distinct from normalized monthly recurring revenue.
- Observation or prediction: name the observed horizon and any forecast beyond it separately.
For the example below, the cohort is 100 distinct customers with a first completed payment in the same acquisition period. A later refund changes revenue, not that fixed historical customer count. Amounts use one currency and exclude sales tax. Every customer has reached five completed monthly cycles. This is an illustrative business ledger, not a reproduction of a vendor's dashboard.
A worked subscription cohort: revenue, contribution, and payback
Assume a $10 monthly subscription. The original cohort makes 100, 80, 60, 45, and 30 payments across five cycles. These are invented figures, not customer results or a retention benchmark. No new customers join this ledger.
For arithmetic only, assume transaction costs equal 25% of revenue after refunds, so a refund reverses its associated fee in full. That is a hypothetical contract, not an App Store or payment-provider fee schedule. Actual retained fees must come from your statements: for example, Stripe's refund documentation says original processing fees are not returned. The separate service costs below cover incremental costs attributable to this cohort.
| Cycle | Payments | Collected | Refunds | After refunds | Assumed fees | Service costs | Contribution |
|---|---|---|---|---|---|---|---|
| 1 | 100 | $1,000 | $50 | $950 | $237.50 | $100 | $612.50 |
| 2 | 80 | $800 | $0 | $800 | $200 | $80 | $520 |
| 3 | 60 | $600 | $20 | $580 | $145 | $60 | $375 |
| 4 | 45 | $450 | $0 | $450 | $112.50 | $80 | $257.50 |
| 5 | 30 | $300 | $0 | $300 | $75 | $80 | $145 |
| Total | 315 | $3,150 | $70 | $3,080 | $770 | $400 | $1,910 |
Five-month revenue per opening customer = $3,080 ÷ 100 = $30.80. Five-month contribution per opening customer = $1,910 ÷ 100 = $19.10. Dividing by the 30 customers who pay in the final cycle would change the population and overstate value per acquired customer.
Suppose acquiring these 100 customers cost $1,800, using a consistently defined allocation of acquisition expenses. CAC is $18 per customer. The observed contribution-to-CAC ratio is $19.10 ÷ $18, or about 1.06. Contribution exceeds acquisition cost by $110 in total, before fixed overhead and other excluded costs. This alone does not establish business profitability.
Cumulative contribution is $612.50, $1,132.50, $1,507.50, $1,765, and $1,910 at the five cycle ends. Cycle 5 is the first observed cycle-end point above the $1,800 acquisition spend. That is the measured payback crossing at this resolution; the exact date within the cycle is unknown. Future renewals could add value, and later refunds could change the observed ledger.
When does ARPU divided by churn make sense?
The familiar shortcut is revenue LTV ≈ ARPU ÷ customer churn rate. ARPU must refer to the same paying population and period as churn. A $10 monthly plan is not automatically $10 of measured monthly ARPU: discounts, partial periods, refunds, currencies, free users, and different plans can change the average.
Consider a separate hypothetical model. A customer pays $10 now and has a 5% probability of stopping before each subsequent monthly payment. That probability stays constant; remaining customers continue paying the same amount; there are no reactivations, refunds, or upgrades. Expected payment counts form 1 + 0.95 + 0.95² + … = 20. Expected undiscounted revenue is therefore $10 ÷ 0.05 = $200.
This model does not describe the five-cycle ledger above. It assumes a stable renewal process for an indefinite future. A young app with changing prices, onboarding, customer mix, or renewal behavior should not present the shortcut as a measured lifetime.
A contribution version also needs a cost model. With the same invented 25% fee and $1 incremental cost per paid month, contribution per payment would be $6.50; $6.50 ÷ 0.05 gives $130 of expected undiscounted contribution. That example assumes costs follow paid months. Costs that continue after cancellation, one-time setup costs, and nonrefundable fees require their own treatment.
Keep monthly inputs with monthly inputs and annual renewals with annual renewals. Do not substitute net revenue churn, which can include expansion, for a customer stopping probability. At zero observed churn, division is undefined; it does not prove an infinite valuable lifetime. The subscriber churn guide explains why the population and loss event matter.
Why your billing dashboards can disagree
Current first-party definitions show that the label “LTV” does not identify one universal calculation. Review these definitions before copying a number into a planning sheet.
| Source | Documented approach | Comparison check |
|---|---|---|
| RevenueCat realized LTV per customer | Cohort revenue after refunds divided by customers; customer cohorts start at the earliest first-seen date or first purchase outside the app and can include nonpayers. | Do not compare directly with first-paying-customer value. |
| RevenueCat realized LTV per paying customer | A paying-customer denominator with specific first-payment refund rules, still grouped by the earliest first-seen date or first purchase outside the app. | Check denominator adjustments and the selected lifetime horizon. |
| Stripe Billing analytics | An estimate based on average revenue per user divided by subscriber churn rate. | Read its MRR, subscriber, and churn definitions together. |
| ChartMogul LTV report | ARPA divided by a trailing six-month average of customer churn, excluding the current month. | Its smoothing window differs from a single-month shortcut. |
| Adapty cohort reporting | Revenue per user and revenue per paying user, with different cohort modes and refund behavior. | Retain the mode and refund settings; reconcile exported counts. |
RevenueCat's realized revenue definitions are before store taxes and commissions; they are not your contribution ledger. Adapty also distinguishes predicted LTV from realized observations. A disagreement can reflect a different question rather than broken data. Compare identities, cohort dates, maturity, refunds, and money basis before comparing values.
Compare cohorts at the same age
Customers still active at the data cutoff have right-censored lifetimes: their later expiration time is unknown. Do not treat their current age as a completed lifespan, or average only customers who have already left. A cohort with six months of renewals has had more time to generate revenue than one with two months. Compare both at the two-month horizon first. If some customers have not reached that horizon, mark the value incomplete and wait or publish a clearly labeled partial observation.
Annual subscriptions add another complication: an upfront receipt does not demonstrate renewal a year later. Separate plans when examining renewals, and state whether the table measures receipts or a recognized-revenue schedule. Do not mix an annual payment into a monthly revenue shortcut without a consistent normalization contract.
For a forward estimate, keep observed value and predicted remaining value in separate columns. A model can sum expected future contribution for each period, adjusted for survival and a chosen discount rate. Document the billing timing, forecast horizon, model version, and uncertainty. More decimal places do not make a forecast more reliable.
Use LTV and CAC to choose a test
Match acquisition spend and customer counts to the same cohort. A campaign cost divided by installs is cost per install; divided by first-paying customers, it answers a different question. Account for organic content and shared acquisition work using a stated allocation rather than calling those customers free.
A fixed 3:1 ratio cannot prove that every business is profitable or ready to increase spending. Check the value basis, uncertainty, payback timing, cash needs, and excluded costs. Even a favorable lifetime forecast can take too long to fund the next acquisition cycle.
Use a cohort gap to choose an investigation: missing initial payments, refunds, weak renewals, or unexpectedly high service costs require different responses. A higher-value channel is an observational finding, not proof that the channel caused the difference. Pricing, audience mix, seasonality, and product changes may also explain it.
When testing onboarding or a paywall, record the assigned population, conversion, refunds, and retention through a comparable horizon. A purchase uplift alone does not establish an LTV improvement. The paywall A/B-test calculator helps plan a conversion comparison; it does not forecast customer lifetime value.
A reusable LTV review worksheet
| Field | Write down |
|---|---|
| Population | People/accounts, entry event, cohort dates, fixed denominator, identity deduplication |
| Time | Timezone, elapsed horizon, completed renewals, incomplete observations |
| Money | Currency, receipts or recognized revenue, refund timing, taxes, fees, incremental costs |
| Model | Observed value, predicted remainder, churn/retention assumptions, discounting, uncertainty |
| Decision | CAC allocation, observed payback, alternative explanation, next test and review date |
The useful output is a named number someone else can reproduce, with a horizon and cost basis they can understand. Start with the ledger you have, preserve the unknown future, and review it when the next comparable cohort observation becomes available.