Revenue per install and payer value cannot share a target

RevenueCat defines revenue per install using installs and realised lifetime value per payer using paying users. These denominators create different planning questions. Methodology.

Keep the conversion bridge in the model

A high value per payer does not tell you how many acquired players become payers. For a simple internal reconciliation, align the revenue horizon and revenue definition first, then inspect payer conversion and payer value together. If the business includes advertising or non-subscription purchases, identify which streams the calculation includes.

Our recommendation is to refuse a single unlabeled “LTV” column in a budget review. State whether it means observed value to date, a forecast, value per install or value per payer. A precise name is often enough to expose a comparison that should never have been made.

Check event populations before comparing tools

GameAnalytics’ metric definitions provide a separate example of named user and revenue measures. Product labels are not a guarantee that two tools count the same population or apply identical revenue adjustments.

The attached card is a reconciliation aid, not a new benchmark. It shows which unit each reported measure uses and the missing inputs needed to relate it to the studio’s acquisition cost. A game should set its allowable spend from the value of the population it buys, while retaining payer-level analysis for diagnosing how that value is generated.

Inspect the evidence

Download the source-population and comparability card. The extraction separates documented facts from our analysis and unknowns.

Further reading in the existing archive: UA metrics explained: CPI, ROAS, LTV and payback; Blended ROAS Calculation: Where It Quietly Goes Wrong. These links provide background; this check does not independently verify their full contents.