Unit Economics Calculator

Does this subscription app's growth math ever close?

Set your plans and prices; each of the other 24 benchmark inputs (22 in the web funnel) starts from public data, for any of 6 verticals and 6 geos (every one of them, dated and sourced) – override anything you actually know.
The horizon is M13: 12 months of payments plus the first annual renewal, with VAT and the store or PSP fee deducted before LTV.
35 self-tests ship with the page and run in your browser at ?test=1.
Scope: subscription apps only – app→app and web→web quiz funnels, Meta acquisition, hard paywall; ad-monetized (in-app advertising), hybrid and commerce economics are out of scope.
Only need what a subscriber is worth? The LTV Calculator is this tool's LTV engine without the funnel – bring your own CPA.
Buying iOS installs? The SKAN Schema Builder builds the conversion schema for the same kind of app.
Tags: B benchmark · E estimate · A assumption.

Terms used on this page

AEO – app event optimization: Meta bids for an in-app event, here the trial start · MAI – mobile app install optimization · VO – value optimization, bids for purchase value · SBP – Apple's Small Business Program, 15% commission instead of 30% · M13 – the horizon: 12 months of payments plus the first annual renewal in month 13 · P25 / P75 – the 25th / 75th percentile of the benchmark panel; the median (P50) is the default · CPT – cost per trial start · CPA – cost per subscriber.

How to use – 30 seconds

Pick your vertical and geo – every benchmark fills itself from public data (RevenueCat, Adapty, Lebesgue, Interact…). The install→trial benchmark defaults to hard-paywall apps; switch the base to "All apps" for the raw RC panel median.
Enter your plans and prices – the only thing the tool can't know.
Press Calculate after every change (the default case is already computed). Override any field you have real data for – it turns blue = "my data" and is used as-is: season, optimization-event, platform and paid-traffic factors are not applied on top. Where each number lives in your own systems – Reference › Data sources.
The scenario preset swings every remaining benchmark at once – conversions and retention to P25 / P75, CPM the opposite way, so Pessimistic = every stage against you. Ten stages at P25 compound into far worse than "a P25 app". Early stage? Switch retention to Fit from my first 2 renewals. Show a colleague your exact setup – Copy share link.

Questions this tool gets asked

Which apps is this for, and which is it not for?
Subscription apps only, in two funnels: app to app (store install) and web to web (quiz funnel, web checkout), acquired on Meta, behind a hard paywall. Ad-monetized apps (in-app advertising), hybrid models and commerce economics are out of scope.

What does M13 mean?
The horizon the calculator works to: 12 months of payments plus the first annual renewal, which falls in month 13. LTV, the payback month and the peak cash line are all computed to that point.

Where do the numbers come from if I enter nothing?
Everything except your plans and prices starts from a public benchmark – 24 inputs in the app funnel, 22 in the web funnel, for any of 6 verticals and 6 geos, from named sources such as RevenueCat, Adapty, Lebesgue, Apptweak, Adjust and Interact, each linked where it is used and all of them listed on the benchmark snapshots page. The median of the panel is the default; the scenario preset moves every remaining benchmark to P25 or P75 at once.

What happens when I put in my own number?
The field turns blue – my data – and is used as it is: the season, optimization-event, platform and paid-traffic factors are not applied on top of it. Where each of these numbers lives in your own systems is listed under Reference, Data sources.

How is this different from the LTV Calculator?
The LTV Calculator is this tool's LTV engine without the acquisition funnel: it answers what one subscriber is worth and you bring your own CPA. This tool starts from impressions and CPM and computes the funnel down to CPA itself.

Are VAT and the store commission taken out?
Yes. Net LTV is the payment schedule divided by (1 + VAT), times (1 – the store or PSP fee), times (1 + upsell). On store billing Apple or Google strip the VAT out first and take their 15 or 30% from what is left; on web billing you are the merchant and the PSP fee applies instead. The VAT rate defaults to the geo you acquire in and can be overridden.

Setup

Platform / device

Vertical

Benchmark base (install → trial)

Geo (where you acquire users)

Scenario preset

Optimization event

Paywall trial

Trial length

Seasonality (month)

AI product

Store commission

Plans & prices (your data – required; mix must sum to 100%)

