Cross-Channel Contact Deduplication

Cross-channel contact deduplication is the process of collapsing the multiple records that separate channels created for the same person into one contact, while keeping different people apart.

It is a specific case of identity resolution, and the harder one. Deduplicating within one source is mostly about typos and formatting: two rows, one address book, one set of identifiers. Deduplicating across sources means reconciling records that were minted by systems with no shared key, no agreed schema, and different opinions about what a person even is.

The deceptive part is that it looks like a string-matching task. It is not. It is a sequence of judgment calls, each with an error rate, and one of the possible errors is unrecoverable in practice.

Duplicates in a cross-channel contact set are not data-entry mistakes. They are the correct output of channels that never coordinated. Four recurring sources:

• Fragmented identifiers. Each channel minted its own identifier for the person. Nothing joins them, so each channel contributes at least one record.
• Change over time. Someone changes a handle, migrates to a new number, or switches the address they reply from. Anything that treated the old value as definitive now has two people where there is one.
• Multiplicity per person. One human has a personal number and a work number, a personal mailbox and a work mailbox, sometimes two accounts on one platform for two contexts. All of them are legitimately them.
• Sparse and lopsided records. One record has a name and no contact details; another has a number and no name; a third has only an opaque account identifier.

That last point is the one people underestimate. A large share of true duplicate pairs have nothing in common to compare at all until something else links them.

This is the failure mode that turns a dedup routine into an incident.

Merging chains. If A merges with B, and B merges with C, then A, B and C are one record — even though A and C were never compared and share nothing. That is normally the point: it is how a series of small pieces of evidence assembles a complete identity from records that individually look unrelated.

It is also how one bad join destroys a data set. Suppose a company's front-desk number appears on the records of forty different employees. A rule that merges on matching phone number does not produce forty pairs of duplicates. It produces one record containing forty people, because each merge chains into the last. The same shape occurs with a shared household line, a role address like info@, or a placeholder value that half the records happen to carry.

The damage is not proportional to the mistake. A single over-permissive rule applied at scale collapses a large fraction of a contact set into a handful of monster records, and every one of them silently mixes people's histories together.

The general lesson is unglamorous: most of these values identify a context — a company, a household, a function — rather than a person, and a system that cannot tell the difference will find them all and treat them as proof.

Group conversations break the assumption that a message belongs to exactly one relationship.

A message sent in a group belongs to the person who sent it and to the group relationship it was sent in, and both matter. Attribute it only to the person and you lose the context that gave it meaning — who else heard it, what it answered. Attribute it only to the group and the person's own record goes empty even though you have talked to them for a year.

So the record has to hold both edges. A contact's history should include what they said in a group conversation, and the group itself should remain a thing you can open and read in order. Systems that pick one of the two are easier to build and are wrong in a way users notice immediately.

Because the catastrophic error is a false merge, the design constraint that matters most is that every merge must be undoable.

That means the contributing records survive underneath the unified contact instead of being flattened into it, and that undoing one join does not disturb the others. A dedup routine implemented as a destructive rewrite — copy the fields to the survivor, delete the rest — passes its tests and then cannot be repaired, because the information needed to separate the record again was deleted along with it.

The corollary is the interaction model. Where the evidence is unambiguous, resolving automatically is correct and the user should never be asked. Where it is ambiguous, the honest move is to propose the merge and let a person confirm it. That confirmation is a feature, not an unfinished automation: it is the system declining to make an irreversible, invisible decision on evidence that does not support one. Pantheon works this way — it resolves the clear cases on its own and asks about the rest.