App LTV: Calculate and Improve Mobile Customer Value

A campaign can deliver cheap installs and still destroy margin if those users churn before they generate meaningful revenue. App LTV turns that delayed outcome into a number a growth, product, and finance team can use together.

App LTV is the revenue or gross profit an average user generates across their relationship with a mobile app. Calculate it from observed cohort value when possible, or estimate it with periodic ARPU divided by churn; then compare like-for-like cohorts rather than trusting one blended average.

This guide shows how to choose the right formula, build a defensible cohort view, connect value to acquisition, and improve LTV without optimizing a vanity metric.

What is app LTV?

App lifetime value estimates how much economic value one user creates from install until they stop using or paying for the app. It may include subscription revenue, in-app purchases, advertising revenue, commerce margin, or another monetizable outcome, depending on the business model.

The definition must state whether “value” means gross revenue, net proceeds, or gross profit. Revenue LTV is useful for comparing monetization. Margin-adjusted LTV is safer for acquisition and budgeting because app-store fees, refunds, content royalties, payment costs, customer support, and other variable costs can make a high-revenue user less profitable than the headline number suggests.

LTV is not the same as a current-period revenue metric:

If you need to standardize the payer metric first, this ARPPU formula guide explains the revenue and user rules that keep its numerator and denominator comparable.

Why app LTV matters

LTV connects acquisition quality, activation, retention, and monetization. It helps a team answer practical questions:

• Which channel brings users who remain valuable after the install?
• How much can we afford to spend on a new user or payer?
• Did a new onboarding flow improve long-term economics or only Day 1 conversion?
• Do annual subscribers, ad-supported users, and purchasers need different models?
• When does a cohort repay its acquisition cost?

Apple’s App Store Connect cohort reporting reflects this operating view: teams can compare proceeds per download and subscription retention across download or subscription cohorts, then filter by dimensions such as source, territory, device, and offer.

How to calculate app LTV: choose the right model

There is no universal app LTV formula. The right method depends on the monetization model, the maturity of the data, and whether the decision requires observed or predicted value.

Method 1: cumulative cohort LTV

Use this method when you can connect revenue and variable costs to a defined install or subscription cohort.

Realized cohort LTV at day N =
(cumulative cohort revenue through day N - refunds - variable costs) / users acquired in the cohort

For revenue LTV, omit variable costs but label the result clearly. Keep the original acquired-user count in the denominator as the cohort ages. Dividing by only the users still active would inflate value as users churn.

This model is especially useful for apps with mixed monetization because it can accumulate purchases, subscriptions, and ad revenue on one time axis. It also avoids pretending the future is known. The limitation is latency: a Day 30 cohort cannot tell you its complete lifetime value.

Method 2: ARPU divided by churn

For a stable recurring-revenue app, a common shortcut is:

Revenue LTV = ARPU per period / user churn rate per period

Margin-adjusted LTV = (ARPU per period × gross margin) / user churn rate per period

If monthly ARPU is $6, gross margin is 80%, and monthly user churn is 12%, the estimate is:

($6 × 0.80) / 0.12 = $40 margin-adjusted LTV

Adjust’s mobile LTV guide presents the basic ARPU/churn formula and cautions that data quality, changing behavior, forecast windows, and cohort selection affect the result.

This shortcut assumes churn is reasonably stable and behaves like a constant probability. It becomes misleading when a new app has volatile retention, when annual and monthly subscribers are blended, or when churn changes sharply with customer age.

Also keep units aligned. Monthly ARPU requires monthly churn; weekly ARPU requires weekly churn. A percentage belongs in the formula as a decimal, so 12% becomes 0.12.

Method 3: retention-curve or predictive LTV

For non-subscription, ad-supported, freemium, and seasonal apps, estimate future value by projecting the retention curve and revenue per active user:

Predicted LTV through day N =
sum of (probability user is active on day t × expected value on day t)