Plan	Price, $	1st-period price, $ (intro offer – optional)1st price, $	Share of subscriptions, %Share, %
Weekly	$	$	%
Monthly	$	$	%
Yearly	$	$	%

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.

Show sources & methodology for all fields ▾

Acquisition funnel

LTV inputs (M13 horizon)

Retention input

Results

Press Calculate to compute the results with the current inputs.

…

–

Blended net LTV M13

–

Modeled CPA (cost per subscriber)

–

ROAS (net LTV ÷ CPA)

–

Payback month (net)

–

Modeled CPI (blended w/ organic)

–

Target CPA (at ROAS goal)

–

Target CPT / CPI (per trial / per install)

Target ROAS (net LTV ÷ CPA)

Monthly ad budget, $$

How to read this tab

Per 100,000 impressions, iOS vs Android, on your current Setup and overrides (a2a and w2w keep separate ones). Healthy band = P25–P75 for your geo × vertical; ✓ / ⚠ marks where your value sits.
Money check uses each funnel's own plumbing: a2a – the store fee you selected, no cohort penalty; w2w – the PSP fee (~5%) plus the web-cohort ×0.89 on benchmark retention [B, Adapty]. Same prices, so the two ROAS figures are directly comparable.
Net LTV per column = the calculator's headline re-based by the ARPU factor (iOS ×1.0 · Android ×0.8 · Blended ×0.9 [A]); store CVR is per store in each column whatever the Setup selector says. For w2w, iOS/Android means the targeted device (split provisional [A]); stages without a published OS split show the same value in both columns.

a2a funnel per 100,000 impressions – iOS vs Android

w2w funnel per 100,000 impressions – iOS vs Android devices

Compare with the other funnel on the same Setup

Assumptions behind the numbers – every constant as in the code

Every number below is what the code uses today (constants in CONFIG, GEO, VERT, PLAT, MAI); the reasoning behind each choice lives in Design decisions; every source was re-checked against its live page on 4 Sep 2026. Scenario presets move conversion and retention fields P25 → P75 and the CPM the opposite way.

