Deterministic vs Probabilistic Attribution Explained

Deterministic and probabilistic attribution differ in how a visit gets linked to a person or a sale. Deterministic attribution reads that link from an identifier that is actually there, such as a click id, a login, an email or a visitor id passed to checkout. Probabilistic attribution infers the link from statistical similarity, such as IP address, device and timing, and so carries uncertainty.

What is the difference between deterministic and probabilistic attribution?

Every attribution report must answer a question before any credit rule runs: which visit does this sale belong to? Rules such as linear or time decay (see attribution models explained) split credit among visits, but they assume the visits were linked correctly. These two terms describe how that link is made.

• Deterministic: two records are joined because they carry the same identifier. The identifier is either on both records or it is not. There is no partial match.
• Probabilistic: two records are joined because they look alike. A model compares signals and decides that a visit and a sale probably belong together. The result is a likelihood, not a fact.

You will also see “modeled attribution” on vendor pages. It is used loosely: sometimes it means probabilistic matching, sometimes a statistical estimate that fills gaps. Ask which one a vendor means.

How do they compare side by side?

	Deterministic	Probabilistic
What the link relies on	An identifier present on both records: a click id, a login, an email, a first-party id	Similarity between signals such as IP address, device and timing
What it can get wrong	It misses people who never leave an id. It does not link them wrongly; it does not link them at all	It can merge two people into one or split one person into two, and it can attach a sale to the wrong visit
What you can audit	Each link: open the record and read the id on both sides	The rules and the score, if the vendor shows them. You cannot check the guess against an id, because there is none
What happens when data is missing	The visit stays unlinked	A model typically fills the gap with its top candidate
How coverage grows	By getting more visits and sales to carry an id	By adding signals and tuning the model

In short: deterministic fails by leaving gaps, probabilistic fails by filling them. They call for different checks.

What does the same sale look like tied both ways?

This is an illustrative example with made-up values, not customer data. A shop records a $120 sale. The buyer clicked a Meta ad earlier in the week, browsed on a phone, and paid on a laptop.

Tied deterministically. The checkout page passes the visitor id it read from the browser. The same id sits on the ad-click visit. The tool joins them. The record says: matched on visitor id, ad click id present. You can open both records and see the id on each.

Now remove the id: the buyer paid in a different browser, so the checkout carries none. A deterministic tool finds no link and reports the sale as unlinked or Direct. That is a visible gap.

Tied probabilistically. With no id, the model looks for visits that resemble the buyer. Two candidates turn up: a paid social visit and a paid search visit, both from the same network and a similar device within the same day. Suppose it scores them 0.6 and 0.5 and picks the higher one. The report shows paid social with no mention of the runner-up.

Two things could be wrong and neither can be checked. The paid social visit may have been a colleague on the same office network, or the real buyer may have been the other visitor. The report reads the same either way. Credit given to a guess looks like credit given to a certainty unless the tool labels it.

Why would a tool use one or the other?

Deterministic matching is used where an identifier is reliably present, such as ad click ids, logins and checkout forms. It suits teams that want each credited sale to be traceable and can accept a smaller linked share. See click ids explained for how these ids travel.

Probabilistic matching is used where ids are often missing and a tool wants to report on more visits. The cost is that the extra coverage is inferred, not read.

Two terms come up when judging either:

• Identity resolution is the work of deciding which records belong to the same person. Deterministic tools do it with ids and probabilistic tools do it with similarity scores.
• Match rate is the share of records that got linked. A high match rate says how much was linked, not how many links are right. Ask how a vendor counts it, and whether guessed matches are included.

Cross-device is where the gap shows most. A phone visit and a laptop purchase stay two devices unless a login, a form or an email ties them. A probabilistic tool may infer the tie, and may infer it wrongly.

What are the honest trade-offs?

Deterministic matching:

• Strength: every link can be inspected. If a number looks wrong, open the records and find out why.
• Limit: it covers what carries an id, so a report built on few ids is a partial view. Logged-in users are easy to link; an anonymous visitor who pays as a guest on another device may not be.

Probabilistic matching:

• Strength and limit: it can cover visits that carry no id, but it can merge two people or split one, quietly.
• Limit: a guessed match cannot be inspected the way an id can. You cannot check a single link against the ground truth.
• Limit: a score is not a confidence you can verify; a precise-looking number can sit on a loose guess.