This is more flexible than ARPU / churn because retention can fall steeply after install and flatten later. A mature model can include channel, country, platform, plan, onboarding behavior, purchase history, or other early signals.

Prediction adds model risk. AppsFlyer’s predicted LTV overview recommends choosing relevant KPIs, accounting for timing and seasonality, and continually comparing forecasts with newer observations. Report a model version and forecast horizon—such as predicted Day 180 revenue LTV—instead of presenting “LTV” as an timeless fact.

App LTV calculation example for a mobile cohort

Suppose a fitness app acquires 10,000 users in January. After 90 days, the cohort has generated:

• $34,000 in subscription revenue;
• $6,000 in one-time purchases;
• $2,000 in refunds;
• $8,400 in platform, payment, and content-related variable costs.

The observed calculations are:

Day 90 revenue LTV = ($34,000 + $6,000 - $2,000) / 10,000
Day 90 revenue LTV = $3.80

Day 90 margin-adjusted LTV = ($38,000 - $8,400) / 10,000
Day 90 margin-adjusted LTV = $2.96

Assume that cohort cost $20,000 to acquire, or $2 per user. It has passed payback on a margin-adjusted basis by Day 90 because $2.96 exceeds the $2 CAC. That does not mean the team should immediately bid up to $2.96: reporting delay, forecast error, overhead, and the desired profit buffer still matter.

Now compare two channels:

The short-video campaign wins on install cost but produces less contribution per acquired user. A CPI-only optimization would send budget toward the weaker cohort.

How to track app LTV by cohort

An accurate formula cannot rescue incomplete event data. Build the measurement path before treating LTV as a budget control.

1. Choose the cohort anchor and identity

Start with a stable event such as first install, first open, signup, trial start, or first payment. Install cohorts are useful for acquisition decisions; payer cohorts are useful for subscription and pricing analysis. Do not compare an install-based LTV with a payer-based CAC.

Use a privacy-conscious first-party account or analytics identifier where appropriate, and define how reinstalls, anonymous-to-known transitions, cross-device activity, and account merges are handled. The goal is consistency, not artificial person-level certainty.

2. Capture every value stream

Record purchases, renewals, refunds, ad revenue, and relevant variable costs with a consistent currency and timezone. Avoid counting a subscription renewal from both the store event and a server webhook. For advertising apps, Firebase documents that linking AdMob adds ad metrics and AdMob revenue to Google Analytics, which helps create a more complete view of user lifetime value alongside app behavior.

3. Preserve acquisition context

Store the campaign, channel, creative, referral, landing destination, and attribution timestamp needed for segmentation. Apple’s acquisition documentation notes that App Store metrics can be viewed by sources and campaigns, while usage, sales, and subscriptions can be attributed to the recorded download source. A separate measurement layer may be needed for a consistent cross-platform view.

Deeplinkly connects deep links and deferred deep links with install attribution and downstream campaign measurement, so teams can compare the value created after a click instead of stopping at the install. That makes it relevant when an app LTV report needs source and campaign context across the click-to-install gap.

4. Build a cohort table

For every install week or month, calculate cumulative value at fixed ages such as Day 1, 7, 30, 60, 90, and 180. Add only segments large enough to support a decision.

At minimum, keep these dimensions available:

• acquisition source and campaign;
• organic versus paid;
• country or region;
• operating system and app version;
• plan, offer, or monetization type;
• onboarding completion or another activation event.

Compare cohorts at the same age. A cohort installed 15 days ago cannot fairly compete with one that has accumulated 90 days of revenue.

5. Validate the forecast

Backtest every predicted LTV model. For example, compare the Day 7 prediction for each cohort with its realized Day 90 value once that outcome becomes available. Track median error, large misses, and bias by source. If one channel is consistently overpredicted, lower its bidding guardrail until the model is corrected.

Common app LTV mistakes

Calling revenue “profit”

Gross revenue does not fund acquisition dollar for dollar. Maintain separate revenue and margin-adjusted views, and state what each cost layer includes.

