Setup

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

Results

a2a funnel per 100,000 impressions – iOS vs Android

Both funnels, each with your current Setup and manual overrides (a2a and w2w keep separate overrides). Healthy bands = P25–P75 for your geo × vertical; ✓/⚠ marks where your value sits. For w2w, iOS/Android means the targeted device (split provisional [A], R4-11). Stages without an OS split use the same value for both columns – that's what Research Round 4 is hunting.
Economics rows use each funnel's own money mechanics: a2a – store fee 15% (SBP), no cohort penalty; w2w – PSP ~5% plus the web-cohort ×0.89 retention penalty [B, Adapty]. That's why the two ROAS figures are directly comparable – same prices, different money plumbing. Colors: a2a = blue/coral, w2w = sky/green (iOS / Android).

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

Assumptions behind the numbers

• A Click → store page 85–95% – in-app browser → deeplink losses; no public data (R3-5 sanity anchor via CTI).
• A Install → paywall view 75–90% – composite of first open + onboarding; only Superwall's "≥85%" guideline exists (R3-2).
• A Paid-traffic factor ×0.7–0.9 on store CVR – paid converts below blended benchmarks (R3-8).
• E Organic uplift 10–40% – extra organic installs per paid install (R4-9).
• A Trial share of new subscriptions 85–95% – no public benchmark (R3-1).
• E No-trial paywall converts ×0.6 of trial-start rate – Adapty per-view ratio 0.82% vs 1.35%.
• A Platform factors: CPM iOS ×1.1 / Android ×0.85; store CVR Android ×1.15 (cross-store CVR ratio unreliable – stores use different denominators); trial→paid at store parity [B, RC 32.6/32.5]; paywall stage Android ×0.9 [B, RC download-to-paid]; ARPU factor Android ×0.65 [E, anchored to RC D60 RPI $0.23/$0.42; the Y1 narrowing looks like survivor bias]; CPM Android ×0.95 in-geo [A – "cheap Android" is mostly geo mix, modeled separately] – CPM and store CVR still pending R4-1/R4-2.
• A No OS split yet on install→trial, trial→paid, retention, renewal, refunds, plan mix – R4-3…R4-6.
• E AEO: CPM ×3–5 [B, Mobile Dev Memo], conversion uplift ×2.5–4 – practitioner consensus, inferred (if AEO does not beat MAI ×2.5+, the signal is broken, not the format). Round 4.
• A w2w: paywall→checkout 5–15%, checkout completion 40–60% (the "3.5%" figure was rejected – wrong denominator; R3-4); web cohort LTV ×0.89 B.
• 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) – invented placeholders, R4-11.
• E Monthly retention M1 anchor 50–68% – from the v7 hand-built curves, consistent with RC M6/M12 anchors.

Retention curves – share of subscribers still active, months 0–12

Built from RevenueCat SOSA 2026: first three renewal rates by category B, M6 and M12 anchors B, store deltas B (Google Play +3.5pp on 1st monthly renewal, iOS +4.4pp on 1st weekly; stores converge by the 3rd renewal – so the curves meet at M6). The line between anchor points is log-log interpolation E; Business/Social & Lifestyle series are reconstructed from chart extremes quoted in the report E. Under each chart – a power-law fit per curve (least squares on log-log, months 1–12).
S(m) – share of subscribers still active in month m · m – months since the first payment (M0 = everyone) · R² – goodness of fit, 1.0 = the curve follows the formula exactly. These same power curves drive the Calculator's Fit from my first 2 renewals retention mode – enter what you already observe at week/month 1–2, the tail is extrapolated.

Why 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: 31% of Google Play cancellations are billing errors (involuntary churn) vs 14–15% on the App Store [B, RC ↗] – grace periods and payment retries recover a chunk of it for free.

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, we build a month-by-month payment schedule per subscriber: the first payment (minus refunds), then each renewal weighted by the probability of surviving to it (the retention curve from the Retention curves tab – RC anchors or a power-law fit from your first two renewals). LTV M13 = the sum of that schedule; net LTV = ÷(1+VAT) ×(1−store/PSP fee). The same schedule gives the payback month and the peak-cash figure in the Budget view – one model, three answers.

Where: 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 · VAT – sales tax inside the sticker price · upsell – ARPU uplift from welcome offers, plan upgrades and one-time purchases (0 if you have none) · fee – store commission (15/30%) or PSP fee (~5%) · S₁ – survival after the 1st renewal (= your 1st renewal rate) · r₂ – your 2nd renewal rate · b – decay exponent: how fast the cohort melts.

Two honest simplifications: we cut off at M13 instead of discounting an infinite tail, and the horizon is fixed rather than fitted per cohort. A WACC-discounted sum is the academically correct move – and it starts to matter when the volumes are large and the payback is long: at $100k+/month spend with a 12+ month payback, the time value of money quietly eats several percent of the modeled margin, and finance will (rightly) ask for the discounted version. At typical early-stage volumes and sub-year paybacks, the cutoff is both simpler and easier to defend.

The family of LTV methods (ordered by accuracy)

Symbols in the table: 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 – average revenue per daily active user · DAU – daily active users · cumARPU(t) – cumulative revenue per cohort user by day t · t* – the horizon you read LTV at · CF_i – cash flow of period i · WACC – 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).

Trust check: ✓ Run the built-in self-test – 15 assertions (anchor hits, monotonicity, internal consistency, hand-recalculated snapshots, guards) executed live in your browser, on exactly the code that computes your numbers.

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

How VAT works for subscription apps

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.

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 field on the Calculator tab.

VAT / GST rates deducted from the sticker price, key countries

Rates [E] – verify against Apple's Exhibit B / Google Play tax documentation before relying on them; they change.