Why most mobile games get LTV wrong at UA scale

• Revenue-based LTV can make unprofitable UA campaigns look profitable at scale.
• Mobile publishers should calculate LTV using gross profit and track it across individual player cohorts.
• Moving revenue between app stores and web shops is changing the economics behind LTV calculations.

Leonid Malysh is director of data & insights at Xsolla.

In a live-service mobile game, lifetime value decides how hard you push user acquisition. It sets how much you can pay for an install, which channels you scale, and which you kill. Get it right and you compound. Get it wrong and you scale losing campaigns for months, then find out when the quarter’s revenue lands short of the UA invoices.

Search “how to calculate LTV” and the top results give you “LTV = ARPU × average lifetime,” or “total revenue for a period divided by the number of users.” Both are wrong in a way that burns marketing budgets. In 2026, as more revenue moves to web shops and external checkout, those shortcuts fail in new ways.

Mistake #1: Using revenue instead of gross profit

The most common and most expensive error is using revenue in place of gross profit.

Say a cohort of players each generate $400 over their lifetime, and you buy them at $300 CAC. $400 beats $300, so you scale. Recompute on gross profit and the real figure might be $100. 

Now you lose $200 on every player you buy. Your DAU chart climbs; your losses climb with it.

Gross profit is revenue minus the variable costs of delivering the product, the costs that scale with each extra player (COGS). On mobile, that stack runs heavier than teams assume:

• the platform commission (for a decade Apple and Google took about 30%, or 15% under small-business and subscription terms);

• payment processing fees, when moving players to external checkout

• Live ops server, bandwidth and content-delivery costs that grow with an active player base;

• player support and moderation.

Engineering salaries, studio rent, and the cost of building the game stay mostly fixed. They don’t scale per install, so they stay out of gross-profit LTV. One test decides it: if a cost grows in proportion to the number of players, subtract it; if it doesn’t, leave it out.

The commission itself is now in play. After the Epic settlements and the EU’s Digital Markets Act, Apple and Google let you route purchases through external web shops, where the platform take falls toward 10% or less on some routes, against the old 30%. That margin swing is real, but it carries new variable costs: payment providers, fraud, refunds, and the support load of an off-store funnel. So web shops are not free money.

Every time you change your monetisation mix, your gross-profit stack changes with it, and last year’s LTV may no longer hold.

Mistake #2: The ARPU × lifetime formula

The second favourite is LTV = ARPU × average lifetime. It fails twice.

ARPU is built on revenue, so it carries Mistake #1 with it.

And “lifetime” for a live-service game has no clean definition. The three usual estimates all break:

• Average days until churn. A player installs, drifts off, returns 30 days later for a seasonal event, then leaves. The method logs a 30-day lifetime for two sessions, and it has no answer for the whales still playing.

• Area under the retention curve. Closer to reality, but where do you stop integrating? Strong live games flatten into a long plateau of habitual players. Day-1 ARPU also looks nothing like day-60 ARPU once battle passes and web-shop bundles land, so an average of the two describes no real player.

• 1 / churn. In a non-subscription game you can’t pin the moment a player leaves for good. Churn also tracks player age, since new installs drop out faster than veterans, so the figure swings with the slice you pick.

How to calculate LTV correctly: cohort analysis on gross profit

One method survives a live game:

1. Take a cohort, say every player who installed in February.

2. For each player, track gross profit day by day from install.

3. Sum gross profit across the cohort and accumulate it: profit at day N is the total from day 0 through day N.

4. Divide by the number of players in the cohort. That gives you the LTV curve by day.

You read LTV at a fixed point: day 7, day 30, month 12, matched to the decision. A UA team buying traffic to break even inside a year needs 3-6-12-month LTV, depending on its payback window. A product team tuning first-session activation needs day-7.

Keep cohorts apart. February installs and September installs face different UA sources and a different meta. Blend them and your average describes nothing you can use.

Forecasting LTV before the data is in

A UA team can’t wait a year for 12-month actuals; the auction runs now. So teams read historical cohorts and learn what day-7 gross-profit LTV needs to hit the 12-month target. Cut the campaigns that come in below the benchmark, scale the ones on track.

 As spend grows, teams split the model by country, platform and channel, because a US iOS install and an Indonesian Android install are not the same asset.

That read is accurate enough to steer real money, and it flags a bad channel in week one instead of at year-end.

The cross-platform wrinkle, and why it’s getting worse

When revenue splits across store IAP, web shops and external checkout, teams lose the thread. The same player pays in two places, your attribution double-counts or drops revenue, and the dashboard LTV drifts from reality.

If you move players off-store to cut commission, and in 2026 most studios do, hold one gross-profit LTV per player across web and app. Skip that and you optimise UA against a number that no longer fits your business.

The real cost of getting this wrong

The pattern repeats across studios. A team calculates LTV on revenue, sees a healthy number, and scales acquisition. The quarter closes and the economics don’t work: money leaves faster than it arrives, though every dashboard looked green. At $400 revenue LTV, $100 gross-profit LTV, and $300 CAC, you are down $200 a player. Across tens of thousands of installs, that gap is your runway.

Actionable checklist

Do:

• Calculate LTV on gross profit, not revenue. Subtract platform commission, payment and chargeback costs, and LiveOps server and support costs.

• Use cohort analysis, and keep install cohorts apart.

• Read LTV at a fixed horizon (day 7, day 30, month 12) tied to your payback window.

• Forecast from early-cohort benchmarks so you cut or scale in week one.

• Recompute the gross-profit stack whenever the monetisation mix changes, above all when you move revenue to web shops.

• Hold one LTV per player across app and web.

Don’t:

• Base LTV on revenue or its derivatives (ARPU, average bundle value).

• Use ARPU × “lifetime” in any form.

• Use 1 / churn as a stand-in for player lifetime.

• Assume last year’s LTV survives a monetisation or platform-fee change.

Once the inputs are right, the LTV on your dashboard is one you can spend a UA budget against.