Google Play Install Referrer: How It Works & Why It Stops Fraud

The Google Play Install Referrer API is a small Google library that hands a freshly installed Android app the campaign and timing data that explains where the install came from — the referrer URL plus two timestamps — delivered directly by Google Play rather than by any signal an attacker can fake. It is the deterministic foundation almost every Android measurement and anti-fraud system is built on, and most marketers use it every day without ever seeing it.

The mechanics are simple to picture. When a user taps an ad or a tracking link, that click sends them to your Google Play listing with a set of parameters appended to the store URL. Google Play remembers those parameters through the install. The first time the app launches, it asks Play — through the Play Install Referrer Library — "what referrer information do you have for me?", and Play returns the campaign string and the timestamps. The app, or more usually the MMP SDK embedded in it, reads that response and matches the install to the campaign that drove it.

What makes this trustworthy is the channel. The data does not travel through the open device where other apps can read or spoof it; it comes from the Play Store install record itself. That is the difference between an attribution signal you can defend in a payout dispute and one you cannot. For any app spending on user acquisition, the Install Referrer is the closest thing Android has to ground truth about install source.

Two boundaries are worth stating up front. First, this is Android-only — there is no equivalent on iOS, where attribution runs through SKAdNetwork and AdAttributionKit, which we contrast later. Second, the referrer is available for a limited window after install and is fetched once, so it has to be retrieved correctly or it is gone. Across our 300+ apps managed since 2013, the single most common Android attribution bug we are called in to fix is not a misconfigured campaign — it is an Install Referrer that was never read at the right moment, which silently drops a slice of paid installs into the organic bucket.

The Install Referrer API returns three things to the installed app: the referrer URL containing your campaign parameters, the referrer click timestamp (when the user clicked the ad), and the install-begin timestamp (when the download started) — and those three together are everything attribution and fraud detection need. Each one does a specific job.

• The referrer URL: this is the campaign string carried through from the click — typically a set of utm parameters or an MMP-encoded token such as the network, campaign, ad set and click ID. It answers "which campaign, channel and creative drove this install?" Your MMP decodes it to credit the right source.
• The referrer click timestamp: the server-side time, in seconds, at which the click that led to the install happened. This is not a device clock the user can tamper with — it is recorded by the click infrastructure, which is what makes it reliable.
• The install-begin timestamp: the server-side time at which the install actually began on the device. It marks the moment Play started fetching your app for this user.

The library also exposes secondary fields — for example whether the user had previously interacted with an instant experience, and the Play Store version — but the three above are the load-bearing ones. The referrer URL handles "who gets the credit"; the two timestamps handle "is this credit legitimate". Strip the API down to its essentials and that is the whole story.

The reason it matters that all three arrive together, from Play, in one signed response, is that you cannot trust one without the others. A referrer URL on its own is just a string — anyone can append parameters to a Play link. It is the two timestamps, anchored to server-side records, that let your MMP ask whether the install behaves like a real human journey or like a machine gaming the payout. We will spend the rest of this guide on what those three values unlock.

The Install Referrer attributes an install deterministically: it matches the campaign parameters Play returns against the click your MMP logged, with no guessing or probabilistic fingerprinting involved — the referrer string is a direct, first-party link between the click and the install. That determinism is what makes it the gold standard for Android measurement.