Mixing user and payer denominators

LTV per install, per registered user, and per payer can all be valid. They are not interchangeable. Put the population in the metric name and match CAC to the same population.

Using one blended average

Channel, country, plan, and behavior can produce materially different retention and revenue curves. A blended average can subsidize a poor segment and hide the segment worth scaling.

Treating a forecast as realized cash

Predicted LTV is a model output. Keep realized cumulative value beside it and include a forecast date, horizon, and model version. RevenueCat argues that subscription apps often get more actionable control from realized cohort value, payback period, and gross contribution after CAC than from an overconfident lifetime ratio.

Optimizing LTV alone

LTV can rise while total contribution falls—for example, if a higher price lifts value per payer but sharply reduces conversion. Read LTV with cohort size, activation, retention, total margin, payback, and forecast error.

How to improve app LTV

Improvement comes from changing one or more components of the value curve: more users reach value, more return, more monetize, or the app earns more contribution per active user.

Improve activation before buying more installs

Find the smallest early behavior associated with later retention or payment: completing a first workout, saving an item, inviting a collaborator, or viewing a second episode. Remove setup friction and test onboarding around that outcome. Use the WAU metric as a supporting engagement signal, not as a substitute for cohort value.

Reduce preventable churn

Segment churn by customer age and reason. Fix failed payments, confusing renewal states, crashes, missing content, notification overload, and weak habit loops separately. Subscription churn should also be split by plan and offer because a discounted trial cohort may not behave like a full-price annual cohort.

Test pricing across the full lifecycle

Evaluate paywall and price experiments using conversion, refunds, renewals, realized LTV, and total contribution—not only initial purchase rate. RevenueCat’s price-testing guidance emphasizes that the revenue visible during an experiment is an incomplete snapshot because retained subscribers continue adding value over time.

Improve monetization without breaking trust

For purchase apps, test bundles, merchandising, and contextual offers. For ad-supported apps, balance fill, format, and frequency against retention. For subscriptions, improve the product value and plan fit before relying on discounts. Guard every test with retention and complaint metrics.

Reallocate acquisition by value, not volume

Move budget using mature, margin-adjusted cohort results where available. For younger cohorts, apply conservative predicted LTV thresholds and require a profit buffer. Scale a channel only when its value persists across multiple cohorts rather than one unusually strong week.

Frequently asked questions

What is a good LTV for an app?

A good app LTV is high enough to repay matched acquisition and variable costs within the company’s cash-flow window while leaving the required margin. There is no universal dollar benchmark because monetization model, geography, retention, and the denominator differ.

How do you calculate LTV for a mobile app?

The most defensible method is cumulative cohort value: subtract refunds and relevant variable costs from cohort revenue, then divide by the original number of acquired users. A stable subscription app can also estimate LTV as periodic ARPU times gross margin divided by churn.

What is the difference between app LTV and ARPU?

ARPU measures average revenue per user during a defined period. App LTV measures or predicts value accumulated across the user relationship; periodic ARPU is one possible input to an LTV model.

Should app LTV include ad revenue?

Yes, if advertising is part of the app’s monetization model and the revenue can be assigned consistently to users or cohorts. Document whether the result also includes purchases, subscriptions, refunds, and ad-serving costs.

How often should you update app LTV?

Refresh realized cohort value as new revenue and cost data arrives, and review acquisition decisions on a consistent cadence such as weekly or monthly. Retrain or recalibrate a predictive model whenever backtests show material bias or a product, pricing, channel, or seasonal change alters user behavior.

Turn app LTV into a decision rule

Start with one clearly labeled cohort metric: Day 90 margin-adjusted LTV per install. Compare it with matched CAC, inspect differences by acquisition source, and keep predicted value separate from realized value.

Once the measurement is stable, choose the bottleneck with the clearest evidence—activation, retention, monetization, or channel quality—and run one guarded experiment. If campaign context is getting lost between click, app store, and first open, map that journey before using LTV to scale spend.