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 use, what each is worth, where the threshold sits, 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 | Confidence | 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 and Android | Deterministic | A token issued at click time and recovered at first open where the click path allows it. Exact when available. |
| Probabilistic match | iOS and Android | Scored | Compares device and network characteristics observed at click and at install. Consent-gated, scored, and never reported as certain. |
| 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 match met the confidence floor. 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. The probabilistic scoring model
Where no deterministic signal exists and consent has been granted, five characteristics observed at click and at install are compared and weighted into a single score between 0 and 1.
| Signal | Weight | Why |
|---|---|---|
| IP address | 0.40 | Strongest single signal, but mobile carrier NAT means many devices share one address. Deliberately capped below 0.5 so it can never carry a match alone. |
| User agent | 0.25 | Fine-grained in browsers, coarse in apps. Compared by similarity rather than equality. |
| Screen dimensions | 0.15 | A device-class signal. Discriminating when combined with model hints, weak alone. |
| Timezone | 0.10 | Narrows geography without identifying it. Stable over the matching window. |
| Locale | 0.10 | Language and region. Cheap to compare and more discriminating than its weight suggests. |
The confidence floor
A match is only recorded at 0.6 or above. That sits deliberately above the midpoint, because the two error types are not symmetrical. A false negative under-credits a paid campaign and someone investigates. A false positive credits paid spend for an organic install, inflates return on ad spend, looks like success, and attracts more budget — nobody investigates a number moving the right way.
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, while a timezone effectively never does, so the same score means less at day six than at minute two.
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. Links still route immediately; only the recording waits.
- 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 a deferred click token where the click path allows it. Where neither is available, matching becomes probabilistic and is scored rather than asserted. 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.
What is the confidence floor and why is it 0.6?
It is the minimum score a probabilistic match must reach before an install is attributed. It sits above 0.5 because the two error types cost different amounts: a missed match under-credits a campaign and gets investigated, while a false positive credits paid for an organic install, inflates ROAS, looks like success, and gets more budget. The threshold is set where a false positive is more expensive than a missed match.
Is probabilistic matching the same as fingerprinting?
Yes, and we describe it that way rather than using a softer term. Comparing device and network characteristics to identify a device is fingerprinting under Article 5(3) of the ePrivacy Directive, and the EDPB's Guidelines 2/2023 confirm it requires end-user consent — legitimate interests does not cover it. Apple also restricts it irrespective of App Tracking Transparency status. It is off until consent is granted and can be disabled entirely per workspace.
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 signals decay at different rates — an IP address on a mobile network can change within minutes of a click, while a timezone effectively never does. A match at 90 seconds and a match at 6 days are not equally strong claims even at an identical score.
How should I interpret a match type in reporting?
As the answer to how confident the attribution is. Every install carries its match type and, where probabilistic, its score. A report that blends deterministic and scored 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.