Install Attribution

Install attribution connects an app install (or re-open) to the link that drove it. WarpLink uses a multi-tier match cascade to determine which link a user came from, with confidence scores that help you decide how to route the user. See Install attribution for the commercial overview.

What You Need

Attribution is recorded by a WarpLink mobile SDK, and the SDK must be configured with an SDK key. Create one in the dashboard under Keys > SDK keys, then pass it to configure().

An API key is not a substitute. It carries the scopes you pick for backend and CI work, and install attribution is never one of them. Configure the mobile app with an SDK key, since only an SDK key records installs.

Match Cascade

The server tries matching methods in order. The first successful match wins.

Priority	Method	Signal	Confidence	Platform
1	Referrer	Play Install Referrer	1.0	Android
2	Device ID	IDFV	The stored install's own score	iOS
3	Probabilistic match	IP (server-derived) + normalized language + timezone	0.20–0.85	Both
4	Raw signals	accept_language + timezone + timezone_offset (IP added server-side)	0.20–0.85	Both

Only the first tier is deterministic: the referrer names the link, so the response returns match_guaranteed: true. The device ID tier is a repeat check, not an install match: it returns the install the device already has, with that install's own match type and confidence, so it never turns a probabilistic match into a guaranteed one. The last two are probabilistic and match on IP, language, and timezone. Every first install on iOS is matched in the probabilistic tiers and returns match_guaranteed: false.

An app can switch the last two rows off. In routing-only mode the server runs only the referrer and the device ID repeat check, stores no click data for matching, and answers matched: false when neither applies.

The IP Gap Problem

The SDK cannot know its own public IP address, but WarpLink includes the request IP in match key computation at click time. To solve this:

• The SDK sends raw device signals (not a pre-computed match key) to the attribution endpoint
• The server computes the match key hash using the request's IP address
• This ensures the SDK-originated match key matches the one WarpLink stored at click time

Getting more installs matched

• Send visitors to the store. The Play Install Referrer is attached only when WarpLink sends the visitor to the Play Store. The dashboard flags this on the link. For deterministic Android attribution, make the Play Store URL the destination for visitors without your app.
• Install within the match window. The match window is 6 hours by default and up to 24. Each click is claimed by one install.

The Play Install Referrer sits at the top of the cascade and names the link directly.

A custom-scheme URL such as myapp://promo is an in-app route, not a web address. Visitors who do not have your app are sent to your fallback URL, then to your app's store URL, on both platforms. Set at least one of those, or such visitors have nowhere to go.

A market://details?id=... address counts as a custom scheme too, so WarpLink routes it the same way, to your fallback URL or your Android store URL rather than to the scheme itself. That is what keeps Android attribution deterministic, provided the address it resolves to is on play.google.com. Use the https://play.google.com URL as your Android store URL.

Confidence Scores

A deterministic match always scores 1.0. A probabilistic match starts from how long ago the click happened and which match variant the SDK could send:

Time since click	enriched_tz	enriched	basic
< 1 hour	0.85	0.80	0.70
< 3 hours	0.65	0.60	0.50
< 6 hours	0.50	0.45	0.35
< 24 hours	0.30	0.25	0.20

Matches run up to 24 hours after the click. The link's match window can cut that shorter still: it defaults to 6 hours and is capped at 24.

enriched_tz is what current SDKs send: it hashes the IANA timezone name, for example America/Toronto. The name carries far more entropy than the minute offset (roughly 340 zones against 38 offsets) and it does not shift at a daylight-saving boundary. enriched hashes the offset instead and is the fallback for SDKs that send no zone name. basic covers signals that carry neither.

Two multipliers then reduce the starting score:

Condition	Multiplier
The bucket offered more than one distinct link	0.6
Click IP was carrier-grade NAT or private	0.6
Click IP was a household IPv4 address	0.9
Click IP was IPv6	1.0

Use the result to decide how far to lean on the match: route straight to content near the top of the range, show a suggestion or a confirmation in the middle, and fall back to generic onboarding at the bottom. match_guaranteed and the score help you pick where to route the user, and sign-in stays on your own authentication.

Confidence depends on four things: how much time passed between the click and the install, which match variant was used, how many clicks were claimable in the same bucket, and how shared the click's IP address was. When several clicks could match, the most recent claimable one wins and the ambiguity multiplier applies.

Click Deduplication

Click uniqueness is computed server-side at write time for perfect accuracy, never at the cache layer.

A click is considered unique per combination of link, IP address, and 24-hour window.

What attribution returns

When a match succeeds, the response identifies the link and how confident the match is:

• Matched link: the link the install is attributed to, with its resolved deep link and destination URLs and any custom parameters
• Match type: deterministic for a Play Install Referrer match, or probabilistic for a probabilistic match. A device ID answer carries the type of the install it returns.
• Match confidence: a score from 0.0 to 1.0 you can use to decide how to route the user (see Confidence Scores above)
• Match guaranteed: true only for a deterministic match, exposed as matchGuaranteed on the SDKs

Use match_guaranteed and the confidence score to pick the destination the attribution result routes to, and keep sign-in on your own authentication.

Deterministic matches come only from the Play Install Referrer on Android. On iOS the IDFV answers the same install asking again and returns the install the device already has, with that install's own match type and confidence, so it never turns a probabilistic match into a guaranteed one. On a reinstall, iOS attribution runs again through the probabilistic tier and records a new install when it matches a click. On Android the Play Install Referrer answers a reinstall too, and records it as a new install of its own. When nothing matches, the response says so, and you can fall back to generic onboarding.

Reinstalls

A reinstall is an install. When someone deletes your app and installs it again, attribution runs again from scratch, on every platform, and the result counts in your install numbers like any other install. The install that follows a reinstall is the one most likely to have come from a link, so dropping it would lose exactly the campaigns you care about.

The SDK also labels it. Each platform keeps two separate markers:

Marker	Survives an app delete?	Job
Attribution complete	No, and it is never restored from a backup	Stops a second attribution request inside one install
Device seen	Yes, and it does come back from a backup	Decides whether this install is a reinstall

When the device-seen marker is present and the completion marker is not, the SDK sends is_reinstall: true on the attribution request. Anything else is a first install. The flag never gates the request: attribution runs either way. SDK versions older than the flag send nothing, which the server reads as a first install.

The dashboard counts installs and reinstalls together as one installs number.

Privacy

WarpLink's attribution is privacy-preserving:

• No IDFA (iOS) or GAID (Android): no advertising identifiers
• No cross-app tracking: IDFV, used only to recognize an install asking again, is scoped to your vendor
• No ATT prompt: IDFV is exempt from App Tracking Transparency
• Hashed match keys: Probabilistic match keys are stored only as a one-way hash, never as raw signals
• Scoped purpose: The match restores the link a user tapped on the first open after install. It does not track users across other companies' apps or websites, and the hashed match key is handled as follows. Each tap can be matched only within the app's match window, and pending entries are deleted automatically within 48 hours. A matched install keeps the hashed key for your plan's data retention period. The raw IP address is not stored.
• HTTPS only: All signal transmission is encrypted