Identity resolution: how user stitching actually works
Identity resolution stitches one person's scattered fragments (anonymous visitor, lead email, CRM contact, customer) into a single entity you can trust for revenue reporting. The match keys ranked, deterministic vs probabilistic settled honestly, a worked stitching pass, and where stitching fails.
The customer who just placed a $4,000 order is, as far as your systems know, three different people: an anonymous visitor your pixel saw last Tuesday, a lead your CRM opened on Wednesday, and an account billing created on Friday. None of the three is connected to the others, so the ad click that started it all gets credit for nothing. Identity resolution is the fix: it stitches those fragments into one entity using the keys they share (hashed email, user ID, click IDs, device IDs). User stitching is the mechanical pass that does the matching, and done right, your "three users" become one customer with one history.
The version you'll usually meet arrives inside a platform pitch, "unify your customer view," and stays carefully abstract. This page does the opposite: the real match keys ranked, the precedence rules that decide which identifier wins, a worked stitch you can follow, and the places stitching honestly fails. Buron ships an identity map as a warehouse dataset, a real stitching implementation, which is why this page can show the machine instead of selling the outcome.
#Why you have fragments at all
Fragmentation isn't a bug; it's unmatched data. Every system starts counting "a user" at the moment it first sees the person, keyed by whatever identifier it has at that moment:
- Anonymous visitor. The pixel sees a browser: a cookie ID, some pageviews, a gclid on the landing URL.
- Lead. The form gets an email; your CRM opens a contact. The CRM neither knows nor cares about the cookie.
- Customer. Billing or the order system creates its own record, keyed by order email or account ID.
Same human, three "users," three part-histories. Ad platforms then count their own version on their own IDs. Nothing here is broken; each system is correct in isolation. The connection is simply work nobody's system does by default; GA4's reporting-identity options (User-ID first, then device ID, then modeling) are that same problem being solved inside one tool, and the warehouse version below is the cross-stack generalization.
#The match keys, ranked
Stitching is only as good as its keys. Ranked by durability and trust:
- Hashed email. The workhorse. Survives devices and browsers, appears on both sides of most matches (forms, CRM, orders, ad-platform uploads), and hashing (SHA-256) lets systems match without passing the raw address. Weakness: work vs personal addresses fragment the same human.
- user_id. Your own login ID; authoritative wherever the person authenticates, absent everywhere they don't.
- Click IDs. Gclid, fbclid and family: deterministic but short-lived, and the only key that reaches back into ad clicks, the bridge between ad spend and everything else (Click IDs: what gclid, fbclid, and wbraid do).
- Device / cookie IDs. Plentiful but perishable: per-browser, per-device, and capped to days on Safari (Tracking after third-party cookies: what actually still works has the lifetimes).
The pattern: keys strong on one flank are weak on another, which is why a stitching pass uses all of them under precedence rules, not one "best" key.
#Deterministic vs probabilistic: the honest table
Our position, stated plainly: deterministic-first. Probabilistic matching is a reach extender for ad platforms, not a foundation for revenue data.
| Deterministic | Probabilistic | |
|---|---|---|
| Match basis | Exact shared key (hashed email, user_id, click ID) | Inference from device, IP, geo, behavior |
| A match means | Fact: these records share an identifier | Likelihood: these records look like one person |
| Wrong-match cost | ~zero when keys are handled correctly | Real, and invisible to you |
| Right use | Revenue matching, conversion uploads, LTV, reporting | Ad-platform audience extension, reach modeling |
| Auditability | Every merge traceable to a key | Depends on the platform's model |
Both have a place: platforms use probabilistic modeling to recover reach that privacy changes removed, and that's fine inside their walls. But money decisions ride on your matched data, and a merge you can't trace to a shared key is a merge you can't trust or debug. The test to run on any "360° customer view" pitch: name your match keys and their precedence. A platform that can't is selling confidence, not resolution.
#A stitching pass, worked
Here's the shape of the pass Buron's identity map runs in the warehouse, generic enough to sketch on your own stack. Take one person's fragments as they actually arrive:
| Fragment | Arrives with |
|---|---|
| Pixel events (Tuesday) | cookie ID c-91, gclid=Xk4… on the landing URL |
| Form fill (Tuesday) | email → hash e-7f2…, fired in session c-91 |
| CRM contact (Wednesday) | same email hash e-7f2…, deal attached |
| Order (Friday) | account u-1043, billing email → same hash e-7f2… |
The pass: collect keys per fragment → link fragments sharing any key
(the form fill connects c-91 to e-7f2…; the email hash connects web to
CRM to order) → merge into one entity under precedence, keeping every
source pointer. Result: one person, carrying the gclid from Tuesday's ad click
and Friday's order value, the row that lets revenue credit the campaign.
Two rules do most of the real work. Precedence: when sources disagree, the more authoritative key wins: email hash and user_id outrank cookie-level evidence, so a shared laptop can't overwrite a known customer. Conflicts split, not force: one cookie ID touching two email hashes is two people on one device, so the pass leaves them unmerged rather than inventing a person. Everything stays traceable: every merge cites the key that caused it, so a bad stitch can be found and unwound instead of silently poisoning downstream numbers.
#Where stitching fails
An honest implementation names its failure modes; here are ours:
- Shared devices. One browser, several humans: deterministic handling keeps them apart only if login or email events separate them.
- Consent-blocked keys. Where consent denies storage, the cookie and click-ID trail never exists; those journeys start at the first volunteered key, usually the form fill (Consent Mode v2 without losing your signal).
- Cross-domain loss. The session dies at an external checkout and the fragments arrive keyless, and stitching can't match what never carried a key (Cross-domain tracking: the checkout-domain trap is that failure mode end to end).
- Stale graphs. People change emails and companies; a stitch that was right last year drifts. Identity is a maintained table, not a one-time build.
The theme: stitching cannot create keys; it can only match the ones your collection layer captured, which is why identity quality is downstream of pixel and capture quality (First-party data: the definition and the operating model covers that collect-then-match ordering).
#What this buys your signal
Identity resolution isn't tidiness; it's what several other capabilities stand on:
- Trustworthy values. Revenue matched to clicks is what makes value-based bidding honest (Value-based bidding needs values you can trust) and predictive LTV trainable.
- Deduplication. One entity across platforms is the ground truth for spotting the same conversion claimed three times (Every platform claims the same conversion: why ad platforms overreport).
- One customer count. Marketing, product, and finance stop arguing about whose number is right, because the number resolves to the same entities.
And because it is the layer everything else in the Conversion tracking & signal quality argument rests on (bids are only as good as the signal you feed them), the stitched identity map is where signal quality stops being abstract.
The zoom-out worth keeping: identity resolution is never done. People change emails and jobs, new sources show up, consent states flip, and a graph that was right last quarter quietly rots. That's the real reason "unify your customer view" stays a slide at most companies. The one-time stitch is easy; the maintained one is the job. Buron ships the identity map as a dataset in your warehouse (visitors, leads, and customers stitched into one inspectable view, the precedence table above as the published contract rather than a black box) and keeps it current as new data lands, so the entity behind your revenue stays one entity. Connect your sources and see who your fragments actually resolve to. [Connect your sources →]
Frequently asked questions
What is the difference between deterministic and probabilistic identity matching?
Deterministic matching links records on exact shared keys (the same hashed email, user ID, or click ID), so a match is a fact. Probabilistic matching infers that two profiles are likely the same person from signals like device, location, and behavior. Deterministic is for revenue data; probabilistic extends ad reach.
What is user stitching?
User stitching is the mechanical pass that implements identity resolution: scanning event and record fragments for shared keys, linking fragments that match, and merging them into one entity under precedence rules that decide which identifier wins when sources conflict. The output is one customer with their full history.