Deterministic attribution

Definition

Deterministic attribution credits an install to a specific click by matching an identifier that is present in both records, producing a one-to-one link rather than a statistical estimate.

The word that matters is *carried*. A deterministic match works because something — a click ID, a referrer string, an attribution token — physically travels from the click to the install and arrives intact. Where that carrier exists the answer is exact; where it does not, no amount of modelling turns a guess into a match. Most of the confusion in mobile attribution comes from treating a platform without a carrier as a measurement problem rather than a plumbing one.

The carriers that still work

There are fewer of these than there were in 2018, and the surviving list is short enough to hold in your head. Each one is a different mechanism with different failure conditions, which is why an integration that relies on exactly one of them is fragile by construction.

What a deterministic match actually looks like

The click writes a record keyed by an ID it also puts in the outbound URL. The install reports the same ID back. There is no matching algorithm — it is a join on a primary key, which is exactly why it does not degrade with volume, geography or time.

# 1. The click. Your link service records clk_4b7d2e and redirects to
#    the Play Store with the same value inside the referrer parameter.
https://go.example.com/spring?clk=clk_4b7d2e
  -> https://play.google.com/store/apps/details
       ?id=com.example.app
       &referrer=clk%3Dclk_4b7d2e%26utm_source%3Demail

# 2. The install. The Play Install Referrer API returns it verbatim,
#    with the two timestamps that make the match auditable.
installReferrer          = "clk=clk_4b7d2e&utm_source=email"
referrerClickTimestamp   = 1755388800
installBeginTimestamp    = 1755388930

# 3. The join. Not a heuristic — the same string on both sides.
SELECT * FROM clicks WHERE click_id = 'clk_4b7d2e';

Note the URL encoding in step 1. The referrer value is a query string nested inside a query parameter, so its & and = characters must be percent-encoded. An unencoded ampersand truncates the referrer at the store boundary and every parameter after it disappears — a silent, total loss that looks exactly like a tracking bug because it is one.

Where the chain breaks in practice

Almost every unattributed install traces to one of a handful of breaks, and they are ordered here by how often they turn out to be the cause. Why are my installs unattributed walks the full diagnostic; this is the short version.

1. The link never carried anything. An untagged link cannot produce a deterministic match no matter what the SDK does. This is the largest single cause and the cheapest to fix.
2. The redirect dropped the parameters. A marketing redirect, a consent gate, or a CDN rule that strips query strings ends the chain before the store.
3. The ampersand was not encoded. Silent truncation of the Android referrer at the first raw &.
4. An in-app browser ate the click. A webview that never hands off to the system browser cannot open the app, and often cannot preserve the click either — see deep links in in-app browsers.
5. There is genuinely no carrier. An iOS install from a non-Apple ad where the user did not use the paste button. Nothing is broken; the platform simply provides no path.

A healthy setup therefore reports three buckets rather than one: deterministically matched, aggregate-only (SKAN or AdAttributionKit), and unattributed. The third number is not a failure metric — it is the size of the population about which you should be reasoning statistically rather than individually.

One more property is worth stating plainly because it decides audits. A deterministic match is reproducible: given the same click table and install table, the same join produces the same answer next year. A probabilistic match is a model output, and re-running it against a retrained model produces a different history. Only one of those two survives a finance review.