E CTR 1.2 / 1.6 / 2.0% – our band for video/UGC app-install creatives; the public panels bracket it without a creative-type split (Superads industry average 0.90–1.10%, Triple Whale e-commerce median 2.39%) – no OS split.
A Click → store page 85 / 90 / 95% – in-app browser → deeplink losses; no public data.
B/E Store CVR per store, per category – App Store: SplitMetrics category medians, page view → install with dropped visits removed (H&F 18.52%, Social 11.36%, Entertainment 8.6%, Education 6.75% [B]; via AppScreenshotStudio 2026; AppTweak's panel runs ~1.5× higher – H&F 30.8% in H1 2024 – and can exceed 100% because installs also come straight from search results); Google Play: AppTweak H1 2024 category figures as cited by Adjust (H&F 23.2%) and Adapty (Education 30.4%) [B] – AppTweak's own page now carries 2025 store averages only; Productivity / Photo & Video / Utilities and Music/M&E on both stores interpolated [E]. Blended = the average of the two. Denominators differ between stores, so no cross-store "bonus" is applied.
A Paid-traffic factor ×0.7 / 0.8 / 0.9 on store CVR – paid converts below the blended store benchmarks; no public split.
E Organic uplift 10 / 25 / 40% extra organic installs per paid install – practitioner range; TUNE's 2017 figure (1.5 organic per paid, dataset not described) is far higher and not representative of hard-paywall subscription apps. Applied to CPI (labeled "blended w/ organic"); set 0 for strict paid-only ROAS; not on web.
B Install → paywall view 45 / 56 / 85% – Superwall (Nov 2022): platform average of 56% of users ever seeing a paywall; 85% is its recommended install→paywall view target – a hard paywall in onboarding should sit near the top of the band. The first-open / onboarding / registration rows above are display sub-stages of this composite (iOS first open ×0.87 [E], Android ×0.775 [E, UXCam citing Adjust – 20–25% of Android installs never open]; onboarding ×0.95 [A]; registration ×0.80 [E]) and do not enter the math.
B/E Benchmark base for install → trial: hard-paywall apps (default). RC's category medians mix every access model and most panel apps are freemium, where a minority of installs ever sees a paywall; RC 2026 reports hard-paywall apps converting 10.7% of downloads to paid (top quartile above 20%) vs 2.1% for freemium [B] – above the all-apps top quartile of the best categories (H&F 6.2%). This tool models hard paywalls only, so its default shifts the RC install→trial band one quartile up (H&F: 5.0 / 6.9 / 16% → 6.9 / 16 / 37%); the size of the shift is [E]. "All apps" in Setup gives the raw panel band.
E Paywall view → trial start – derived: RC install→trial band (per the benchmark base above) for your vertical × geo factor (WE ×0.70, LatAm/TR ×0.50, Gulf ×0.70, IN/SEA ×0.45) ÷ the install→paywall benchmark of the same scenario. So the stage product reproduces the RC composite by construction; the cross-check only fires on your overrides.
B Trial → paid by vertical × geo × trial length (RC: H&F 30 / 37.7 / 51.4%; geo factor WE ×0.87, TR ×0.65, IN/SEA ×0.44 …; 3-day trial ×0.68 – RC's ≤4-day bucket 25.5% vs 37.4% for 5–9 days) – store parity [B, RC 32.6% iOS vs 32.5% Play].
A Trial share of new subscriptions 85 / 90 / 95% – no public benchmark.
E No-trial paywall: direct purchases ×0.4 of the trial-start rate – Adapty 2026 onboarding paywalls: 0.82% without a trial vs 1.35% with one (conversion per paywall show; denominator not defined) = ×0.6, a ceiling since apps running no-trial paywalls are self-selected; A/B practice lands at 0.3–0.5. Consequence: a trial pays for itself when trial→paid ≥ ~36% (×0.4 × trial share), and the calculator says so explicitly.
A/B Platform factors (a2a): CPM iOS ×1.1 / Android ×0.95 / Blended ×1.0 [A – most of the "cheap Android" is geo mix, modeled by the Geo selector]; paywall stage iOS ×1.30 / Android ×0.45 / Blended ×1.0 [B, RC SOSA 2026 store split: download→paid at day 35 is 2.6% on iOS vs 0.9% on Android with trial→paid at parity (32.6% vs 32.5%), so the gap sits at the funnel entrance; the global median of the same metric, 2.0%, implies a ≈65/35 iOS/Android blend and the factors are the ratios to it – medians do not mix linearly and the cross-category gap is applied to every vertical alike [E]]; trial→paid ×1.0 (store parity) [B, RC]; ARPU per subscriber Android ×0.8 / Blended ×0.9 [A – RC publishes no revenue-per-install split by store; the mechanism is documented: 32.3% of Play cancellations are involuntary billing failures vs 15.2% on the App Store] – ARPU is used on this tab only, the calculator takes your prices as entered.
A No OS split on install→paywall, retention, renewal, refunds, plan mix – none is published; the store deltas on the first renewal shown on the Retention curves tab are the only split RC gives.
E Optimization event – the benchmarks are AEO/organic-basis: the CPM panels come from conversion-optimized campaigns and RC's install→trial is measured on the traffic real apps get (AEO on trial start + organic), so AEO on trial start (default, the subscription-app standard) applies ×1.0 to price and intent. MAI: impressions ×0.4 the price, installs ×0.4 the paywall conversion [E, practitioner consensus "AEO beats MAI ×2.5–4 on install→trial"; the MAI/AEO/VO framing is Mobile Dev Memo's] – mirrored, so MAI ≡ AEO on cost per subscriber: the model claims no winner it cannot source and the pair does not move with the scenario preset. Purchase optimization with a trial: AEO price for MAI-quality installs (the event fires days after the click).
E Seasonality: Jan–Feb ×0.80 · Mar–Jun ×0.96 · Jul–Aug ×0.88 · Sep–Oct ×1.08 · Nov ×1.33 · Dec ×1.40 – January–February (−20%) and the holiday peak (+40%) are the two figures Bïrch states in words (US campaigns, 2021–2023); the other months are read off its chart. Multiplies benchmark CPM, never a manual one.
B/A w2w: quiz stages LP→start 30 / 38 / 40% [A, no public benchmark], start→finish 50 / 60 / 65% [B, Interact], finish→email 60 / 65 / 75% [B, derived from Interact's start→lead 37.6–44.9% ÷ start→finish – an earlier version used the start→lead figure itself as finish→email, understating the funnel by ×1.5]; paywall→checkout 5 / 10 / 15% [A, Adapty's web paywalls convert ×0.69 of in-app: 1.10% vs 1.60%]; checkout completion 25 / 40 / 60% [E, practitioner band; Stripe publishes a +22.3% conversion lift from offering Apple Pay, not absolute completion rates]; web cohort LTV ×0.89 B [Adapty: $35.80 vs $40.10 one-year LTV; whether those are gross or net of store fees is not stated – applied to gross here, fees deducted separately] – per plan, and only while that plan's retention is a benchmark: typed anchors or fitted renewals already contain the web cohort's behavior, so no ×0.89 on top; optimization events purchase ×1.0 / initiate checkout CPM ×0.85 & intent ×0.9 / lead CPM ×0.6 & intent ×0.8 [A].
A w2w device split: CPM iOS ×1.15 / Android ×0.85 (device-targeting price), checkout completion iOS ×1.05 / Android ×0.95 (Apple Pay effect), ARPU iOS ×1.0 / Android ×0.9 / Blended ×0.95 – placeholders, no public data.
B/E Retention: monthly anchors M1 50 / 61 / 68% [E, our band; RC category medians of the 1st monthly renewal span 42–61%], M6 14 / 20 / 26% and M12 6 / 10 / 14% [B, RC SOSA 2026 report], log-log between anchors; weekly renewals 35/46/58 [B, RC: 1st weekly renewal 35–58%] → 67/71/75 [E, report chart] → 74/80/85% [B, RC: 3rd renewal converges to 74–91%], then a two-phase tail through RC anchors M6 ≈ 10% and Y1 ≈ 1.5% [B, report], scaled by your first three renewals [E] – the week-26 anchor is an editable field (the least certain number in weekly LTV; real weekly cohorts with strong early renewals can keep churning at a near-constant weekly rate instead of following RC's slowdown), and the weekly early-stage fit is a geometric tail at your 2nd renewal's churn, not a power law; intro offers: the first payment at the 1st-period price, renewals at the plan price; yearly renewal 22 / 30 / 40% [B, RC: 1st annual renewal 23–40% across categories; Y1 27–28%] × a price ramp ×1.0 at $50 → ×0.8 at $70 [E, report price-tier chart: high-price 1st-renewal churn 37% vs 24%]; refund 2.5–4.7% by vertical on the first payment only [B, RC report]; AI apps: install→trial ×0.487 [B, Adapty 5.31% vs 10.92%] and monthly M6/M12 anchors ×0.7 [E – RC: AI apps churn ~30% faster / retain 36% worse over 12 months].

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 deltas B: 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 extremes E: 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).

LTV_M13 = P·(1−refund) + Σ_m=1…12 P·S(m) + P_yearly·renewal_M13

net LTV = LTV × (1+upsell) ÷ (1+VAT) × (1−fee)

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 (P_yearly – 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
renewal_M13: 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 = Revenue_cohort ÷ Size_cohort 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.
Retention-curve integral (Bottoms Up)	R(t) = A·e^−Bt + C, Lifetime = ∫₀^T R(t)dt, LTV = ARPDAU × Lifetime 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.
Cumulative ARPU fit (Top Down)	cumARPU(t) ≈ A·ln(t) + B, LTV = cumARPU(t*) or PV = Σ CF_i ÷ (1+WACC)ⁱ 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
CF_i, 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 × platform × plan).

Consistency checks: the built-in self-test (button in the footer, or ?test=1) runs 35 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.

The Bottoms Up / Top Down framing and spreadsheet mechanics: Eric Seufert (Wooga) – LTV spreadsheet models.

How VAT works for subscription apps

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%

Running this calculator on your own data – where each input comes from

Jump to: 0. Systems map · 1. Setup selectors · 2. App → App funnel · 3. Web → Web funnel · 4. LTV inputs · 5. Plans & prices

Every benchmarked field of the calculator starts from a public industry number; the moment you type your own value it is used as is – no seasonality, optimization-event, platform or paid-traffic 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 system and report it comes from, the granularity and history that make the number trustworthy, and the trap that most often breaks it.

Notation. The calculator has 35 numeric inputs in App → App mode; 24 of them carry a benchmark tag (B benchmark · E estimate · A assumption), the rest are your prices, plan shares, budget and target. Granularity – the cut at which the number has to be measured for the model to be honest: at least geo × platform (iOS / Android) × month; for retention – by plan and by cohort of the first payment. History – how many months of data it takes before the number is signal rather than noise.

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 Gives installs by campaign × geo × platform, click→install, organic installs, cohort reports "spend → trials → paid"
Stores	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
Product	Systems Amplitude / Mixpanel / Firebase / PostHog Gives events open → onboarding → registration → paywall_view → trial_start / purchase; for web→web – LP view, quiz start / finish, email, checkout
Web payments (w2w)	Systems Stripe / Paddle / Braintree 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
Platform / device	Pick iOS, Android or Blended Where Ads Manager: split by OS; MMP: install shares Trap "Blended" only makes sense for a real mix; at 80%+ iOS, run iOS and Android separately
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)
Benchmark base	Pick Hard-paywall / All apps Where product: is there a path to content without a paywall? Trap irrelevant once you type your own install→trial – the field is overwritten
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
Optimization event	Pick AEO trial / MAI / Purchase Where Ads Manager: the optimization goal of the campaigns that carry ≥70% of spend Trap mixed optimization goals – run one branch per goal
Paywall trial	Pick with / no trial Where product: is there a trial on the main paywall? Trap some apps trial only on Android or only on the annual plan
Trial length	Pick 3 / 7 days Where App Store Connect / Play Console – intro offer settings
Seasonality	Pick the launch month Where the media plan Trap a typed CPM is used as is – seasonality and the optimization premium are not added; the selector matters only while the CPM is the benchmark
AI product	Pick yes / no Trap the Adapty modifiers apply to benchmarks only, never to typed values
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. App → App funnel – from impression to subscriber

