Google Play install referrer
Android's attribution mechanism is more capable than Apple's and easier to get wrong, mostly because of one layer of URL encoding.
6 August 2026 by PAD team
The parameter
A Play Store URL accepts a referrer value, which Google stores and hands to your app after installation:
https://play.google.com/store/apps/details?id=com.example.app
&referrer=utm_source%3Dinstagram%26utm_campaign%3Dsummer
The value is itself a query string, so it must be URL encoded as a whole. That is the double encoding everyone gets wrong: = becomes %3D and & becomes %26 inside the referrer value.
Reading it in the app
The Install Referrer API returns the string on first launch, along with timestamps that let you measure the gap between click and install:
val client = InstallReferrerClient.newBuilder(context).build()
// onInstallReferrerSetupFinished →
val response = client.installReferrer
response.installReferrer // your referrer string
response.referrerClickTimestampSeconds
response.installBeginTimestampSeconds
The limits
- Available once, on first launch after install, so store it immediately
- Retained by Google for 90 days after the click
- Truncated beyond a few hundred characters, so keep values short
- Only populated for installs that came through Play, not sideloads or preinstalls
Why Android attribution is easier
Unlike iOS, the referrer travels through the install itself, so you can match a specific click to a specific install without a probabilistic model. That is also why deferred deep linking is more reliable on Android.
The part that fails first
None of it runs if the visitor never reaches Play. On Android that is rare, because in-app browsers can hand off through intent://, which is why the blank page problem is overwhelmingly an iPhone issue. Still, if you build the intent URL by hand, remember to keep the referrer encoded inside the fallback URL as well.
We attach the referrer correctly on the final Play URL, including inside the Android intent fallback.