NIELSEN VALIDATION OF DRAWBRIDGE (2015)
The question a marketer actually asks: of the journeys that touched my ads, how many did the graph join to the converting person?
ACCURACY (THE FLATTERING NUMBER)
97.3%
Counts correctly identified non-matches too. This is the figure vendors quote.
MATCH RATE (THE ONE ATTRIBUTION NEEDS)
10.3%
The share of users actually linked. About 10 journeys joined per 100 attempted.
Same system, same test, two numbers that differ by 87 points. Attribution accuracy is bounded by the right one, and it is rarely the one on the slide.
The lesson generalises past 2015. When any identity vendor hands you a match-rate figure, it is always conditional on the keys it had to work with. LiveRamp reports a 99.5% match rate, but only when onboarding first-party data with complete address information: name plus postal address. Most digital-only attribution setups never hold that. A near-perfect match rate is real for the conditions it was measured under, and those conditions are the whole story.
## Deterministic versus probabilistic: narrow and sharp, or wide and soft
There are two ways to decide that two touchpoints belong to the same person, and the tradeoff between them is the reason you cannot simply buy a high ceiling.
Deterministic matching uses an exact identifier the person supplied: an email, a phone number, a hashed login token. Industry benchmarks put it at roughly 100% confidence on the records that match, but it only matches the smaller share of traffic where such an identifier exists. Probabilistic matching uses device fingerprint, IP, browser signals and behaviour to guess. It extends reach a long way but lands around 70 to 80% accuracy on what it does match. The two effects compound. A vendor claiming a 70% match rate via probabilistic methods is delivering roughly 50% accurately resolved records once you multiply reach by per-match accuracy.
Probabilistic error also compounds across links, and this is the part that surprises people. At 80% accuracy per link, each extra device you try to chain multiplies the error.
| Devices in the journey | Probabilistic stitch accuracy (0.8 per link) |
|---|---|
| 2 touchpoints | 80% |
| 3 touchpoints | 64% |
| 4 touchpoints | 51% |
| 5 touchpoints | 41% |
The arithmetic is just 0.8 raised to the number of links, so you can check it yourself. SegmentStream, which frames it this way, draws the blunt conclusion: by the time a user has interacted across three devices, statistical identity matching is barely better than a coin flip. That is why serious cross-device stitching leans on deterministic signals and treats probabilistic matching as a soft fallback, not a foundation.
## The key-strength table
Rank stitch keys by how reliably they join two touchpoints, and a pattern falls out. The keys at the top are accurate but narrow. The keys at the bottom are wide but soft. Reliability figures below are directional benchmark bands, not one cited study, so read the join-reliability column as typical rather than precise.
| Stitch key | Type | Typical join reliability when present | Coverage (share of traffic it can join) | Failure mode |
|---|---|---|---|---|
| `user_id` (authenticated login) | Deterministic | ~100% | Logged-in sessions only | Blind to the entire pre-login and anonymous top of funnel |
| Hashed email (SHA-256) | Deterministic | ~100% on exact match | Roughly 60 to 80% of a clean, engaged list | No email captured, no join; typos and multiple addresses fragment |
| Hashed phone (E.164) | Deterministic | ~100% on exact match | Lower than email in most digital funnels | Format normalisation errors; sparse in web-first funnels |
| Click ID (gclid / fbclid) | Deterministic-ish | High within the platform | Paid-click sessions only | Platform-scoped; degrades under ITP; no organic or direct join |
| First-party cookie / device ID | Pseudonymous | Single-device only | High on that one device | 7-day ITP expiry; wiped on clear or incognito; no cross-device |
| IP + user-agent / fingerprint | Probabilistic | ~70 to 80% per link | Wide but soft | Compounds to ~51% at four touchpoints; shared IPs create false merges |
The load-bearing point sits under the table. You do not escape the tradeoff by picking one row. You raise the ceiling by capturing more deterministic keys server-side: email, phone and user_id sent from your backend, not scraped from a cookie the browser is about to expire.
## Why the browser clock caps client-side stitching
Client-side stitching has a hard structural limit that has nothing to do with your data quality. Apple's Intelligent Tracking Prevention expires JavaScript-set first-party cookies after 7 days, and after 24 hours for domains it classes as trackers. A user who clicks a campaign and returns 8 or more days later on Safari is treated as a brand-new visitor. The user ID resets, the session history is severed, and the conversion misattributes.
Any consideration window longer than a week loses its true source on Safari. For considered B2B purchases and most high-ticket e-commerce, a week is nothing. This is the bridge to why server-side matters: server-side identity is not subject to the browser cookie clock. Your backend already knows the email on the order and the user_id on the login, and it can send them regardless of what Safari did to the cookie in between.
## Two versions of the same journey
The same buyer, measured two ways, produces two different channel rankings from identical ad spend. The difference is entirely identity.
SCENARIO ONE — THE THREE-DEVICE GHOST (COOKIE-ONLY)
A B2B buyer researches on a work laptop (Google search then blog), reads on their phone during the commute (LinkedIn ad then pricing page), and converts on a home desktop (direct then demo request) 9 days later. Cookie-only tracking, Safari on the phone.
The result is three separate pseudonymous users. The phone's cookie is irrelevant to the others, and the desktop conversion lands past the 7-day ITP window, so it resets. Last-touch credits Direct with 100% of the conversion. The Google and LinkedIn touches are stranded on ghost users that never converted.
The blended report now shows one conversion attributed to Direct, plus two engaged non-converting users. The paid channels that actually started the journey get zero credit, and the direct-and-unknown bucket inflates. No model fixes this. Markov and Shapley redistribute credit inside the one journey they can see, and that journey is one touchpoint long.
SCENARIO TWO — SAME JOURNEY, HASHED-EMAIL STITCH, SERVER-SIDE
Same buyer, but the blog gates one asset behind an email and the pricing page fires a server-side event carrying the hashed email. The login at demo request supplies a user_id.
The email hash joins the laptop and phone sessions. The user_id joins the desktop conversion to both. One user, three touchpoints, the full path recovered. Now the models disagree usefully: last-touch says Direct, first-touch says Google, and Markov and Shapley split across Google, LinkedIn and Direct. The spread between them is the signal.
The stitch rate went from fragmenting the journey into three to resolving it into one. The attribution question only becomes answerable at this stitch rate. Below it, you are not choosing a model. You have no journey to model.
The same fragmentation scales to a portfolio and distorts the whole channel mix. Take 1,000 real converting buyers, each averaging 2.4 devices across a 10-day consideration window. Suppose a cookie-only setup stitches at an effective 55% and a server-side setup with hashed email reaches 85%. Treat those two numbers as illustrative assumptions rather than measured constants: the exact multiplier depends on device overlap, but the direction is defensible.
At the 55% stitch, journeys fragment enough that the platform reports materially more than 1,000 converting users, because the same purchase surfaces under multiple unstitched IDs, and the opening paid touch goes missing on roughly 45% of paths. Top-of-funnel channels are systematically undercredited and the direct-and-unknown bucket is systematically overcredited. At 85%, the converting-user count converges toward the true 1,000 and the first-touch paid channels reappear in the credit distribution. Two setups, one ad spend, two different channel rankings, and the difference is identity, not the model.
## What stitching does not fix
A skeptical, senior reader trusts a piece more when it names its own limits, so here they are in the open rather than buried.
Stitching does not make attribution causal. A perfectly stitched journey still only shows correlation of exposure with conversion. A 100% stitch rate does not make last-touch causal and it does not make Shapley causal. Identity sets the ceiling on observational attribution accuracy. Incrementality, whether from geo-lift, holdouts or a marketing mix model, is a separate question that stitch rate does not answer.
A higher match rate can lower accuracy if you buy it probabilistically. More stitching is not automatically better. A probabilistic graph that pushes match rate to 85% by fingerprinting is merging some wrong people: shared household IPs, office NAT, family devices. False merges corrupt journeys in the opposite direction by inventing paths that never happened. Deterministic-narrow can beat probabilistic-wide. The target is deterministic stitch rate, not raw match rate.
Server-side is not itself a stitch key. It raises the ceiling by capturing more deterministic identifiers and dodging the browser cookie clock, but if you never collect an email, phone or login, server-side alone still cannot join an anonymous multi-device journey. It is necessary, not sufficient.
Consent and privacy cap the achievable ceiling by design. After GDPR and CCPA, some journeys are legitimately un-stitchable because the user declined tracking or you have no lawful basis to join the keys. The realistic ceiling sits below 100% and that is correct, not a defect. Worth noting: younger, higher-income and privacy-active users match worse, so your unstitched segment is non-random. That biases the channel mix, not only the volume.
And a single reconciled number is still a model output. Even at a high stitch rate, the credit split is an opinion the model made. Identity fixes the inputs. It does not turn the output into ground truth. That is the honest frame for any attribution number: raising the stitch rate stops the model being fed garbage, and it leaves the model itself visible and swappable rather than pretending the number came from physics.
## A note on the numbers in this article
Most figures in identity resolution are vendor-published. LiveRamp's 99.5%, SegmentStream's compounding table, the 60 to 80% hashed-email band: read those as benchmarks the vendors themselves publish, which if anything reinforces a skeptical reading. The one genuine third-party validation, Nielsen on Drawbridge, is a decade old and was itself the subject of a which-stat-flatters-us argument. Cite ranges, attribute vendors as vendors, and do not treat any benchmark band as a measured constant. The direction of every claim here holds regardless. The precise multipliers do not, and this article does not ask you to trust them as if they did.
## Further reading
**On the data layer underneath attribution:**
- [Server-Side vs Client-Side Tracking](/articles/server-side-vs-client-side-tracking): why the capture method sets your ceiling
- [iOS and iPhone Tracking's Effect on Attribution](/articles/iphone-ios-tracking-attribution): the privacy features that sever journeys
**On what the model does with the journey:**
- [Count Your Conversions Before You Credit Channels](/articles/count-conversions-before-crediting-channels): dedupe before you attribute
- [What Is Multi-Touch Attribution?](/articles/what-is-multi-touch-attribution): how the models divide credit inside a journey
## Key takeaways
- Attribution runs on top of identity. Every model divides credit inside a journey that identity resolution stitched first, so the model can only be as good as the journey it is handed.
- Match rate and accuracy are not the same number. Drawbridge scored 97.3% accuracy on a 10.3% match rate. Accuracy counts correct non-matches too; match rate is the share of journeys you actually join, and that is what attribution depends on.
- A low stitch rate loses data and manufactures fake users on top of it. One person on three unstitched devices becomes three users, splitting one journey and one conversion across ghosts.
- Deterministic keys (user_id, hashed email, hashed phone) are near-perfect when present but narrow. Probabilistic matching is wide but soft, and its error compounds to roughly a coin flip by the fourth device.
- Server-side capture raises the ceiling by collecting deterministic keys your backend already holds and by dodging Safari's 7-day cookie expiry. It is necessary but not sufficient, and stitching well never makes attribution causal.
## FAQ
**What is the difference between match rate and accuracy in identity resolution?**
They measure different things. In Nielsen's validation of Drawbridge, the graph was 97.3% accurate but matched only 10.3% of users. Accuracy includes correctly identified non-matches, so a system can look almost perfect while joining a tenth of the journeys it sees. Match rate is the share of journeys you actually stitch, and that is the number attribution depends on. When a vendor quotes accuracy, ask what the match rate was.
**Does a higher stitch rate always mean better attribution?**
No. A probabilistic graph can push match rate up by merging people who are not the same person, such as two colleagues behind one office IP or family members on a shared home network. False merges invent journeys that never happened, which corrupts attribution in the opposite direction. What matters is the deterministic stitch rate, not raw match rate. More matched is not the same as correctly matched.
**Which stitch keys should I prioritise collecting?**
Deterministic identifiers first: an authenticated user_id and a hashed email are close to 100% reliable when present. Hashed phone next. Treat a first-party cookie or device ID as single-device only, and treat IP plus user-agent fingerprinting as a soft fallback whose error compounds across devices. The goal is to capture more deterministic keys, not to widen a probabilistic graph.
**How does server-side tracking raise the stitch rate if it is the same data?**
It is not the same data in practice. Server-side capture sends deterministic keys your backend already holds, such as the email and user_id from a completed order or login, and it is not subject to Safari's Intelligent Tracking Prevention, which expires JavaScript-set cookies after 7 days. It cannot invent a key you never collected, but it stops you losing the keys you have to browser expiry, ad blockers and incognito sessions.
**If I get stitching right, does attribution finally measure the true impact of each channel?**
No, and this matters. Identity sets the ceiling on observational attribution: it decides how much of the journey the model can see. It does not make attribution causal. A perfectly stitched journey still only shows correlation of exposure with conversion. For incremental impact you still need geo-lift tests, holdouts or a marketing mix model. Stitching makes multi-touch attribution honest, not causal.
**Why do my platform reports show more converting users than I actually have?**
Fragmentation. When one buyer moves across three devices with no shared deterministic key, the platform sees three separate users. If the same purchase surfaces under more than one of those unstitched IDs, the converting-user count inflates above the true number while the touchpoint that started the journey goes uncredited on the ghost that did not convert. Raising the stitch rate pulls the reported count back toward reality.