Deterministic Identity Resolution, Precision First

Precision over recall, and here is what that costs: A false merge costs more than two profiles left apart. Collapse two people into one and the error propagates into every downstream tool within a sync cycle, and it is close to impossible to unwind once an email platform, an ads destination and a support tool have each copied it. So I build to a false-merge rate stated as a number, under one in ten thousand merges, verified against a hand-labelled sample of 500, and accept a match rate lower than any vendor demo will show you. Deterministic evidence only: Keys ranked: authenticated user id, order email, hashed email from a form submission, phone in E.164 where the source is reliable. Each key carries a confidence and a rule about what it may merge. No device graphs. No IP-plus-user-agent fingerprinting, no third-party identity vendor. Under the ePrivacy rules the Irish Data Protection Commission enforces, probabilistic cross-device matching is processing you need consent for and cannot easily explain in a subject access response, and its accuracy is worse than the deck suggests. Where identify belongs: Most broken graphs I see call identify on page load with a stale trait bag, which welds an anonymous session to whoever logged in last on that browser. It belongs on authenticated actions and on form submissions carrying a real email address. Fixing the call sites is frequently more of this engagement than the modelling, and it needs your engineers rather than mine. The shared-device problem, answered per business: For a beauty or furniture brand the honest unit is often a household rather than a person, and pretending otherwise produces recommendations that embarrass you in front of customers. For B2B the graph runs person to account to domain, with free-mail domains excluded from domain association. I write down which unit you are resolving to and what you give up by choosing it, because that decision governs everything built on top of it. What gets built: An identity graph in your warehouse as incremental dbt models. Alias edges carrying source, evidence type and timestamp, resolved to a stable surrogate id that does not change when new evidence arrives. Late-arriving evidence handled explicitly rather than by rebuild. An unmerge path from day one, tested on real records, because you will need it. A match-rate dashboard split by channel and source, so a drop tells you where to look rather than only that something is wrong. Not included: Retroactive mass merges without a reversal path. Matching on name and city. Buying a third-party graph. Treating a hashed email as anonymous data, because it is a pseudonym, it remains personal data, and I will not sign a document saying otherwise. Consent collection itself. Media measurement and attribution modelling. Who this is not for: Teams whose goal is cross-device advertising reach. That work depends on probabilistic matching and on vendors who will happily supply it. I am not the person to hire for it and will say so on the first call rather than build a compromised version and describe it in careful language. The governance you are left with: A written merge policy stating which evidence justifies which association, who may approve an exception, and how a disputed merge is reviewed. An erasure procedure that works against the graph rather than around it. And a quarterly precision check against a fresh labelled sample, because a graph that was accurate at launch is not evidence that it is accurate now.