The end of the install as the unit of UA
By UA Ledger staff — Archive date: 6 min read

The install was never what UA wanted. It was what UA could count. As paths to play multiply, teams need a new unit of account and a rule for picking it.
The install has been the unit of account for mobile UA for fifteen years, and it earned the job for one reason: it was the thing every party could count the same way. Networks could bill on it, MMPs could attribute it, finance could divide spend by it. Its usefulness as a proxy for value was always secondary to its usefulness as a shared denominator.
That shared denominator is breaking, and I think the industry is about to spend a year arguing about the wrong replacement. The debate will be about which value event to optimise for. The prior question is what unit every party in the transaction can still observe and price. If the answer is nothing, then the unit of UA becomes whatever the seller's model says it is, and the buyer loses the ability to compare.
Why the install is failing as a denominator
Sensor Tower's State of Gaming report in February put 2025 mobile game installs down about seven percent while in-app purchase revenue rose about one percent. This site covered that report in February under the heading that volume UA was ending. The more precise point is that install volume and revenue have decoupled, and a unit that no longer moves with the outcome is a poor unit.
The second pressure is that the install is no longer the only door. Google Play began surfacing third-party stores to US users in July. Xsolla, a vendor with an interest in the answer, put web shop revenue at roughly fifteen percent of global mobile IAP in its August announcement. Apple's WWDC in June added cross-developer subscription bundles. Each of these creates a path where value arrives without an install the MMP can see in the usual way, or where an install happens through a door your attribution was not built for.
The third pressure is the one the networks themselves created. When the buying model optimises on a predicted value event rather than an install, the install becomes an intermediate variable the model may happily trade away. Fewer installs at higher predicted value is what you asked for. The dashboard row that used to anchor your reporting now reads like a decline.
The mechanism: units follow observability, not intent
Nobody chose the install because it was a good proxy. It won because both attribution technology and platform pricing could observe it, and every unit of account in advertising history has followed that same rule: impressions ruled when servers could count them and nothing else, clicks ruled on the web because both sides could see the redirect, and the install ruled on mobile because the SDK fired on first open.
This matters because the same rule will pick the replacement. Not the event that best predicts lifetime value; the event the seller can observe and price, then bill against. On iOS under SKAN and AdAttributionKit, that's a coarse postback carrying a conversion value. On networks running their own models it is whatever the network's internal predicted value says, and on a web shop it is a payment event the MMP may never see at all.
The consequence most coverage misses is that when units fragment, comparability collapses. You cannot rank a network reporting cost per predicted payer against another reporting cost per install on the same sheet. The buyer who tries ends up ranking vendors on how each defines its own success.
Three tests for a replacement unit
The practical question isn't what you want to optimise; it's which unit passes three tests at once.
Observable across channels, first: you can measure it for a network buy, a web shop visit, a third-party store install and an organic user, using the same definition.
Priced by a party other than the seller. Either you can bill on it, or a neutral intermediary can, so the network's model does not both define and report the number.
Correlated with cash inside a horizon you can wait for, meaning it should predict revenue within the time your finance team is willing to hold budget decisions open.
The install passes the first two and fails the third, while network-predicted value passes the third and fails the second. Day-seven retention passes the first and third and half-passes the second, since it's your MMP or your own analytics that owns it rather than the seller. It's no coincidence that many teams have quietly gravitated to it.
A worked illustrative example
Take an illustrative mid-size studio spending one million a month across three networks plus a web shop and a third-party store presence.
On a cost per install view, the network with a self-optimising model looks worst: fewer installs, higher CPI. On the network's own predicted value view, it looks best. On a unit the studio owns, say cost per user who reaches a defined day-seven engagement threshold, measured identically for all five paths using first-party analytics, the picture might show the model network in the middle, the web shop path cheapest per qualified user but smallest in volume, and the third-party store surprisingly close to the mainstream store on quality while lagging on volume.
None of those numbers is the point. The point is that the third view is the only one on which all five rows can appear at all. A unit you do not own cannot be the unit of the whole programme.
What changes in the review meeting
Adopting a studio-owned unit has a cost. The network's dashboard and your sheet will disagree, and you lose the comfort of a number the vendor will defend. Finance will need a lag it did not have with installs. Creative teams lose the fast signal that installs gave them, and need an intermediate proxy for iteration that is explicitly labelled as such.
Adjust's March report on gaming app sessions said the global paid-to-organic install ratio rose sharply through 2025, by more than half on its count. If more of what you count as organic arrives through doors you did not build attribution for, then a unit defined at the point of first open will misclassify more of it every quarter. The install will still appear in your reports. It should appear as a volume diagnostic, not as the thing the programme is bought and judged on.
Related archive reading
These articles provide related context and remain subject to their stated review status.
Featured
Related posts
measurement
platforms
·1 min read
When to turn rewarded ads off for payers (and how to measure the loss)
measurement
platforms
·1 min read
When custom product pages need their own MMP campaign mapping
measurement
platforms
·1 min read
Season pass refund rate versus standard IAP refund rate
measurement
platforms
·1 min read
Pre-reg cohort quality vs post-launch paid cohort quality
More from the Measurement desk
measurement
platforms
·2 min read
AppLovin Ad Review drops user-level journeys for aggregate-only reporting
measurement
platforms
·2 min read
Apple adds an EU alternative ATT prompt from iOS 27.2 — mandatory in five markets
measurement
platforms
·1 min read
Pity-adjusted expected value versus player-facing banner claims
measurement
platforms
·1 min read