Neither approach measures what caused a sale; both decide which visit to credit. The multi-touch attribution guide treats the journey and the credit rule as separate questions.

What about privacy?

Probabilistic matching often leans on signals, such as network address and device characteristics, that raise privacy questions. Rules on what you may collect, how you must explain it and whether consent is needed differ by region and by situation. Deterministic matching is not exempt: logins, emails and visitor ids can also be personal data, depending on the setting. This post is not legal advice, so check what a tool collects and how it matches with a qualified adviser who knows where your visitors are. The first-party data guide covers what is meant by data you collect yourself.

What should you ask a vendor?

Use these on any tool, including ours.

1. What is each record matched on? Ask for the list of signals or ids, not a summary.
2. Can I see the match type per record? You want a visible label such as “click id”, “visitor id” or “inferred”. If every record looks the same, you cannot separate read links from guessed ones.
3. Is a guessed match ever shown as certain? Check whether inferred sales are mixed into the same revenue number as id-matched sales, and whether you can filter them out.
4. What happens when an id is missing? The answers are usually: the visit stays unlinked, it is filed as Direct, or the model fills it in. Each is a different policy and you should know which one you have.
5. How is the match rate counted, and what does “modeled” cover? Ask whether inferred links are included.
6. What is stored to do the matching, and where? Take the answer to your adviser.

What does SourceTrack do?

SourceTrack ties revenue credit to a visit through an id it can read: a click id, the first-party visitor id, the visitor id passed at checkout or a form, or an exact identifier such as an email or an order id that a payment or CRM stage carries. It does not use guessed matches to credit revenue. If an id matches more than one visitor, or none, the payment is recorded as unattributed instead of being assigned to a channel by guess. A visit that arrives with no tag and no referrer reads as Direct.

A Stripe or Shopify payment can be tied to the visit that produced it when the visitor id is passed at checkout. The standard tracker keeps an anonymous first-party id in the visitor’s browser storage on your own domain. Cookieless Mode, a per-site setting, writes no cookies and keeps no visitor id on the device; the trade is the memory between visits.

The share of sales that link depends on how many visits and checkouts carry an id. Tagging links and passing the visitor id at checkout raises it. See the attribution page for the models that split credit once the link exists, and the cookieless attribution guide for what changes when less is stored.

Further reading

• Google Ads Help: About attribution models: how Google Ads shares credit for a conversion between ad interactions.
• WebKit: Tracking Prevention in WebKit: how Safari limits third-party cookies and script-written storage.

Frequently asked questions

Is deterministic attribution more accurate than probabilistic?

Not by definition. Deterministic attribution is more auditable, because every link rests on an identifier you can look up. Its accuracy depends on how many visits and sales actually carry an id. Probabilistic attribution can reach visits that carry none, but each guessed link carries uncertainty that you cannot inspect record by record.

What is deterministic matching?

Deterministic matching joins two records when they share the same identifier, such as a click id, a login, an email address or a visitor id passed to checkout. If the identifier is present on both sides, the records are linked. If it is missing on either side, there is no match and no guess is made.

What is probabilistic matching?

Probabilistic matching links records that look statistically alike, using signals such as IP address, device type and timing, and assigns a likelihood to the link. It does not need a shared identifier, which is why it can cover more visits. It can also join two different people or split one person in two.

Do ad platforms use deterministic or probabilistic attribution?

Many reports mix the two, and the labels differ by platform, so read each platform’s own documentation. A column marked as modeled or estimated usually means some links or conversions were inferred rather than read from an id. Ask what the label covers before comparing that number with your own records.

Can I use both approaches together?

Some tools do, usually by matching on ids and inferring the remainder. That is workable if the tool marks each record with its match type, so you can filter the guessed links out. If it blends them into one number with no label, you cannot tell how much of the total is inferred.

Next step

1. Open ten recent sales and note how each was linked: an id, or a guess. If you cannot tell, that is a finding in itself.
2. Tag the links you control (the touchpoint guide explains what counts as one) and install the tracker with the quickstart.
3. Pass the visitor id at checkout, and read how a payment returns to its source in closed-loop attribution.
4. Send the vendor questions above, in writing, to any tool you are considering.

Start 28-day free trial, no card needed, or see how the attribution models read the same linked journeys.