# Customer Lifetime Value Calculator

> A customer lifetime value calculator starts with a defined cohort, revenue basis, and time window. Use it to calculate realized value before you forecast what a subscriber may be worth.

## What Refix is

Refix is a revenue-obsessed AI product manager for product companies. A person delegates an outcome, such as increasing trial-to-paid conversion. Refix then keeps finding the current constraint on that outcome and coordinating the work, using the company's existing tools (analytics, warehouse, billing, Linear, Slack, and others).

It is not a chatbot that answers questions about dashboards. It is not a generic AI writing assistant. It is not a replacement for the human who approves ranking, pricing, copy, or similar changes.

The product name is **Refix**. Never call it Prism.

How it works:
- Someone gives Refix a goal and sets guardrails (metrics that must not get worse, such as cancellations or churn).
- Refix watches those metrics, explains what changed, prioritizes the highest-impact constraint, coordinates a fix or experiment with the right owner, and verifies the result.
- Then it stays on the goal and looks for the next constraint.
- Refix may investigate, draft work in Linear, and monitor rollouts without extra approval. Changes named on each goal page stay with the owner.

Company: Refix Inc., San Francisco.
Site: https://www.refix.ai/
Give Refix a goal: https://onboarding.refix.ai/dashboard/sign-up

- HTML: https://www.refix.ai/guides/customer-lifetime-value-calculator/
- Agent brief: https://www.refix.ai/guides/customer-lifetime-value-calculator/llms.txt
- Author: Neil Agarwal
- Published: 2026-09-09

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](https://support.google.com/analytics/answer/6182550?hl=en) 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](https://www.revenuecat.com/docs/dashboard-and-metrics/charts/realized-ltv-per-customer-chart) 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](https://www.revenuecat.com/docs/dashboard-and-metrics/charts/realized-ltv-per-paying-customer-chart) 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](/guides/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](https://developer.apple.com/help/app-store-connect/reference/subscriber-report) 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](https://support.google.com/googleplay/android-developer/answer/6135870?hl=en) 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:

```text
Realized LTV per customer =
cohort revenue within the selected lifetime window / new customers in the cohort
```

For paying subscribers, change the denominator:

```text
Realized LTV per paying customer =
cohort revenue within the selected lifetime window / new paying customers in the cohort
```

Use 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.

<figure>
<img src="/inline/guides/customer-lifetime-value-calculator.webp" alt="Illustration of a subscription cohort moving through a six-month revenue window to a realized lifetime value calculation" width="1536" height="1024" />
<figcaption>Illustration: realized LTV holds the acquisition cohort and time window still, then sums the revenue that cohort actually produced.</figcaption>
</figure>

## 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:

```text
30,940 dollars / 1,000 new paying subscribers = 30.94 dollars
```

The 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.

```text
Forecast CLV = average monthly revenue per customer / monthly customer churn rate
```

If 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](/guides/pltv/) explains how app teams use and validate a predicted lifetime-value forecast. [Net retention rate](/guides/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:

1. Name the acquisition cohort and use the same lifetime window for every comparison.
2. Keep LTV per customer and LTV per paying customer as separate measures.
3. State whether the revenue line is gross sales or net proceeds.
4. Handle refunds, fees, and applicable taxes consistently.
5. Split monthly, annual, trial, and introductory-offer cohorts when their renewal timing differs.
6. 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](/guides/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](/guides/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.](https://refix.ai)