Deterministic identity resolution and merge rule design

A merge rule keyed on email alone collapses a household into a single profile, and in the three publisher graphs I have audited that hit between 6 and 11 percent of active profiles: shared tablets, one family address on the subscription, a partner reading on the same device. Those profiles then received the wrong paywall offer for months. Identity work is mostly the discipline of deciding when not to merge. The rule I will not break: Deterministic matching only. Authenticated identifiers, hashed email, phone in E.164 form, customer or policy number, order ID. No device graphs, no IP-plus-user-agent fingerprints, no third-party probabilistic vendor, and no exception bought with a business case. In banking, insurance and anything touching children, a wrong merge is not a rounding error in a report, it is one person seeing another person's balance, offer or reading history. Deterministic rules produce a smaller graph. Smaller is the point. What actually gets decided: Identifier precedence, meaning which ID wins when two conflict and what timestamp rule settles a tie. Merge direction, and what happens to the losing profile's traits. Which identifiers may trigger a merge at all rather than simply being stored against a profile. Anonymous-to-known stitching windows, and whether historical anonymous behaviour attaches retroactively or only from the login forward. Most platforms, Segment included, cannot cleanly unmerge, and that single constraint shapes every rule I write, so the set errs toward leaving two profiles apart. Household against individual: In a family media product the household is the billing unit and the individual is the consumption unit, and any report that mixes them produces nonsense. Both get modelled, with an explicit link table, and no child profile is ever promoted into a syncable identity. The insurance equivalent is policyholder, insured party and household: three relationships that most schemas pretend are one. Erasure walks the graph: An Article 17 request has to propagate through every merged profile, every warehouse table and every downstream platform that received the row, and it has to be provable months afterwards. The deletion path and its evidence trail are built alongside the graph rather than after it. Treating this as a follow-up phase is why so many identity projects get unwound by a data protection officer two quarters in. Excluded: Consent management configuration. Ad platform audience work, which is separate. Data quality repair inside your CRM, because a graph built on duplicate contact records inherits the duplicates and cleaning those belongs to your team. Real-time identity APIs answering under 200 milliseconds for on-site personalisation, which is an engineering build rather than this. Who should not buy this: Anyone whose main goal is raising match rates on ad platforms. Deterministic resolution usually reduces the profile count and can reduce a match rate while making both numbers true, and if that trade is unacceptable we would argue for eight weeks and you would be right to be annoyed. Also a poor fit where there is no authenticated surface at all, no login, no subscription, no account, because then nothing deterministic exists to match on and I would be selling you a graph made of guesses. What you receive: The rule set as documentation and as code, the merge logic implemented in your CDP and mirrored in dbt so it can be tested against history, a sample of contested profiles worked through by hand with the reasoning attached, the erasure runbook, and a monitoring query that flags merge volume spikes, which is the early signal that a rule has started eating the graph.