The end-to-end flow runs like this. A user clicks your ad. The ad network (or your MMP's click router) records the click with a unique identifier and forwards the user to your Play Store listing with campaign parameters appended. The user installs and opens the app. On first launch, the embedded SDK calls the Install Referrer library, receives the referrer URL and timestamps, and sends them back to the MMP. The MMP finds the matching click record by its identifier, confirms the campaign, and credits that source. The whole loop closes without ever needing device-level identifiers like the advertising ID to make the match.

Contrast this with the probabilistic fallback that attribution had to rely on when no deterministic signal was available — matching loose device and network attributes within a time window to guess the source. Probabilistic matching is an estimate; the Install Referrer is a record. When both are available, every MMP prioritises the referrer, because a deterministic match holds up under scrutiny and a probabilistic one does not. If you want the full mechanics of how clicks, installs and identifiers are stitched together across the stack, our guide to mobile attribution walks through the entire model end to end.

It also helps to be precise about what "match" means here. The referrer string Play returns is not free text your team writes by hand — it is the encoded token your MMP or ad network generated when it logged the click, carrying a unique click identifier alongside the campaign, ad set and creative. On first launch the MMP receives that token back through the Install Referrer, looks up the click record it stored at click time, and confirms the two halves describe the same journey. Because both ends of the match are first-party records the MMP controls, the attribution is reproducible: re-run the logic and you get the same answer, which is exactly what you want when money is changing hands.

The practical payoff is clean reports. Because the referrer is first-party data from Play, it survives the loss of cross-app identifiers, it works whether or not the user consented to tracking in the conventional sense, and it gives you a defensible answer when a network's self-reported numbers disagree with your MMP. In our portfolio, the Android campaigns that reconcile cleanly between network and MMP are almost always the ones where the Install Referrer is wired correctly — and the ones that argue about discrepancies every month are usually the ones where it is not.

The gap between the referrer click timestamp and the install-begin timestamp is the click-to-install time, or CTIT, and it matters because a real human install produces a CTIT that falls in a predictable range — so installs that fall outside that range are the clearest signal of fraud you have. CTIT turns two harmless-looking timestamps into a lie detector.

Think about what a genuine journey looks like. A person sees an ad, taps it, lands on your store listing, decides to install, waits for the download over their connection, and opens the app. That sequence takes time — usually somewhere from tens of seconds to a few hours, depending on connection speed, whether they install immediately or later, and how big the app is. Aggregate enough real installs and CTIT forms a smooth, sensible distribution with a meaningful peak and a long but thinning tail.

Fraud breaks that distribution in two opposite ways. When the gap is implausibly short — a click that lands a fraction of a second before the install completes — it is almost certainly a machine that fired a click at the last moment to steal credit, not a human who browsed and decided. When the distribution is unnaturally flat and stretched across hours or days, with clicks scattered far from their installs, it points to a flood of fake clicks fishing for organic installs to claim. Both patterns are visible only because the Install Referrer gives you the two anchored timestamps to measure between.

It is worth stressing that CTIT is a population signal as much as a per-install one. A single install with an odd gap can have an innocent explanation — a user who clicked, got distracted for two days, then came back and installed. What is far harder to explain away is a whole campaign whose gaps cluster in the wrong place: thousands of installs with sub-second CTIT, or a source whose entire distribution is smeared flat across days with no natural peak. MMPs therefore look at both the individual outliers and the shape of the distribution per source, which is why a fraudster cannot hide by sprinkling a few plausible gaps among the fakes.

This is why MMPs treat CTIT as a primary fraud dimension rather than a nice-to-have. The referrer URL tells you who is asking to be paid; the CTIT tells you whether their claim is physically plausible. A network can fake a referrer string, but faking a believable CTIT at scale, across thousands of installs, without the install-begin timestamp it does not control, is far harder. That asymmetry is the entire defensive value of the Install Referrer, and it is why "why it stops fraud" is not marketing language — it is the timestamps doing the work.

The modern Install Referrer API replaced the old broadcast INSTALL_REFERRER intent, and the differences are not cosmetic: the broadcast carried no timestamps, was delivered openly on the device where other apps could intercept or spoof it, and Google deprecated it — the API fixed all three problems by serving signed data with timestamps straight from Play. Understanding the contrast explains why the API exists at all.

The original mechanism worked by broadcasting an Android system intent to the newly installed app when the install completed, with the referrer string tucked inside. It got the job done for basic campaign tagging, but it had two structural weaknesses. First, it carried only the referrer string — no click timestamp, no install-begin timestamp — so there was no native way to compute CTIT and therefore no native way to spot the fraud patterns above. Second, the broadcast was a system-wide signal, and in practice other apps installed on the device could listen for it or fire their own, which opened the door to click injection: a malicious app intercepting the install broadcast and inserting its own referrer to hijack the credit.

The Install Referrer library closed both gaps. Instead of a broadcast that travels across the open device, the app makes a direct, authenticated request to Google Play and receives the referrer plus the two timestamps in a single response that other apps cannot read or alter. Adding the install-begin timestamp is what made CTIT-based fraud detection possible in the first place — you cannot measure a gap you were never given one end of.

The migration is effectively complete. Google deprecated the broadcast approach, and the documented, supported path is the Install Referrer library; if any of your older tracking or a legacy SDK still depends on the broadcast, that is technical debt to retire, not a fallback to keep. Fraud teams at the major MMPs make the same point — Adjust's published fraud-prevention research repeatedly frames the move from the spoofable broadcast to the signed, timestamped API as a turning point for shutting down install hijacking. If you are auditing an Android stack today and still see the broadcast in use, treat it as a red flag.

The Install Referrer is the carrier your MMP uses for both attribution and deferred deep linking on Android — the same referrer string that credits the campaign can also carry the destination the user should land on after they install, so they arrive exactly where the ad promised rather than on a generic home screen. Attribution and routing ride the same rail.

Deferred deep linking is the part marketers feel most directly. A user taps an ad for a specific product, playlist or promo, but they do not have your app yet, so they install first. Without deferred deep linking they open the app to the default screen and have to find that product again — and many simply do not. With it, your MMP encodes the destination into the referrer parameters, reads them back on first launch through the Install Referrer, and routes the user straight to the right screen. The Install Referrer is what survives the install gap to make that possible on Android.

In practice you almost never touch the API directly for this — the MMP SDK does. AppsFlyer, Adjust and Singular all integrate the Install Referrer under the hood: their SDK calls the library, parses the referrer and timestamps, runs the attribution and fraud logic, and exposes the deep-link payload to your app through a clean callback. Your job is to integrate the SDK correctly and handle the deep-link callback; the referrer plumbing is theirs. AppsFlyer's measurement resources document how that decoding maps to their attribution model, and if you are weighing which MMP to standardise on, our comparison of AppsFlyer, Adjust and Singular breaks down how each handles Android attribution and fraud.

One nuance teams miss is that the referrer and the deep-link destination are independent decisions that happen to travel together. You can run the same campaign URL for attribution while varying the deferred destination by ad or audience, because both are encoded into the parameters the Install Referrer carries. That means a well-structured link strategy lets you route a user who tapped a winter-sale ad to the sale screen and a user who tapped a specific-product ad to that product, all while crediting the same campaign — without building separate install flows. The Install Referrer is the single channel that makes that flexibility survive the install gap.

The takeaway for your stack is that the Install Referrer is not a standalone tool you operate — it is the data source your measurement platform sits on top of. Get the SDK and the referrer handling right once, and you get accurate attribution, working deferred deep links, and CTIT-based fraud filtering as a single package. Get it wrong, and all three degrade together, which is why we treat Install Referrer health as a core check in any analytics and measurement audit.

iOS has no Install Referrer equivalent — Apple replaced device-level install signals with SKAdNetwork and its successor AdAttributionKit, which are privacy-preserving and aggregated, so the per-user, timestamp-based fraud detection the Install Referrer enables on Android simply does not translate one-to-one to iOS. The two platforms now attribute installs in fundamentally different ways.

On Android, the Install Referrer gives your app a per-install referrer string and two precise timestamps it can act on immediately. On iOS, attribution runs through Apple-mediated postbacks. With SKAdNetwork, a successful install triggers a postback to the ad network that confirms the conversion and a coarse "conversion value", but it is deliberately delayed, privacy-protected, and aggregated to prevent linking the install back to an individual user. AdAttributionKit, introduced as the modern successor, extends the model — adding support for re-engagement and alternative marketplaces — while keeping the same privacy-first, aggregated philosophy.

That design choice has a direct consequence for fraud detection. Because iOS does not hand you a precise click and install timestamp per user, you cannot compute a clean per-install CTIT the way you can on Android. Fraud controls on iOS instead lean on the integrity of the Apple-signed postback, network-level anomaly detection, and the constraints the framework itself imposes. The mechanics differ enough that MMPs run separate logic per platform — Adjust's SKAdNetwork explainer and AppsFlyer's AdAttributionKit breakdown both detail how iOS attribution is reconstructed from aggregated postbacks rather than per-user records.

The practical implication for a cross-platform marketer is to stop expecting symmetry. Android gives you granular, deterministic, timestamp-rich attribution through the Install Referrer; iOS gives you privacy-preserving, aggregated, slightly delayed signals through SKAN and AdAttributionKit. Your benchmarks, your fraud thresholds, and your reporting cadence all have to be set per platform. The teams that get burned are the ones that assume an Android measurement playbook drops cleanly onto iOS — it does not, and the Install Referrer is one of the biggest reasons why.

Implementing the Install Referrer means adding the Play Install Referrer library, establishing a connection to Google Play on first launch, reading the referrer and timestamps from the response, and handling the response codes correctly — and in almost every real stack your MMP SDK does this for you, so the work is integrating the SDK properly and then validating that the referrer actually arrives. The risk is not complexity; it is silent failure.

1. Add the library or let the SDK own it: the Install Referrer library is a small dependency. If you run an MMP SDK — the usual case — it already bundles and calls the library, so you should not implement it twice. Implement it directly only if you have a specific reason to handle attribution yourself.
2. Connect and read on first launch: the flow opens a connection to Google Play, and on a successful connection reads the referrer URL, the referrer click timestamp and the install-begin timestamp from the response, then closes the connection. This happens once, early in the app's first session.
3. Handle the response codes: the connection can come back OK, or report that the feature is not supported on that Play version, or that the service is unavailable. Your handling has to account for the non-OK cases gracefully rather than assuming the referrer is always there — because sometimes it genuinely is not.
4. Pass the values onward: the referrer and timestamps go to your attribution logic, which is the MMP. From there they drive campaign credit, CTIT fraud checks and deferred deep linking.

Validation is where teams save themselves weeks of bad data. Test an end-to-end install from a real tracking link and confirm three things: that the referrer string arrives intact with your campaign parameters, that both timestamps are present and sane, and that the install shows up attributed to the right source in your MMP dashboard rather than landing in organic. Run that test on more than one device and Android version, because Play behaviour and store versions vary in the field.

Because the Install Referrer is fetched once within a limited post-install window, the failure mode is quiet — a broken integration does not throw a loud error, it just under-reports paid installs while everything appears to work. That is precisely the kind of leak that makes a channel look unprofitable when it is actually fine, which is why we build Install Referrer validation into every Android user acquisition setup before a rupee or dollar of media goes live.

The Install Referrer detects the two most common install frauds — click injection and click spam — by exposing the click and install timestamps that make each attack visible: injection produces a CTIT that is impossibly short, and spam produces a CTIT distribution that is unnaturally long and flat, and neither pattern survives once the timestamps are on the table. This is the core of why the API is a fraud-prevention tool, not just a tagging tool.

Click injection works by hijacking the install at the last second. A malicious app already on the device detects that a new app is being installed and fires a click — carrying its own referrer — moments before the install completes, so it can claim credit for an install it had nothing to do with. The tell is CTIT: a genuine click happens before the user even reaches the store, so a real CTIT spans at least the time it takes to browse and download. An injected click lands a fraction of a second before install-begin, producing a CTIT so short it is physically implausible for a human journey. The install-begin timestamp the Install Referrer provides is exactly what catches it.

Click spam (also called click flooding) takes the opposite approach: a fraudster fires a huge volume of fake clicks for many devices, hoping that some of those devices will organically install your app later, at which point the most recent fake click steals the credit. Here the giveaway is a CTIT distribution that is stretched and flat — installs scattered hours or days after their supposed clicks, with none of the natural peak a real campaign shows. An MMP looking at that distribution can see the fingerprints of flooding rather than genuine engagement.

In both cases the defence is the same: the MMP reads the Install Referrer timestamps, computes CTIT per install, compares it against expected human behaviour, and rejects or reattributes the installs that fail. The referrer string alone could not do this — it is the pairing of the click timestamp and the install-begin timestamp that makes the fraud measurable. If you want the broader playbook of detection methods that sit alongside CTIT, our guide to mobile ad fraud prevention covers the full toolkit. We have seen Android campaigns where correctly enforced CTIT thresholds stripped out a meaningful chunk of "installs" that turned out to be injected or flooded — budget that was being quietly handed to fraudsters until the timestamps were enforced.

The pitfalls that cost teams the most are misreading organic referrers as paid, losing the referrer entirely by fetching it in the wrong window, and forgetting that some install paths carry no referrer at all — each one quietly corrupts your Android numbers if you do not handle it deliberately. None are hard to avoid once you know they exist.

• The organic referrer trap: an install that came from organic Play search or browsing still returns a referrer, but it is an organic one — not a paid campaign. Treat any non-empty referrer as paid attribution and you will over-credit your campaigns and under-count organic, which inflates paid ROAS and hides where your real growth comes from. Your MMP should classify these correctly; confirm that it does.
• The missing referrer: the API can legitimately return that the feature is unavailable or unsupported — older Play versions, certain device states, or service hiccups. If your handling assumes a referrer is always present, you will either crash that path or, worse, misclassify those installs. Handle the non-OK response codes explicitly.
• The fetch-window mistake: the referrer is retrievable for a limited time after install and is read once. Fetch it too late, fail to establish the Play connection, or never close and handle it properly, and the data is simply gone — and the install falls to organic. This is the most common silent leak we find.
• Non-Play install paths: sideloaded installs, some OEM preloads, and installs from alternative stores do not carry a Play Install Referrer at all, because Play was never in the loop. For any meaningful non-Play distribution, you need a separate attribution plan rather than expecting the referrer to cover it.

The thread running through all four is that the Install Referrer fails quietly. It rarely throws an obvious error — it just returns nothing, or the wrong classification, and your dashboard keeps rendering numbers that look fine while paid installs leak into organic and your fraud filters run on incomplete timestamps. That is why validation, not just implementation, is the real work.

If your Android attribution does not reconcile, your paid channels look weaker than they are, or you suspect injection and flooding are inflating install counts, the Install Referrer is the first place to look — and getting it right is exactly the kind of measurement plumbing our team sets up and audits. You can see the outcomes across our work with growth teams when the foundation is built correctly from day one.