How LinkTrail attributes an install
Attribution is a series of judgement calls, and most platforms publish the result without the reasoning. This is the reasoning: which signals we compare, which ones we never collect, what the match actually says, and what we refuse to infer.
Why publish this
Two attribution tools pointed at the same traffic will disagree, and the gap is almost never a bug. It comes from different attribution windows, different models, different consent defaults, and different definitions of an install. None of that is visible when a vendor reports a single attributed total.
So the numbers a platform produces are only as trustworthy as the method behind them, and the method is usually undisclosed. Publishing ours means a reader can check our reasoning, reproduce the comparison on their own traffic, and disagree with specifics rather than with a black box.
What this page is not: a performance claim. There are no accuracy percentages here, because we do not yet have a production dataset large enough to publish one honestly. When we do, the benchmark will appear on this page as a dated revision with its sample size and limitations stated.
1. The attribution waterfall
Layers are evaluated in order. The first that produces a match wins, and the install records which layer produced it.
| Layer | Platform | Basis | Detail |
|---|---|---|---|
| Play Install Referrer | Android | Deterministic | Google Play passes a referrer string through the store to the installed app. When present it is exact — there is no inference involved. |
| Deferred click token | iOS (primary) | Deterministic | A token the tapped link leaves on the clipboard, recovered at first open. Exact when present. By default it is read only when the user taps a paste control, so it requires a deliberate action rather than silent clipboard access — apps can opt into an automatic read, or switch it off entirely. |
| Probabilistic match | iOS and Android | Inferred | Matches the install's IP address and platform against clicks inside the attribution window. Off by default, enabled per workspace, and consent-gated. Inferred rather than certain, and recorded as such. |
| SKAdNetwork / AdAttributionKit | iOS | Aggregated | Apple's own frameworks, running alongside the above. Aggregated, delayed, and conversion-value limited by Apple. No provider can enrich them. |
| Unattributed | Both | None | No token matched and no qualifying click was found. Reported as organic rather than assigned to the most plausible campaign. |
The final row is the one worth noting. An unattributed install is reported as organic rather than assigned to the most plausible campaign — the alternative is a number that always looks better and means less.
2. Probabilistic matching
Where no deterministic token is available, the workspace has switched probabilistic matching on, and consent has been granted, the install is matched against clicks in the window on two fields — the IP address and the platform — both compared for exact equality. That is the whole comparison. The table below lists every field the matcher reads, across both layers.
| Signal | Compared how | Notes |
|---|---|---|
| Click token | Exact equality | A 32-hex token minted at click time and carried through the install by the Play Install Referrer or the clipboard. Where it is present, matching stops here and the install is recorded as deterministic. |
| IP address | Exact equality | Observed server-side at click and at install; never read from the device. Mobile carrier NAT means many devices share one address, which is the main reason this layer is inferred rather than certain. |
| Platform | Exact equality | iOS or Android. Sent by the SDK where it is known, otherwise derived from the User-Agent of the click. The User-Agent itself is not compared. |
| Click recency | Within the window | The click must fall inside the workspace's attribution window — 7 days by default. Where several clicks qualify, the first or the last is chosen by the workspace's attribution model. |
What we do not compare
Screen dimensions, timezone, locale, device model and advertising identifiers are not part of the comparison, because they are never collected. The install endpoint validates its request body strictly and accepts only the app identifier, the platform, the click token, a device id and the consent flag — a request carrying a screen size or a timezone is rejected outright. The table above is the whole list, not the part we are willing to publish.
The outcome is binary — there is no score
A click is matched or it is not. There is no similarity function, no weighting and no confidence value anywhere in the system, so there is none to publish. What every install does carry is its match type — deterministic, probabilistic or none — which is what lets a report separate attribution that is certain from attribution that is inferred.
A weighted score would read as more rigorous and tell you less. The honest version of this control is the one we ship: decide whether inferred matching belongs in your numbers at all, per workspace, and know which installs came from it.
Off by default
Probabilistic matching is disabled for a new workspace and stays disabled until someone turns it on in the attribution settings. While it is off, an install with no deterministic token is recorded as unattributed rather than inferred — no IP comparison happens at all.
Attribution window
Seven days by default, configurable per workspace. The window is a precision control rather than a coverage setting: an IP address on a mobile network can change within minutes of a click and can be shared by thousands of devices behind carrier NAT, so a match at day six is a much weaker claim than one at minute two even though the record looks identical. Where more than one click qualifies, the workspace's attribution model decides whether the first or the last takes the credit. The window applies only to this layer — a deterministic token match is exact whenever it arrives.
3. What we don't do
- We never read the Apple IDFA, with or without App Tracking Transparency permission, and never read the Google Advertising ID. Device identifiers are vendor-scoped only — IDFV or App Set ID, with a random persisted UUID as fallback.
- We don't run probabilistic matching before consent, and we don't run it at all unless the workspace has switched it on. Links still route immediately; only the recording waits.
- We don't publish a confidence score, because we don't compute one. A match is binary, and the match type is recorded instead.
- We don't model the unattributed gap. An install with no qualifying match is reported as organic, not as a statistically likely campaign.
- We don't make payout decisions. Fraud scoring affects reporting only.
- We don't use end-user data to build advertising or marketing profiles. That commitment is contractual, in the DPA.
4. Reproducing this
If you're comparing LinkTrail against another provider, hold the window and the model constant and compare deterministic matches first — those are the figures both tools derive the same way. If deterministic counts agree, the tools agree and the rest is methodology. If they don't, there's an integration bug worth finding.
Citations and corrections are welcome. This page is versioned and dated; if you believe something here is wrong, write to support@linktrail.io and we'll correct it in the open. The implementation detail behind each layer is in the attribution documentation, and the legal analysis of probabilistic matching is published in full in our Data Processing Agreement.
Methodology — common questions
How does LinkTrail attribute installs without advertising identifiers?
Through a waterfall of four layers. Deterministic signals first — the Google Play Install Referrer on Android, and on iOS a click token the tapped link leaves on the clipboard, read by default only when the user taps a paste control. Where neither is available and the workspace has enabled it, matching falls back to comparing the install's IP address and platform against clicks inside the attribution window. Apple's SKAdNetwork and AdAttributionKit run alongside all of it for paid iOS network spend. The SDK never reads the Apple IDFA or the Google Advertising ID at any point.
Does a probabilistic match carry a confidence score?
No. The outcome is binary: a click is matched or it is not. What the install records instead is the match type — deterministic, probabilistic, or none — so a report can separate certain attribution from inferred attribution. We publish this rather than a score because a score we did not compute would be a more confident-sounding number, not a more accurate one.
What does probabilistic matching actually compare?
The IP address and the platform, and nothing else. Both are observed server-side — the IP from the connection, the platform from the SDK or the User-Agent of the click. No screen dimensions, timezone, locale, device model or advertising identifier is read from the device or accepted by the install API, which validates its request body strictly and rejects any field outside identifier, platform, click token, device id and consent.
Is probabilistic matching the same as fingerprinting?
We describe it as fingerprinting rather than using a softer term, on the basis that inferring one device from another event's characteristics is what Article 5(3) of the ePrivacy Directive is aimed at, and the EDPB's Guidelines 2/2023 confirm consent is required — legitimate interests does not cover it. Apple also restricts fingerprinting irrespective of App Tracking Transparency status. So we gate it: it is off by default, must be switched on per workspace, and does not run before consent is granted.
What attribution window does LinkTrail use?
Seven days by default, configurable per workspace. The window is a precision lever rather than a coverage setting, because an IP address on a mobile network can change within minutes of a click and can be shared by thousands of devices behind carrier NAT. A match at 90 seconds and a match at 6 days are the same binary outcome, but they are not equally strong claims — which is why the window is yours to set.
How should I interpret a match type in reporting?
As the answer to how the attribution was established, which is the closest thing to a confidence signal we have. Every install carries its match type. A report that blends deterministic and probabilistic matches into one attributed total will systematically overstate channels that attribute deterministically and understate those that do not — which is why match type should be a first-class column wherever installs appear.
Does LinkTrail make fraud decisions?
No. Installs are scored against velocity, device-signal, and spoofing heuristics, and the score is surfaced in reporting. That score affects what you see, not what anyone is paid — LinkTrail does not reject installs, arbitrate partner disputes, or make payout decisions.