Email Contact Merge Policies: Avoid Combining Different People

TL;DR

• Main decision: treat identical email strings as delivery destinations, not automatic identity evidence—decide what a contact means in your application before choosing a merge key and policy.
• Useful method: separate candidate detection from approved merges, classify evidence, and apply field-level provenance so merges preserve authoritative sources rather than replacing whole records blindly.
• Meaningful limit and success check: review downstream impacts, show a preview of resulting values, preserve consent and suppression history, and test varied cases before enabling automatic cleanup.

A shared address is not always a shared identity

Contact cleanup can look like a simple deduplication task until two records represent different people using the same team mailbox, or one person has changed addresses. Decide what a contact means in your application before choosing a merge key.

A person, an account membership and a delivery destination are related but distinct concepts. Combining records because their email strings match can erase that distinction. The right policy depends on the product's identity model and the purpose of the contact list.

Begin by documenting which relationships are authoritative and which are only clues that deserve review.

Separate duplicate candidates from approved merges

Use matching rules to identify candidates, then classify the evidence. An exact stable external ID from a trusted source may be stronger than a similar name. A shared phone number or domain can indicate a household or organization rather than one person.

For an illustrative business application, two records named Alex Chen may be different employees. Conversely, “Alex C.” and “Alex Chen” may refer to the same person. Neither conclusion should be reached solely by how convincing the text similarity looks.

Keep uncertain cases separate from automatic merges, with an owner and a specific missing piece of identity evidence. The cleanup process should make ambiguity visible instead of hiding it behind a confident duplicate count.

Define which record owns each field

Even when identity is confirmed, the records can disagree about name, locale, organization and preference state. Do not choose one entire record as the winner without considering the meaning and source of each field.

For example, a recently edited account preference may be more authoritative than an older CRM export, while a verified billing contact name may have a different purpose from a casual display name. Store the provenance needed to explain the choice.

A field-level policy is more work to define, but it prevents a merge from quietly replacing good information with whichever record happened to be created first.

Preserve consent and suppression history

Merging records must not convert an opt-out into an opt-in merely because another record appears subscribed. Identify the scope and timing of each preference event and apply the reviewed policy for the resulting identity.

The SendDart consent-record guide provides useful background for retaining how a choice was made. Keep the relevant history available rather than flattening it into a single unexplained Boolean.

Also separate preference decisions from delivery-related suppression. A bounce record and a recipient's topic choice describe different facts; resolving identity does not automatically resolve either one.

Related reading: How to Reduce Email Bounce Rate with Better Diagnostics.

Work through a shared-mailbox example

Imagine two employees are associated with support@example.com in a customer system. The application may need separate person records for permissions while using one mailbox as a communication destination for a team.

Merging the employees could corrupt ownership and activity history. Creating one delivery destination linked to the appropriate team may be a better model, but that is an application design decision requiring evidence about the intended relationship.

The example demonstrates why “one email, one person” is not a universally safe assumption. Review the downstream use of the record before deciding that fewer rows necessarily means cleaner data.

Review the consequences before applying a merge

List the related objects that will be affected: audience membership, message history, external IDs, preferences, account relationships and analytics attribution. A merge that looks harmless in the contact table may change how another workflow selects recipients.

Show a preview of the chosen field values and retained relationships. Highlight irreversible or difficult-to-reconstruct consequences so the operator understands the actual change being authorized.

If the system supports reversal, define its limits. A later split cannot necessarily undo messages already sent or external synchronization effects triggered by the merged identity.

Make concurrent updates part of the design

A contact can change while a merge is being reviewed. Use appropriate version checks or transactional controls so the approved preview is not applied blindly to a different current state.

PostgreSQL's transaction-isolation documentation illustrates why concurrent reads and writes need deliberate handling. The correct implementation depends on your database and workflow; a generic “upsert” is not a complete merge policy.

If the records changed materially, rerun the preview or require the conflict to be resolved. Preserve newer recipient decisions rather than silently replacing them with the review's older snapshot.

Keep a clear merge record

Record the original identifiers, evidence for identity, selected field sources and resulting record. Limit access to the audit details according to their sensitivity.

Test confirmed duplicates, similar names, shared mailboxes, changed addresses and conflicting preferences before enabling automatic cleanup. The successful policy reduces redundant records while preserving the people, relationships and choices those records represent. SendDart audience updates should receive the result of that considered identity decision, not become the place where uncertain identities are combined by accident.