Probabilistic attribution

Definition

Probabilistic attribution estimates which ad interaction most likely caused an install by inferring a match from signals such as timing, network and device characteristics rather than from an identifier shared by both records.

It is the answer to a real problem: on iOS, a large share of installs arrive with no carrier at all, and a business still has to decide where to spend. The difficulty is that the term covers two very different practices — legitimate aggregate modelling, and device fingerprinting, which Apple prohibits outright. Treating them as one thing is how teams end up with a policy violation they did not intend to buy.

Three different things wear this label

The word *probabilistic* is doing a lot of work in vendor marketing, and the three practices it covers have almost nothing in common except that none of them is a join on a key. Separating them is the first useful step, because their accuracy, their unit of analysis and their policy standing all differ.

The other three rows are ordinary statistics and are how serious measurement gets done in a world without user-level joins. They give up the ability to name the click behind a specific install, which is a real loss, in exchange for answers that survive scrutiny.

Why per-install accuracy collapses at low volume

The failure mode is structural rather than a matter of model quality. Matching works by narrowing candidate clicks until one remains; how well that works depends entirely on how many candidates share the same coarse signals in the same time window.

-- How many clicks could plausibly explain each install, given only
-- coarse signals? If this number is not close to 1, a "match" is a
-- coin toss dressed up as a result.
SELECT
  i.install_id,
  COUNT(c.click_id) AS candidate_clicks
FROM installs i
JOIN clicks c
  ON  c.country      = i.country
  AND c.os_version   = i.os_version
  AND c.device_model = i.device_model
  AND c.clicked_at BETWEEN i.installed_at - INTERVAL '24 hours'
                       AND i.installed_at
GROUP BY i.install_id;

-- Rural, low-traffic campaign  -> candidate_clicks = 2   (plausible)
-- Metro, high-traffic campaign -> candidate_clicks = 8400 (a guess)

Run that query against your own data and the shape of the problem is immediate. Accuracy is not a single number a vendor can quote; it is a function of traffic density, campaign concentration and window width, and it is worst exactly where budgets are largest.

Using it honestly

The workable posture is to stop asking probabilistic methods to do a deterministic job. They are poor at naming the click behind one install and genuinely good at estimating how much a channel moved a total — so use them at the altitude where they are strong.

1. Maximise the deterministic base first. Tagged links, correct referrer encoding and the AdServices token cost nothing and shrink the population you have to model. See deterministic attribution.
2. Report modelled numbers in their own column. Merging a modelled install into the same total as a matched one destroys the only signal about confidence you had.
3. Use aggregate platform reporting for iOS ad channels. SKAdNetwork and AdAttributionKit are the sanctioned aggregate paths; they are coarse, delayed, and permitted.
4. Validate with a holdout. A geo split or a scheduled pause is the only method that tells you what would have happened anyway, which is the question budget decisions actually turn on.
5. Never let a modelled number become a payout basis. Paying a partner on an estimate they can influence is an incentive problem, not a measurement one.

There is one more reason to keep the two columns apart, and it is operational rather than philosophical. A modelled attribution changes when the model is retrained, so last quarter's report can move after the fact. A deterministic match cannot. If your reporting cannot say which of its numbers are stable, nobody downstream can either.