Sep 2026 · v1.0 · Systems · Interactive · the LTV engine of the Unit Economics Estimator as a standalone tool
What is one subscriber worth? Net LTV at the M13 horizon – a month-by-month payment schedule built from the retention curve, net of VAT, store / PSP fee and refunds – per plan and blended, with payback against your own CPA. Retention starts from RevenueCat benchmarks; type your cohorts over them. Scope: subscription apps only; no acquisition funnel here – for CPM → CPA and the full "does the growth math close?" view use the Unit Economics Estimator (same LTV engine, mirrored and self-tested). Tags: B benchmark · E estimate · A assumption.
Jargon on this page
LTV M13 – lifetime value over 13 months: the first payment, 12 months of renewals and the first annual renewal · RC – RevenueCat; SOSA – its State of Subscription Apps report · SBP – Apple's Small Business Program (15% commission under $1M/year; Google has the same 15% tier) · PSP – payment service provider on web checkout (Stripe, Paddle) · CPA – cost per new subscriber · ROAS – net LTV ÷ CPA · M1 / M6 / M12 – share of a monthly cohort still paying at that renewal · a2a / w2w – app-store billing / web-checkout billing (the web cohort retains ×0.89 on benchmarks).
How to use – 30 seconds
Pick your vertical (refund rate, typical plan mix) and geo (VAT default – and a reminder to enter local prices). Retention benchmarks come from RevenueCat SOSA 2026; the scenario preset moves them P25 → P75.
Enter your plans and prices – the only thing the tool can't know. 1st-period price if you run an intro offer; shares must sum to 100%.
Retention: keep the benchmark curve and type over any anchor you have (M1 / M6 / M12, weekly renewals #1–#3, week-26 survival) – a typed field turns blue and is used as-is – or, if you only have two renewals so far, switch to Fit from my first 2 renewals. Where each number lives in your own systems – Reference › Data sources.
Press Calculate (the default case is already computed). Enter your CPA – from Ads Manager or the Unit Economics Estimator – to see ROAS, payback month, target CPA and peak cash. Show a colleague your exact setup – Copy share link.
Setup
Plans & prices (your data – required; mix must sum to 100%)
1st-period price: what the first payment is charged at (e.g. $8.99 for the first week/month, $59.99 for the first year); every renewal is charged at the plan price. Leave blank when there is no intro offer.
Refund hits the first payment only (renewals are rarely refunded) – it is inside the gross figure.
VAT / GST is stripped out of the sticker price first – the store (or you, on web) remits it; then the store commission or PSP fee is taken from what is left.
Web cohort ×0.89 [B, Adapty] applies to benchmark retention on web billing only – typed or fitted renewals already are your cohort.
Press Calculate to compute the results with the current inputs.
…
–
Blended net LTV M13
–
Gross LTV M13 (sticker)
–
VAT · fee · cohort
–
Net from the 1st payment (M0)
$
$
CPA from Ads Manager (cost per subscription / purchase) – or the modeled CPA of the Unit Economics Estimator. Leave blank to see LTV alone.
–
ROAS (net LTV ÷ CPA)
–
Payback month (net)
–
Target CPA (at ROAS goal)
–
Break-even CPA (ROAS 1.0)
Per plan – one subscriber on that plan, M13 horizon
Cumulative net revenue per subscriber, M0 → M12
Blended (solid) and each active plan; the yearly renewal lands in the last bucket (M13 → M12+). Dashed red line = your CPA – where the blended curve crosses it is the payback month.
Retention curves – share of subscribers still active, months 0–12
RevenueCat SOSA 2026 benchmark curves – the category median B and the two extremes E – against the dashed curve your current setup monetizes (benchmark × scenario, your typed anchors, or the early-stage fit). Store switch applies RC's 1st-renewal deltas; stores converge by the 3rd renewal.
Monthly plans
Weekly plans
Weekly LTV lives or dies in the first month: by M3 the median weekly cohort is already below 26%, by M12 – 1–2%. Monthly survives 6–14% to M12; Business is the outlier in both.
Store choice barely matters after the first renewal – early funnel quality dominates.
One structural exception: 32.3% of Google Play cancellations are involuntary billing failures vs 15.2% on the App Store [B, RC blog; the report card rounds them to 31% / 14% ↗] – grace periods and payment retries recover a chunk of it for free.
How these curves are built – sources, interpolation, what the equations mean
Benchmark series: RC SOSA 2026 – first three renewal rates by category B, M6 and M12 anchors B; the line between anchor points is log-log interpolation E.
Store deltasB: Google Play +3.5pp on the 1st monthly renewal, iOS +4.4pp on the 1st weekly; stores converge by the 3rd renewal, so the curves meet at M6. They come from the report's store-split charts, not from the public web page.
The extremesE: Business / Social & Lifestyle series are reconstructed from the extremes RC quotes for weekly and monthly plans (Business 61% vs Social & Lifestyle 42% on the 1st monthly renewal; for annual plans the extremes are Travel/Business vs Photo & Video).
Your setup (dashed): monthly – the calculator's three-anchor curve through your effective M1 / M6 / M12 (benchmark × scenario, or what you typed; AI factor ×0.7 on benchmark M6/M12); weekly – renewals #1–#3, then a two-phase tail through week-26 survival (RC 10% scaled by your first three renewals, or the value you typed) and Y1 at the RC ratio. In Fit from my first 2 renewals mode: monthly power law through your two renewals, weekly geometric tail at your 2nd renewal's churn.
Equations: S(m) – share still active in month m (M0 = everyone); a power-law fit per curve, least squares on log-log over months 1–12; R² = goodness of fit, 1.0 = the curve follows the formula exactly. The monthly power law is what the fit mode extrapolates from.
Why this shape and not another – design decisions §8 (§8.3 weekly tail, §8.4 fit mode).
How this calculator computes LTV – and what the alternatives are
Our method: a discrete payment schedule built from the retention curve
Subscriptions monetize at billing events, not continuously – so instead of integrating a daily activity curve, the calculator builds a month-by-month payment schedule per subscriber and sums it to M13. One model, three answers: LTV, payback month and the peak cash it takes to fund 12 months of spend (the budget line under the results).
First payment (minus refunds; at the 1st-period price when there is an intro offer), then each renewal weighted by the probability of surviving to it – the retention curve from the Retention curves tab: RC anchors, or a fit from your first two renewals.
Net LTV = the schedule ÷ (1 + VAT) × (1 − store or PSP fee), × (1 + upsell).
early-stage fit – monthly: S(m) = S₁·m−b, b = −log₂(r₂) · weekly: S(w) = r₁·r₂w−1 (churn stays at your 2nd renewal's level)
P
plan price (Pyearly – the yearly plan's price)
m
months since the first payment
S(m)
survival – the share of subscribers still active at renewal m
refund
refund rate, hits the first payment only
renewalM13
probability the yearly plan renews at month 13 (× a price ramp: ×1.0 up to $50, ×0.8 from $70)
VAT
sales tax inside the sticker price
fee
store commission (15 / 30%) or PSP fee (~5%)
upsell
ARPU uplift from welcome offers, plan upgrades, one-time purchases (0 if none)
S₁, r₂
survival after the 1st renewal (= your 1st renewal rate); your 2nd renewal rate
b
decay exponent – how fast the cohort melts
Two honest simplifications
Cut-off at M13 instead of discounting an infinite tail – 12 months of payments plus the first annual renewal; beyond that is extrapolation.
Fixed horizon rather than one fitted per cohort. A WACC-discounted sum is the academically correct move, and it starts to matter at $100k+/month spend with a 12+ month payback – there the time value of money quietly eats several percent of the margin and finance will (rightly) ask for the discounted version. At typical early-stage volumes and sub-year paybacks the cut-off is simpler and easier to defend.
The family of LTV methods (ordered by accuracy)
Method
How it works · when to use
Post-factum
LTV = Revenuecohort ÷ Sizecohort
Wait until a cohort fully dies, divide its total revenue by its size. The only method that measures rather than models – and useless in practice, because you can't wait years. Everything below is a forecast.
Divide everything
LTV = Total Revenue ÷ Total Users
All revenue ÷ all users, one arithmetic action. Fast and crude: mixes app life stages, counts users who haven't had time to pay, can't segment. A sanity check, not a model.
Lifetime × ARPDAU
LTV = Lifetime × ARPDAU, ARPDAU = Revenue ÷ DAU
Average lifetime (days until an inactivity window) × average revenue per daily active user. Simple, segmentable – but multiplies two averages from non-overlapping user sets and assumes ARPDAU never changes.
Fit the curve through known retention points (D1/D7/D28…), lifetime = the area under it. Accurate, gives a retention forecast as a bonus. Our method is its subscription-specific cousin: with discrete billing the integral collapses into a sum over renewal events – fewer assumptions, same idea.
Track cumulative ARPU of a cohort at D7/D14/D28…, fit the curve, read LTV at the horizon – or add discounting and take the asymptote. Skips retention entirely; great when monetization is many small purchases.
R(t)
retention on day t; A, B, C – fitted curve coefficients (least squares)
Lifetime
average days a user stays = area under R(t)
ARPDAU, DAU
average revenue per daily active user; daily active users
cumARPU(t)
cumulative revenue per cohort user by day t; t* – the horizon you read LTV at
CFi, WACC
cash flow of period i; discount rate (ask your finance people) – discounting makes the infinite tail summable
Why the business model dictates the method
Subscription app (this calculator): revenue = few large discrete payments → model the payment schedule from renewal/retention curves. ARPDAU-style methods waste the structure the billing system gives you for free.
F2P game: revenue = a stream of micro-purchases spread over daily sessions → retention-curve integral × ARPDAU, or the cumulative-ARPU fit. There is no renewal event to anchor on – daily activity IS the monetization clock.
E-commerce: LTV = average order value × purchase frequency × margin over the repurchase window – a third clock again (orders), a third method.
The golden rule regardless of method: segment. One blended LTV hides more than it shows – compute per plan, per platform, per geo, per acquisition channel (this whole calculator is that rule applied: vertical × geo × plan).
Consistency checks: the built-in self-test (button in the footer, or ?test=1) runs 24 assertions live in your browser – anchor hits, monotonicity, tab-to-tab consistency, hand-recalculated snapshots, guards – on exactly the code that computes your numbers. They prove the model is internally consistent, not that the benchmarks are right; for that, every field carries its source and confidence tag.
What the calculator deducts by default – the rate of the acquisition geo, blended where a region mixes countries E; override it in the VAT/GST field whenever your payer mix differs.
Two different worlds depending on who the merchant of record is – the store or you.
a2a – Apple / Google are the merchant of record
In most countries the sticker price includes VAT. At every transaction the store first strips the VAT out, remits it to the tax authority itself (you never touch it), and only then takes its 15/30% commission from what's left. Your monthly payout is already net of both.
Worked example – $59.99 yearly plan:
Turkey (VAT 20%): $59.99 ÷ 1.20 = $49.99 → × 0.85 (SBP) = $42.49 to you – 71% of the sticker.
US (no VAT in price): $59.99 → × 0.85 = $50.99 to you – 85% of the sticker. Sales tax, where applicable, is added on top at checkout and also handled by the store. Both users saw the same $59.99 on the paywall and paid the same – but your proceeds differ by 17% purely because of where the transaction is taxed.
When: deducted per transaction, automatically. Refunded transactions return the VAT too. You do not register, file or remit anything for store sales – but you also can't optimize it away.
w2w – you are the merchant (or you buy that service)
On web billing the stores are out of the picture and the tax obligation lands on the merchant. Two routes:
Stripe (processor): you are the merchant of record – you must register where you cross thresholds, collect at the buyer's local rate (Stripe Tax automates it for +0.5%/txn) and remit. In the EU, consumer prices must be displayed VAT-inclusive, so the tax comes out of your sticker just like in the stores.
Paddle (merchant of record): Paddle plays the Apple role – collects and remits everywhere, absorbs the compliance, charges a higher base fee (~5–6% effective).
Net-proceeds shape is the same in all cases: proceeds = price ÷ (1 + VAT) × (1 − fee). Only the fee differs: 15/30% store vs ~4.4–6% web.
Which country's VAT applies? The storefront, not the ad targeting
VAT is set by the payer's storefront country – where the Apple ID / Google payment profile is registered – not by where your ads run. But Meta targets people by physical location, and a person's storefront almost always matches where they live. So with tightly geo-targeted campaigns the two coincide 90%+ of the time: buy US → US storefront → ~0% · buy Germany → DE storefront → 19%. That's why the calculator defaults the VAT field to the acquisition-geo rate [E].
Where the match breaks – set a blended rate manually:
Expats: buying Gulf traffic yields a visible share of IN/PH-storefront accounts – their VAT (and prices) follow their home storefront.
Storefront arbitrage: the Turkish storefront is popular with non-residents chasing cheap local prices – TR-storefront payers aren't necessarily people you bought in Turkey.
Advantage+ / multi-geo campaigns without country limits: Meta spreads budget across countries, and the payer mix becomes genuinely unpredictable.
Blended example: 60% US payers + 25% Western Europe (~20%) + 15% Turkey (20%) → 0.25×20 + 0.15×20 ≈ 8% blended – enter that in the VAT/GST field of the Calculator.
VAT / GST rates deducted from the sticker price, key countries
Standard VAT / GST on digital services as the stores deduct it from the sticker price. ✓ = the rate appears in Apple's or Google Play's own tax notices (checked Sep 2026); the rest are the countries' standard rates [E] – they change, so verify against Apple's Exhibit B / Google Play tax documentation before relying on them. Grouped the way the Geo selector is; one country per row.
Americas
Rate
North America
United States
0% (sales tax added on top)
Canada
0–5% (GST added on top in most provinces)
LatAm – Spanish-speaking
Mexico
16% ✓
Argentina
not deducted by the stores ✓ – 21% VAT plus perception taxes are added on top by the card issuer
Colombia
19% ✓
Chile
19% ✓
Peru
18% ✓ (since Feb 2025)
Brazil
Brazil
~9.25% withholding mix (CIDE/PIS/COFINS, store-dependent) + IOF 3.5% on Apple since Aug 2025 ✓
Turkey · Gulf
Rate
Turkey
20%
Saudi Arabia
15% ✓
United Arab Emirates
5% ✓
Qatar
0% – no VAT; not a store-collected country
India · SEA · APAC
Rate
India
18% GST
Pakistan
not deducted by the stores ✓; selling direct (w2w): provincial sales tax on services 13–16% [E]
Indonesia
11% ✓
Philippines
12% ✓ (since Aug 2025)
Vietnam
10% ✓ (since Aug 2025)
Thailand
7% ✓
Malaysia
8% service tax ✓
Singapore
9% GST ✓
Japan
10% JCT ✓ (platform-collected since Apr 2025)
South Korea
10% ✓
Australia
10% GST ✓
New Zealand
15% GST
Europe
Rate
United Kingdom
20%
Ireland
23%
Germany
19%
Austria
20%
Switzerland
8.1% ✓
France
20%
Belgium
21%
Netherlands
21%
Spain
21%
Portugal
23%
Italy
22%
Poland
23%
Czechia
21%
Romania
21% ✓ (since Aug 2025)
Greece
24%
Sweden
25%
Denmark
25%
Norway
25%
Finland
25.5%
Design decisions – the calculations, and why this way and not another
The companion document to the Unit Economics Estimator – and to this calculator, whose LTV engine is the estimator's (§8–§9): for every block – what is computed → formula → why → what was rejected → status. Every number in it is the one in this tool's code, and the dated decision log is at the end. The method notes under the results link straight into its sections. Open the full document →
Every benchmarked field starts from a public industry number; the moment you type your own value it is used as is – no scenario, AI or web-cohort factor is applied on top. This tab lists, for every input, the definition the model uses (so that a similar-looking metric does not get pasted in), the report to read, the cut and history that make the number trustworthy, and the trap. It is the LTV part of the estimator's checklist – the acquisition-funnel fields live there.
Notation. The calculator has 13 numeric inputs on the retention and money side (B benchmark · E estimate · A assumption until you overwrite them) plus your plans, prices, shares and CPA, which are never benchmarked.
0. The systems a subscription app needs for this (the map)
Layer
Systems · what it gives the calculator
Ads
Systems Meta Ads Manager (plus Google Ads / TikTok where used)
Gives spend, impressions, CPM, link clicks, unique outbound clicks, landing page views – by campaign / country / OS / month; the optimization goal of each campaign (AEO / MAI / VO)
Attribution
Systems MMP – AppsFlyer / Adjust / Singular; SKAN postbacks on iOS
Systems App Store Connect (App Analytics + Financial Reports), Google Play Console (Store performance, Earnings)
Gives impressions → product page views → downloads (store CVR) by country and source; proceeds after commission and tax by storefront; the commission tier (15 / 30%)
Subscriptions
Systems RevenueCat / Adapty / your own billing backend (+ App Store Server Notifications, Google RTDN)
Gives trial starts, trial→paid, renewals by cycle, refunds, intro offers, MRR by cohort; a customer list with the first-payment date and plan
Gives checkout sessions initiated vs paid, net proceeds, fees, refunds, disputes, VAT (Stripe Tax, or Paddle as merchant of record)
Data warehouse
Systems BigQuery / Snowflake / ClickHouse + ETL (RevenueCat → BQ, MMP raw data, Stripe → DWH)
Gives the one place where spend, installs and payments meet in a single cohort; without it the join is a spreadsheet – fine once, not as a process
Finance
Systems Apple Financial Reports, Google Play Earnings, Stripe payouts, the books
Gives net revenue, VAT by country, commission, exchange rates – the check that "revenue" in the subscription tool and on the bank account are the same number
Without an MMP and a subscription analytics tool the cost side can still be computed from Ads Manager and the store reports, but everything after the install and the whole LTV stay on benchmarks. Without a warehouse the cohorts are assembled by hand – half a day per geo × platform.
1. Setup – the selectors
Selector
What to pick · where to find it · trap
Vertical
Pick the store category
Where App Store Connect / Play Console – the app's category
Trap the store category can differ from how the product monetizes (a quiz-funnel H&F app is still H&F)
Geo
Pick where you acquire users
Where Ads Manager: spend by country over the last 3 months
Trap one geo per run; a regional mix – run the largest regions separately
Scenario preset
Pick Reasonable
Where not needed once your data is in – the preset only moves the remaining benchmarks
AI product
Pick yes / no
Trap the Adapty modifiers apply to benchmarks only, never to typed values
Billing
Pick in-app / web checkout
Where where the subscription is sold: the stores, or Stripe / Paddle behind a quiz funnel
Trap the web-cohort ×0.89 [B, Adapty] applies to benchmark retention only – typed or fitted renewals are used as is; the fee follows the choice (15 / 30% store vs ~5% PSP)
Store commission
Pick 15 / 30 / PSP ~5%
Where App Store Connect → Agreements (Small Business Program, $1M/year threshold); Play Console – 15% on the first $1M; Stripe / Paddle – your plan
Trap the most common mistake: revenue in the subscription tool is gross while the company thinks net
Retention input
Pick Benchmark / Fit
Where do you have 6–12-month cohorts?
Trap fit mode is for apps younger than six months
2. LTV inputs – retention and money
Field
Definition in the model · source · granularity / history · trap
Monthly retention M1
Definition share of monthly subscribers who pay the 1st renewal
Source RevenueCat → Charts → renewal rate by period; Adapty → Retention; or the warehouse from transaction data
Cut · history by first-payment cohort × geo × OS; 3+ cohorts
Trap measure from the first payment (after the trial), not from the trial start; exclude sandbox
Monthly retention M6 / M12
Definition share still active at the 6th / 12th renewal
Source same
Cut · history cohorts aged 7 and 13 months
Trap no such cohorts – keep the benchmark or switch to fit mode; do not extrapolate by hand
Yearly renewal at M13
Definition share of annual subscribers who pay the 2nd year
Source subscription tool renewals on the annual plan; App Store Connect → Subscriptions → retention
Cut · history cohorts older than 13 months
Trap an app younger than a year has no such number – it is a benchmark by definition
Weekly renewals #1 / #2 / #3+
Definition weekly-plan renewals by cycle
Source RevenueCat → renewal rate by period (weekly); the warehouse
Cut · history 12+ weeks of cohorts
Weekly survival at week 26
Definition share of weekly subscribers still paying at week 26
Trap enter revenue you actually collect, not plans for it
VAT / GST
Definition tax inside the sticker price, by the payer's storefront
Source Apple Financial Reports (proceeds by storefront, already net of tax and commission); Play Earnings (tax column); Stripe Tax
Cut · history the storefront mix weighted by spend
Trap the targeted country ≠ the payer's storefront (expats, store arbitrage) – take the real mix from the payouts
3. Plans & prices, your CPA – the only things the tool cannot know
Field
Source · trap
Price weekly / monthly / yearly
Source App Store Connect → Subscriptions → price tier by storefront; Play Console; Stripe products
Trap the price of the storefront you buy in, not the US default; enter the gross (sticker) price – the model removes VAT and the commission itself
1st-period price (intro offer)
Source intro offer settings in the stores; Stripe coupons / trial price
Trap quiz funnels almost always have one – without it the LTV of the first payment is overstated
Share of subscriptions
Source subscription tool: new subscriptions by product over 3 months (counts, not revenue)
Trap the dashboards show revenue shares; the table wants subscription shares – annual plans always look bigger in revenue
Your CPA
Definition cost per new paying subscriber (not per trial, not per install)
Source Ads Manager: spend ÷ subscriptions (purchase / start-trial→paid events) for the campaigns that carry the geo you selected and the platform whose cohorts you typed; MMP cohort report spend → paid subscribers; or the modeled CPA of the Unit Economics Estimator
Cut · history same geo × platform as the retention you typed; 8+ weeks so the trials have converted
Trap cost per trial ÷ trial→paid is the CPA, cost per trial is not; SKAN / attribution windows under-report iOS conversions – take the MMP or the subscription tool's cohort, not the ad platform's own count
Monthly ad budget
Source the media plan
Target ROAS
Source the company's financial model: how much net LTV per $1 of CPA the margin and the payback need
Trap 1.3 is the tool's default; a company usually has its own number – or none, which is the first question to ask
Every benchmarked field of the calculator shows which of these it is – B benchmark, E estimate, A assumption – until you overwrite it. The honest way to use the tool on your own data is to replace what you can measure and leave the tag on what you cannot.
Sources · public benchmarks only (RevenueCat SOSA 2026 and RC's renewal-rate and billing-churn posts, Adapty 2026), re-verified against the live pages on 4 Sep 2026 – see the why? on each field and verify before big bets. Fields tagged A are documented assumptions pending research. No client data anywhere in this tool. Where each input lives in your own systems – Reference › Data sources.