Interactive tool
Calculate customer lifetime value
Use realized cohort revenue for a historical LTV, or add monthly revenue and churn for a simple forecast. Keep the cohort and revenue basis consistent.
Realized LTV per customer
Enter cohort values
Realized LTV per paying customer
Enter cohort values
Simple churn-based forecast
Add optional inputs
The forecast divides average monthly revenue by monthly customer churn. It assumes both stay stable, so treat it as a planning input, not a realized result.
A customer lifetime value calculator is most useful when a channel report and a subscription report disagree about what a new subscriber was worth. The channel can show an install. The subscription report can show a trial, a refund, an upgrade, or six months of renewals. Put those records into one declared cohort before treating the result as LTV.
For an app team, the first good answer is usually realized value: how much revenue did this group actually produce in a defined window? That is different from a forecast based on churn. Both have a place, but they should never share one unlabeled number.
What is a customer lifetime value calculator?
A customer lifetime value calculator measures or estimates the revenue a customer cohort produces over time. It needs three choices before it needs a formula:
| Input | Decision to make | Why it changes the answer |
|---|---|---|
| Customer group | All acquired customers or new paying customers | Trials and non-converters affect the denominator |
| Revenue basis | Gross customer sales or net proceeds | Store fees, applicable taxes, and refunds change the numerator |
| Lifetime window | For example, the first 30 days, six months, or a year | A newer cohort has had less time to produce revenue |
Google Analytics describes lifetime value as cumulative metric value for users acquired in a selected acquisition date range, divided by total users acquired in that range. RevenueCat’s realized LTV per customer definition uses the same cohort idea: actual revenue in a selected lifetime window divided by new customers in that cohort.
The wording matters. “Lifetime” does not mean a cohort has completed its life. A cohort that arrived last month can have a 30-day realized LTV. It is a real historical measure, but it is not comparable with a mature 12-month cohort unless the windows match.
Which customers should the calculator count?
Start with the question the number is supposed to answer. If you are evaluating an acquisition campaign, LTV per acquired customer shows what every acquired person produced, including people who never paid. If you are reviewing pricing or retention among subscribers, LTV per paying customer may be the clearer number.
RevenueCat distinguishes the two denominators. Its realized LTV per paying customer divides realized revenue by new paying customers. A customer who only started a free trial is not a paying customer for that measure.
Do not change denominators just because the result looks better. Keep two rows if you need both views.
| Measure | Denominator | Useful when |
|---|---|---|
| Realized LTV per customer | Everyone acquired in the cohort | Comparing acquisition sources, campaigns, or onboarding paths |
| Realized LTV per paying customer | Customers who became paying customers | Comparing plans, offers, and paid subscriber behavior |
A cohort label should travel with the calculation. Acquisition month, channel, country, store, plan, offer, and first paid date are often enough to make a later comparison possible. Mobile app analytics covers the practical work of joining product, store, and subscription signals around those labels.
Choose a revenue basis before doing the math
The price on the paywall and the money reported as proceeds are different measures. Either can be useful, but a calculator should say which one it uses.
Apple’s Subscriber Report reference defines Customer Price as the auto-renewable subscription price and Developer Proceeds as proceeds for each delivered item. The report also records negative Customer Price values for refunds. Google Play similarly says its estimated sales reports show buyer payments without deducting taxes or Google fees, while earnings reports include transaction lines for fees, tax, refunds, and merchant-currency amounts.
| Revenue basis | What it represents | Use it when |
|---|---|---|
| Gross sales | What customers paid before the chosen deductions | You need a top-line demand view and use the same basis for every cohort |
| Net proceeds | The amount left in the relevant store or merchant report after its listed deductions | You are comparing acquisition cost with revenue closer to what the business keeps |
Refunds are not a footnote. Decide whether the window includes them, then use that same rule on every cohort. Apple also notes that proceeds rates can differ after a subscriber has completed more than a year of paid service, so a long-lived cohort needs its report basis documented rather than inferred from the listed price.
How do you calculate realized customer lifetime value?
For a historical cohort, the calculation is straightforward:
Realized LTV per customer =
cohort revenue within the selected lifetime window / new customers in the cohortFor paying subscribers, change the denominator:
Realized LTV per paying customer =
cohort revenue within the selected lifetime window / new paying customers in the cohortUse the same cohort and window on both sides. Do not add new customers who arrived after the acquisition period, and do not compare a six-month cohort with a three-month cohort as though both had the same amount of time to renew.
A six-month customer lifetime value example
Imagine a March cohort of 1,000 new paying subscribers. The team chooses six months and uses net proceeds after the fees, applicable taxes, and refunds recorded in its reports. The monthly proceeds from that cohort are hypothetical and only show the arithmetic.
| Month in cohort | Net proceeds |
|---|---|
| Month 1 | 6,800 dollars |
| Month 2 | 5,950 dollars |
| Month 3 | 5,270 dollars |
| Month 4 | 4,760 dollars |
| Month 5 | 4,250 dollars |
| Month 6 | 3,910 dollars |
Total six-month proceeds are 30,940 dollars. The calculation is:
30,940 dollars / 1,000 new paying subscribers = 30.94 dollarsThe six-month realized LTV per paying customer is 30.94 dollars. It does not say what a future subscriber will produce. It says what this group produced in its first six months under the selected revenue rule.
If the team also acquired 1,500 people who never converted from a trial, LTV per acquired customer would need a different denominator. That distinction can make an acquisition channel look very different from a pricing change, even when both reports use the same revenue total.
When should you use a churn-based LTV forecast?
A churn-based calculation is useful for planning when the team needs an assumption to test before a cohort has matured. Keep it visibly separate from the realized result.
Forecast CLV = average monthly revenue per customer / monthly customer churn rateIf a hypothetical app has 6.80 dollars in monthly net revenue per customer and 12 percent monthly customer churn, the calculation gives 56.67 dollars. That result assumes the monthly revenue and churn rate remain stable. It can become misleading when an annual plan, a price change, a refund wave, upgrades, or a new onboarding flow changes the cohort’s shape.
Use a forecast as an input to a decision, then replace it with realized cohort data as renewals arrive. pLTV explains how app teams use and validate a predicted lifetime-value forecast. Net retention rate is the companion view when you need to separate expansion, contraction, and lost revenue inside an existing cohort.
What should an app team check before trusting LTV?
A calculator is reliable when its definitions survive a second look. Before comparing channels or months, check these items:
- Name the acquisition cohort and use the same lifetime window for every comparison.
- Keep LTV per customer and LTV per paying customer as separate measures.
- State whether the revenue line is gross sales or net proceeds.
- Handle refunds, fees, and applicable taxes consistently.
- Split monthly, annual, trial, and introductory-offer cohorts when their renewal timing differs.
- Separate deliberate cancellation from a failed renewal instead of calling both the same kind of churn.
That last split changes the work after the calculation. Churn analysis shows how to find the cause behind the lost revenue. For failed renewals, use the store-state sequence in failed payment recovery for subscription apps rather than treating a billing problem as a cancellation decision.
Refix is built to bring product, subscription, and support signals into one operating view, so a team can calculate cohort value and follow a change in it back to the journey that produced it.
See how Refix connects the signals behind subscriber value.
FAQ
- What is a customer lifetime value calculator?
- A customer lifetime value calculator estimates or measures how much revenue a customer cohort produces over a defined period. For subscription apps, it should state which customers count, whether revenue is gross sales or net proceeds, and how refunds are handled.
- How do you calculate customer lifetime value?
- For realized customer lifetime value, divide the cohort revenue earned within a selected lifetime window by the number of customers acquired in that cohort. Use new paying customers instead when you need LTV per paying customer.
- Should I use gross sales or net proceeds for LTV?
- Either can work if you label it and keep it consistent. Gross sales reflect what customers paid. Net proceeds are closer to the revenue left after the store's fees, applicable taxes, and refunds in the chosen report.
- Do free trial users count in customer lifetime value?
- They count in LTV per customer when they are in the acquired cohort. For LTV per paying customer, use customers who became paying customers and keep trial-only users out of that denominator.
- Can I calculate customer lifetime value from churn rate?
- You can make a forecast by dividing average monthly revenue per customer by monthly customer churn, but it relies on stable revenue and churn assumptions. A realized cohort calculation is the safer starting point when you have the data.