Field	Definition in the model · primary source · granularity / history · trap
CPM – base	Definition cost per 1,000 impressions; the model adds seasonality and the optimization premium to the benchmark and takes a typed value as is Source Ads Manager: spend ÷ impressions × 1,000 Cut · history geo × OS × month; 3 months Trap type the CPM of the month and of the campaigns (optimization goal) you are modeling – nothing is layered on top
CTR – impression → click	Definition link clicks ÷ impressions Source Ads Manager: link CTR (not "CTR (all)") Cut · history geo × OS × month Trap "CTR (all)" counts likes and expands – 1.5–2× too high
Click → store page	Definition share of clicks that reach the store page Source MMP clicks (or App Store Connect impressions from the App Referrer source) ÷ Ads Manager unique outbound clicks Cut · history geo × OS Trap often >100% because the counters differ; the calculator caps at 100%. No data – leave 90% [A]
Store CVR (page → install)	Definition product page views → first-time downloads Source App Store Connect → App Analytics → Metrics: Product Page Views and Total Downloads by source type App Referrer / Web Referrer (paid traffic), CVR = downloads ÷ page views; Play Console → Store performance → Store listing acquisition report: visitors → acquisitions by UTM / channel Cut · history geo × OS × month; 3 months Trap App Store Connect's own "Conversion Rate" is impression-based – a different metric; the stores count differently (Apple – page view → download, Google – visitor → installer), never mix them
Paid-traffic factor	Definition multiplier on the store CVR for paid traffic Source not needed when the store CVR is taken from a paid source – enter 100 Trap keep 80% [A] only with a blended store CVR
Install → paywall view	Definition share of installs that see the paywall (composite of open + onboarding + registration) Source product analytics: users with a paywall_view event ÷ installs (MMP), same cohort Cut · history geo × OS × install week; 8+ weeks Trap MMP installs ≠ store installs (±10–20%); the denominator must come from the same system as the CPI
Paywall view → trial start	Definition trial starts ÷ unique paywall views Source RevenueCat / Adapty (trial starts) + analytics (paywall views) Cut · history by install cohort; 8+ weeks Trap if the subscription tool counts a trial start by transaction and analytics by tap, they disagree – reconcile on one week
Organic uplift	Definition extra organic installs, % of paid installs Source MMP: organic ÷ paid installs in the same geo × OS and period; better – a geo holdout or weeks with vs without spend Cut · history geo × OS × month; 3 months Trap brand and ASO installs are not "uplift"; in doubt, 0 – that is an honest paid-only ROAS
Trial share	Definition share of new subscriptions that start with a trial Source subscription tool: new subscriptions with vs without a trial Cut · history by plan; 3 months Trap not applied when the paywall has no trial
No-trial paywall factor	Definition direct purchases as a share of the trial-start rate Source needed only for the "trial vs no trial" comparison – a paywall A/B test (Superwall, Adapty) Trap without your own A/B, keep the 40% [E] benchmark

