How to calculate LTV for a subscription app: trials, renewals and store fees

LTV per paying customer and LTV per install

LTV, or lifetime value, is what a customer brings you over a period you choose. Subscription apps need two kinds.

• LTV per paying customer, or per payer: a cohort's revenue divided by the customers in it who paid, as in RevenueCat's Realized LTV per Paying Customer chart (RevenueCat).
• LTV per install: the same money divided by everyone who installed. RevenueCat's closest chart is Realized LTV per Customer (RevenueCat).

They differ by the share of installs that pay. If 5% pay and a payer brings $36, an install brings $1.80. Per payer shows whether your pricing works; per install, what an install is worth. Give either a horizon, such as day 365, and make it net: what you keep after tax, the store's cut and refunds.

The simple formula and why it misleads

The usual shortcut:

Take this guide's fictional app: a $9.99 monthly plan with a 3-day free trial, in Apple's Small Business Program, so it keeps 85% of the price without tax. With 10% monthly churn, the formula gives $9.99 × 10 × 85% = $84.92. Its cohorts, below, show a payer bringing about $36.70 in the first year. Four things go wrong.

• The churn is the wrong one. Your base is mostly long-time subscribers who rarely cancel. New subscribers, the ones ads buy, cancel much faster.
• There is no time limit. You pay for ads now, so value customers over a horizon you can wait for.
• One share kept hides the details: the store, tax, refunds and, on the App Store, how long the subscriber has paid.
• It starts at the first payment, so it ignores installs and trials that never pay.

Build LTV from weekly cohorts

A cohort is the customers who first opened the app in the same week, roughly the week your ads paid for them. RevenueCat's LTV charts group customers the same way (RevenueCat).

1. Get one row per transaction, payments and refunds, with customer, date, store, country and price. RevenueCat's scheduled data exports have a per-transaction feed (RevenueCat).
2. Work out what each payment left you: the price without tax, minus the store's fee at the rate that applied, minus refunds.
3. Add up by age. Total each cohort's net payments by day 7, 30, 90, 180 and 365, from each customer's first day, and divide by its payers. Leave a cell blank until the cohort's last customer reaches that day.

Here, day 30 means day 0 to day 29, while RevenueCat's 30-day lifetime runs through day 30 (RevenueCat).

Each figure in the fictional app's table is what the cohort's payers had paid by that day, on average, net of tax, the 15% fee and refunds.

Read across: day 7 and day 30 barely differ, since the second monthly payment comes after day 30. Read down: cohorts of the same age should look alike, so one that lags by day 90 points to a weaker campaign, country mix or price. The three mature cohorts, those past day 365, put day-365 LTV at $35.28 to $38.28 per payer, $36.70 on average.

What you keep after Apple's and Google's cut

• App Store, standard terms: 30% in a subscriber's first year of paid service, then 15%. Free trials do not count toward that year, and a lapse of more than 60 days restarts the count (Apple).
• App Store Small Business Program: 15% from the first payment, for enrolled developers who are new to the App Store or had up to $1 million in proceeds in the previous calendar year. Passing $1 million in the current year brings back the standard rate (Apple).
• Google Play: 15% of auto-renewing subscriptions, whatever your revenue. In the US, EEA and UK since June 30, 2026, and in Australia and Japan since September 30, 2026, that is a 10% service fee plus a 5% billing fee on Google Play Billing purchases (Google).

At 30%, a $9.99 payment leaves $6.99 for a monthly subscriber's first 12 payments and $8.49 from the 13th, and an annual plan's first renewal is its first payment at 15%. So one-year LTV is almost all at the first-year rate. Outside the program, at 70% instead of 85%, the fictional app's dollar figures would be about 18% lower.

Some storefronts, including the EU, have their own rates (Apple), and our break-even ROAS guide lists them.

Refunds, taxes and currency

Refunds belong to the customer's cohort, not to the week they were processed. App Store customers ask Apple or their card issuer for refunds (Apple), and on Google Play you can also refund orders in Play Console (Google). Late refunds flatter young cohorts. RevenueCat's Revenue chart deducts a refund when it is processed (RevenueCat), its LTV charts only within the lifetime you select (RevenueCat).

Taxes are never yours, and in many countries the store price includes VAT (Google). Apple charges its commission on the price net of the taxes it collects (Apple), and Google calculates its fee on the net price too (Google). RevenueCat's LTV charts include taxes and the stores' commission, so take both out (RevenueCat). Apple does not change subscription prices when tax rates move, so a VAT change alters what you keep from existing subscribers (Apple).

