How an install gets attributed

What is install attribution?

Install attribution is the process of matching an app's first open to the ad click or impression that came before it, so the install can be credited to the right campaign. It is the foundation of every other number in mobile measurement, from cost per install to return on ad spend.

The difficulty is that the two moments happen in different places. The click happens in an ad, a browser or another app. The first open happens inside your app, after a trip through the App Store or Google Play that breaks the obvious connection.

The five steps from click to credit

1. The ad interaction is recorded

When someone taps an ad or a tracking link, the click is logged with a timestamp, a campaign identifier and whatever device or browser signals are available. For a view-through, the impression is logged instead. Self-attributing networks such as Meta and Google typically keep these interactions on their own side and decide for themselves whether they won an install; chapter 4 explains how they claim installs.

2. The person goes to the store

The link redirects to the App Store or Google Play. On Android, a tracking link can pass campaign details to Google Play in a referrer value, which the app can read back later. On iOS there is no equivalent passthrough for a normal App Store install.

3. The app is installed and opened

The install itself is not usually what an MMP counts. Most MMPs count the first open, because that is the first moment their code runs. Google Play, by contrast, records an install on download, which is one reason platform totals and MMP totals differ.

4. The SDK reports the first open

The attribution SDK inside the app starts on first launch and sends an install event with the signals it can collect: on Android, the Play Install Referrer and the Google advertising ID where available; on iOS, the advertising identifier (IDFA) only if the person allowed tracking, plus other app-level identifiers.

5. The match is made

The attribution system compares the first open with recorded touchpoints. If a click falls inside the attribution window, the install is credited to it. If several touchpoints qualify, the usual rule is last click wins, and clicks outrank views. If nothing qualifies, the install is organic.

Deterministic and probabilistic matching

There are two broad ways to make the match in step 5.

Deterministic attribution works when the same identifier appears on both sides. On Android, the Play Install Referrer carries the original referrer URL straight through Google Play, so a click ID placed in that URL comes back on first open. On iOS, the IDFA can link a click and an install, but only if the person granted tracking permission through App Tracking Transparency.

Probabilistic attribution guesses. It compares signals such as IP address and device type at click time and install time, and credits the click when they look similar enough within a short period. It can fill gaps, but it can also credit the wrong campaign, especially on shared networks such as office or mobile carrier IP ranges.

Is fingerprinting allowed on iOS?

No. Apple's App Store guidance says apps may not derive data from a device to uniquely identify it, and it names "fingerprint IDs" as a form of tracking identifier.

Apple also says apps or SDKs that do this, including attribution services, may be rejected. And without the person's tracking permission, you cannot swap in another identifier, such as a hashed email address, to track them across apps and websites. This is why iOS attribution now leans on two routes: deterministic matching for people who allowed tracking, and Apple's own aggregated frameworks, SKAdNetwork and AdAttributionKit, for everyone else. Both are covered in the iOS ATT and SKAN chapter.

A worked example on Android

Arjun taps a tracking link in an Instagram story at 10:02. The link redirects to Google Play with a referrer value that includes a click ID. He installs at 10:04 and opens the app at 10:05.

1. The click is logged with click ID abc123 at 10:02.
2. Google Play stores the referrer URL for the install.
3. On first launch, the SDK calls the Install Referrer API and receives the referrer URL, plus the referrer click timestamp and install begin timestamp.
4. The SDK sends abc123 with the install event.
5. The MMP finds click abc123, confirms it is inside the window, and credits the influencer campaign.

That is a deterministic match. If Arjun had installed from a third-party Android store, there would be no Play referrer, and the MMP would need another signal or would mark the install organic.

A worked example on iOS

Meera taps a TikTok ad on her iPhone, installs from the App Store and opens the app. When the app asks for tracking permission, she declines.

• The IDFA returns all zeros, so there is no shared identifier with the click.
• Fingerprinting is not allowed, so a compliant setup does not guess from IP and device model.
• The install is recorded for SKAdNetwork or AdAttributionKit, and an aggregated postback reaches the ad network after a random delay of at least 24 hours.
• In the MMP's user-level view, Meera's install may appear as unattributed, while the aggregated iOS report counts it against the campaign.

This split between user-level and aggregated data is normal on iOS, and it explains much of the gap between iOS and Android attribution rates.

Where install attribution breaks

The chain fails at predictable points:

• Step 1: tracking link missing campaign parameters, or a network integration not connected.
• Step 2: redirects that strip the referrer value on the way to Google Play.
• Step 3: installs from third-party Android stores, or sideloaded builds, with no Play referrer.
• Step 4: SDK starting late, or the referrer read on a later launch after a crash.
• Step 5: install falling outside the window, or a later click on another network winning.

When an install looks wrong, walk the five steps in order. The glossary defines each term used here if you need a refresher.