3. Web → Web funnel – quiz and web checkout

Field	Definition · source · trap
CPM (web)	Definition as above, for web campaigns Source Ads Manager: campaigns optimized for purchase / lead Trap US health quiz funnels run $40–100+; the $15 benchmark is far below
CTR (web)	Definition link clicks ÷ impressions Source Ads Manager
Click → LP view	Definition LP views ÷ unique outbound clicks Source GA4 / Mixpanel page_view on the LP ÷ Ads Manager unique outbound clicks Trap Meta's landing page views are sessions, its clicks are unique: >100% is normal – enter 100
LP → quiz start	Definition quiz_start ÷ LP views Source quiz analytics (Amplitude or your own tracking)
Quiz start → finish	Definition quiz_complete ÷ quiz_start Source same
Finish → email submit	Definition emails captured ÷ quiz_complete Source analytics + the ESP (Klaviyo / Customer.io) – reconcile with new contacts Trap no email step – enter 100
Paywall → initiated checkout	Definition checkout sessions ÷ paywall views Source Stripe Checkout sessions created ÷ paywall_view
Checkout completion	Definition paid ÷ initiated Source Stripe: sessions completed ÷ created (or Paddle) Trap dedupe test and repeated sessions of one user
Retention (monthly / yearly / weekly)	Definition as in section 4, on the web subscriptions Source Stripe Billing / RevenueCat Web / your billing Trap the ×0.89 web-cohort factor in the calculator is for benchmarks only; typed renewals are used as is

