Every attribution carries a confidence score. Here is how it is calculated.

Ask an attribution platform why it credited an install to a particular campaign and you usually get a category name back. Deterministic. Probabilistic. Last click. The label tells you which family of technique was used. It tells you nothing about whether this specific match is worth trusting.

That gap matters most exactly when the stakes are highest. A fingerprint match made eleven days after the click, from a device sharing a network with two hundred others, gets reported with the same confidence as a deterministic match made forty seconds after a click. Both arrive as one row in your installs table.

We score every attribution from 0 to 100 and store the derivation alongside it. Here is the whole calculation.

The matching hierarchy

Before any scoring happens, we try to match an install to a click in a fixed order. The first method that produces a candidate wins, and we stop looking.

1. Install referrer. The click identifier survived the trip through the app store install. This is the strongest signal available on Android.
2. Click identifier. The SDK parsed the identifier out of a deep link the user opened.
3. Advertising identifier. An exact match on the advertising identifier, taking the most recent click among the top candidates.
4. Fingerprint. An exact match on a hashed device fingerprint, again taking the most recent click.
5. Organic. Nothing matched.

The ordering is not arbitrary. Each tier is a weaker claim than the one above it, and the base score reflects that.

Base scores

The gap between 95 and 70 is the interesting one. A click identifier that travelled through the install is direct evidence connecting a specific click to a specific install. An advertising identifier match is an inference: this device saw a click, and this device later installed, so the two are probably related. Usually correct, occasionally not, and the score should say so.

Fingerprint matching starts lower still. Today it requires an exact hash match, so the similarity term is always 1.0 and the tier tops out at 55. Component level similarity scoring is not shipped yet, and until it is we would rather cap the tier than imply precision we do not have.

The modifiers

A base score is a starting point. Four adjustments follow.

Device uniqueness bonus, up to plus 10. Fingerprints built from unusual device configurations are less likely to collide. We measure the entropy of the fingerprint components and add up to ten points for a distinctive device. This applies only to the inference tiers, since a click identifier match does not need corroboration.

Time delta penalty, up to minus 15. A match inside twenty four hours is unpenalised. Past that, the score drops three points for each additional day, to a floor of minus fifteen. The reasoning is that the longer the gap between click and install, the more other explanations exist. Again, inference tiers only.

Shared network penalty, minus 10. When the click and the install came from the same masked network block, a fingerprint match is materially weaker, because a shared office or campus network produces many devices with similar signatures. This penalty applies to the fingerprint tier alone.

Fraud penalty, up to minus 10. Every event carries a fraud score. High fraud scores subtract from attribution confidence proportionally, one point for every ten points of fraud score. This one applies to all tiers, including the deterministic ones, because a compromised device can produce a technically valid click identifier.

The result is clamped to the range 0 to 100.

The floor

Here is the part that costs us numbers on a dashboard.

If a match scores below 20, we do not report it. The attribution is downgraded to organic and the click identifier is cleared.

We could report those matches. They would inflate the attributed share of installs, which is the number most people look at first. But a confidence of 14 means we genuinely do not know, and a platform that dresses up "we do not know" as an attribution is not measuring anything.

What we do instead is keep the evidence. The rejected candidate is stored on the attribution record with the reason it was rejected, including the method that produced it and the score it failed to clear. When you look at an organic install and wonder whether it really was organic, that trail is there.

Why publish the arithmetic

Two reasons.

The first is practical. If you know a fingerprint match carries a shared network penalty, you know why your office Wi-Fi testing produces lower scores than you expected, and you stop filing it as a bug.

The second is that a confidence score you cannot audit is just a number with a reassuring name attached. The point of publishing the formula is that you can disagree with it. If you think twenty four hours is the wrong threshold for the time penalty, that is a conversation we can have, because the threshold is written down rather than buried in a model nobody can inspect.

Every attribution record stores the signals used, the reason in plain language, and the candidates that lost. The score is the summary. The trace is the evidence.