Currency moves a euro subscription's dollar value every month. RevenueCat converts at the purchase day's rate (RevenueCat), Sales and Trends in App Store Connect at a rolling average of the previous month's rates (Apple), and Apple's payment can differ again with the rate when it pays (Apple). Use one method for every cohort.

Projecting cohorts that have not reached a year

Cohorts from your current campaigns have not reached day 365. Project each from its latest age by how much the mature cohorts grew from there: the middle ratio gives the likely value, the lowest and highest the range.

In the fictional app, the three mature cohorts grew 1.41× to 1.45× from day 180 (middle 1.43×), 2.10× to 2.20× from day 90 (middle 2.15×) and 4.29× to 4.63× from day 30 (middle 4.43×).

The range narrows with age, from $2.79 wide at day 30 to $1.03 at day 180. To keep projections honest:

• Use cohorts sold the same way. After a new price, trial or paywall, treat old ratios as rough and widen the range.
• Merge small cohorts into months.
• Label assumptions. If your app is younger than a year, the step to day 365 rests on a guess, such as renewals holding at the fourth-to-sixth-month rate for the high end and slipping for the low end.
• Score yourself. Compare each projection with the truth at day 365, and widen ranges that keep missing.

LTV per install and your CPI ceiling

Ad networks sell installs, so your bid needs LTV per install. For an app with a trial:

RevenueCat's Trial Conversion chart reports both rates and calls their product the overall conversion rate (RevenueCat). Add buyers who skip the trial, if your paywall allows it.

Say 1,000 installs bring 120 trials, a 12% start rate, and 45% of them convert: 54 payers, a paying share of 5.4%. At the youngest cohort's projected $35.18 to $37.97 per payer, an install is worth $1.90 to $2.05, likely $1.96. That is already net, so $1.90 is a cautious one-year break-even CPI. For 30% profit on cost, divide by 1.3: about $1.46. Working from revenue before the store's cut? Divide by your break-even ROAS instead, as our break-even ROAS guide explains.

• Measure the rates on paid installs, by campaign and country. Organic installs often convert differently.
• Match the horizon to your cash. If you cannot wait a year, set the ceiling on day-90 or day-180 LTV.
• Count only the installs the ads caused. Our guide to measuring what your app ads really add shows how.

Common mistakes

• Blended ARPU. A month's revenue over all users mixes old renewals with new customers, organic with paid, and every country. It is not what a new install brings.
• Mixing plans. Annual plans collect a year up front and weekly plans a little at a time, so a single LTV shifts whenever the plan mix does. Build it per plan, weighted by each campaign's mix.
• Gross against net. A 15% store fee alone makes gross 18% higher than net. With 20% VAT in the price and a 30% fee, gross is 71% higher. Keep LTV, CPI and ROAS on one basis, as our guide to why Ads Manager and RevenueCat never match explains.
• Survivorship. Churn from current subscribers, revenue divided by active subscribers, or bad cohorts dropped from the average all count only the customers who stayed. Divide by everyone who started; keep every cohort.

How INTARC does this

INTARC reads your stores' revenue, from App Store Connect, Google Play or RevenueCat, and your ad accounts with read-only keys, and needs no SDK. It builds each week's cohort from what its customers actually paid, after the store's cut, and forecasts what each cohort will have paid by day 30, 90, 180 and 365, with a range. Every forecast it makes on its own studio's apps is written down in advance and scored in public at /proof. You can look around the demo or create an account to run it on your own apps.

Frequently asked questions

How long should the LTV horizon be?

Usually a year: long enough to see renewals, short enough to act on. If cash is tight, decide on day-90 LTV.

Should LTV be gross or net?

Net: what you keep after tax, the store's fee and refunds. Gross revenue set against ad costs flatters every campaign.

How do free trials change LTV?

A trial delays the first payment and decides how many installs ever pay, so it shifts LTV per payer later and changes LTV per install through the trial start and trial-to-paid rates.

What is the difference between LTV and ARPU?

ARPU often means a month's revenue divided by its active users, old and new together. LTV follows one cohort of new customers, which is what an install is worth. RevenueCat also calls its cohort-based Realized LTV per Customer ARPU.

Can I use RevenueCat's LTV charts?

Yes, as a start. They group customers by the day they were first seen, like the cohorts here, but include taxes and the stores' commission, so take those out first.

Store fees, tax rules and reporting tools change often. We checked every linked source on November 13, 2026. Examples use fictional apps and numbers.