4. 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 Source warehouse / customer list: cohorts aged 6+ months Trap without 6-month cohorts – the 10% [E] benchmark, the least certain number in weekly LTV
My 1st / 2nd monthly renewal (fit mode)	Definition the first two renewals of the monthly plan Source subscription tool – the first two or three cohorts Cut · history 2–3 months of data Trap a mode for young apps; a two-point power law is optimistic – the calculator says so
Trial → paid	Definition share of trials that convert to paid Source RevenueCat → trial conversion (by trial-start date, cancellations during the trial included); Adapty Cut · history by plan × geo × OS; 8+ weeks Trap take a cohort whose trials have already ended – open trials in the denominator understate it
Refund rate	Definition refunds of the first payment Source RevenueCat → refunds; App Store Connect → Sales and Trends (refunds); Play Console → Financial reports Cut · history 3 months Trap renewals are rarely refunded – this field is about the first payment only
Upsells & offers	Definition extra ARPU on top of base subscriptions Source subscription tool / Stripe: one-time purchases, plan upgrades, welcome offers Cut · history 3 months 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

5. Plans & prices – the only thing 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
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, collected July 2026 and re-verified against the live pages on 4 Sep 2026; the data itself is of mixed vintage (RC / Adapty / Lebesgue / Triple Whale / RocketShip 2026, AppTweak H1 2024, Bïrch 2021–23, Superwall 2022, TUNE 2017) – 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.

✓ Run the built-in self-test 35 assertions, live in your browser

All sources – 24 links

RevenueCat SOSA 2026 · Adapty SOIS 2026 (paywall, trial, web and AI figures are from Adapty's paywall blog post below) · Adapty paywall data · Lebesgue CPM by country · ADCostly (TR) · Bïrch seasonality · Superads CTR · Triple Whale · AppTweak store CVR (2025 store averages) · Adjust – AppTweak H1 2024 category CVRs · Adapty – App Store conversion by category · SplitMetrics category CVR (via AppScreenshotStudio) · RC renewal rates by category · RC – the Android paywall gap · Interact quiz report · Superwall · Mobile Dev Memo (MAI/AEO) · Stripe – Apple Pay conversion lift · Stripe vs Paddle fees · RocketShip HQ – Meta app-install CPI/CPM 2026 · Meta location fees (Jul 2026) · Google Play – tax rates & VAT by country · Apple – price and tax updates.