Identity resolution
Identity resolution (user stitching) connects events and records carrying different identifiers (hashed email, user ID, click ID, device ID) into one person.
The anonymous pageview, the click ID from an ad, the form fill with an email, the CRM contact, the order: without stitching, one customer looks like five strangers across your sources. A trustworthy implementation uses named match keys with an explicit precedence, deterministic first (hashed email, then a durable user ID, then click IDs, then device identifiers), and is honest about where matching fails: shared devices, consent-blocked keys, sessions broken at domain boundaries.
#Stitching connects; deduplication removes
The two are routinely confused and solve opposite problems. Dedup removes extra copies of one event (the same purchase sent by pixel and server). Stitching connects different events to one person.
In practice: Buron ships an identity-map dataset with exactly that key precedence; its attribution datasets stand on it.
Which keys match, in what order, and what happens on conflicts: Identity resolution: how user stitching actually works.
Related terms
Click ID (gclid / fbclid / wbraid)
A click ID is a unique URL parameter an ad platform adds at click time (gclid, fbclid, msclkid, ttclid) so a conversion can be matched back to the exact ad click.
Cross-domain tracking
Cross-domain tracking keeps a visitor recognized as one session when they move between domains you own, by passing the identifier across the domain boundary.
First-party data
First-party data is data you collect from your own audience on your own surfaces (site events, CRM records, order history) under your direct consent.