Play install referrer
Expert: with sources and numbers. Plain: the same, without them, for beginners.
Android's first-party install attribution signal, simpler than iOS's, and with one behaviour worth knowing.
Android’s equivalent of the attribution signal iOS spreads across three frameworks. It is considerably simpler, and the difference explains why Android campaign reporting is faster and more granular than iOS’s.
What it does
A The Play Install Referrer API returns install referrer information for a package name, letting developers understand which traffic sources send the most users to download the app from Google Play. (Google Play Install Referrer, verified 2026-09-18)
A On success it provides the install referrer string and install time. It is implemented as an AIDL interface, with a Play Install Referrer Client Library for Kotlin and Java. (Play Install Referrer Library, verified 2026-09-18)
A Connection is established with newBuilder() then startConnection(), which is asynchronous and requires an InstallReferrerStateListener callback. Same source.
The behaviour worth knowing
A Install referrer information is available for 90 days and does not change unless the application is reinstalled. Google advises invoking the API only once, during the first execution after install. (Google Play Install Referrer, verified 2026-09-18)
Three consequences:
If you miss it on first launch, you can still get it, for 90 days. More forgiving than a one-shot signal.
It does not change on reinstall-free reuse. A user who reinstalls gets a new referrer; one who does not, keeps the original.
Calling it repeatedly is wasteful and unnecessary. Google says once, after install.
Why Android attribution is easier than iOS
The referrer is a string Google passes through at install. It carries campaign information directly, so Android attribution is comparatively direct and immediate.
On iOS, equivalent information is distributed across AdServices for Apple Ads and AdAttributionKit or SKAdNetwork for everything else, with postbacks that are delayed, aggregated and deliberately coarse (97-03).
So the same campaign will be measurable in more detail, sooner, on Android. When iOS and Android reporting timelines differ, this is usually why. And it is a reason iOS and Android campaign numbers should not be compared like for like (80-03).
What an ASO practitioner needs from it
It is how a custom store listing’s campaign traffic is identified downstream. The listing reports store-side (95-03, 60-05); the referrer is what carries campaign context into the app.
It is an engineering dependency. If it is not implemented, or implemented incorrectly, Android attribution degrades, usually first visible as a rise in “organic”, which is a residual (97-01).
Confirm it is implemented before diagnosing an attribution problem. A surprising number of Android attribution investigations end here.
What goes wrong
Not implementing it. Campaign traffic appears as organic.
Calling it on every launch. Unnecessary; Google says once after install.
Assuming a one-shot window. The data persists for 90 days.
Comparing Android and iOS campaign granularity. Different mechanisms, different fidelity.
In short
Every fact on this page in one line, with its evidence tier, source and verification date, 2 A. Generated from the claim register, so it cannot drift from the page above.
This centre's own equivalent of the signal the other side spreads across several separate systems. It's considerably simpler, and that difference is exactly why campaign reporting here is faster and more detailed than on the other side.
What it actually does
A specific tool returns install-referrer information for your own shop, letting you understand which traffic sources genuinely send the most people to install your shop from this centre.
On success it hands back a referrer note and the actual install time. It's built to be called once, asynchronously, with a listener waiting for the response.
The behaviour genuinely worth knowing
This referrer information stays available for a real stretch of time, and doesn't change unless the shop gets reinstalled. The centre advises calling this tool only once, during the very first run right after installation.
Three consequences follow:
If you miss it on first launch, you can still genuinely get it later, for a while. More forgiving than a one-shot signal that vanishes immediately.
It doesn't change through ordinary reuse without a reinstall. Someone who reinstalls gets a fresh referrer; someone who doesn't, keeps the original one.
Calling it over and over is wasteful and unnecessary. The centre says once, right after install.
Why crediting advertising is genuinely easier on this side than the other
The referrer is a simple note the centre passes straight through at the moment of install. It carries campaign information directly, so crediting here is comparatively direct and immediate.
On the other side, the equivalent information is spread across the centre's own first-party tool for its own billboard, and a deliberately blurry, delayed signal system for everything else.
So the exact same kind of campaign will be measurable in more detail, and sooner, here. When reporting timelines differ between the two centres, this is usually why. And it's a real reason campaign numbers from the two sides shouldn't be compared as if they were the same kind of thing.
What someone doing this job actually needs from it
It's how a specially-targeted second window's own campaign traffic gets identified downstream. The window itself reports on the shopfront side; this simple note is what carries the campaign's own context through into the shop itself.
It's a genuine engineering dependency. If it isn't implemented, or implemented incorrectly, crediting on this whole side degrades, usually first showing up as a rise in "unpaid," which is really just a leftover number.
Confirm it's actually implemented before diagnosing any crediting problem. A surprising number of investigations into this side's crediting problems end right here.
What tends to go wrong
Not implementing it at all. Campaign traffic quietly shows up as unpaid instead.
Calling it on every single launch. Unnecessary; the centre says once, right after install.
Assuming it's only a one-shot window. The data genuinely persists for a real stretch of time.
Comparing the level of detail here against the other centre's. Genuinely different mechanisms, genuinely different fidelity.