Implementation worksheet · 5 min read
An Identity Merge Decision Log for Lifecycle Teams
Keep one dated log with a row per merge rule: the identifiers it joins (e.g. verified email = verified email), the evidence standard (verified vs user-typed vs inferred), retroactivity (does the merge rewrite history or apply forward), the unwind procedure when a merge proves wrong, and who approved it. Default posture for lifecycle messaging: merge only on verified deterministic keys, apply forward, and treat every un-keyed coincidence (same name, same device) as a candidate for review — never an automatic join. The log matters because merge rules silently define who receives what: an over-eager rule sends one person another person's receipts, and nobody can debug it later without knowing what rule fired and why it existed.
Every CDP and engagement platform ships merge defaults, and teams inherit them unread. Then two customers share a family email, or an agency logs into twelve client accounts, and 'personalization' becomes a privacy incident. The log turns invisible vendor defaults into reviewed policy.
Put it into practice
1. Inventory the identifiers you actually hold
Login IDs, verified emails, user-typed emails, phone numbers, device IDs, anonymous cookies. Rank each by trust: verified-by-flow beats user-typed beats inferred. The rank column drives everything below.
2. Write one row per merge rule, with evidence standard
'Anonymous session joins profile on login' (deterministic, safe). 'User-typed checkout email joins existing profile' — riskier: typos join strangers. Each rule names its evidence bar and what it refuses to join.
3. Decide retroactivity per rule
Forward-only merges are debuggable; history-rewriting merges make yesterday's metrics unstable. Default forward; allow retroactive only where analytics correctness demands it and the unwind procedure can cope.
4. Write the unwind before the first bad merge
Which system is authoritative for splitting profiles, what happens to events attributed during the merged period, and who can execute it. An unwind designed during an incident is a data loss with paperwork.
5. Review the log when vendors change defaults
Platform migrations and CDP version upgrades change merge behavior silently — the Segment-to-anything migration is exactly when audiences drift. Re-run the log's rules against the new platform and record the deltas.
Merge rule log (one row per rule)
Copy this structure into your review document and record your observed result for each row.
| Rule | Evidence standard | Retroactive? | Unwind | Approved by |
|---|---|---|---|---|
| anon session → profile on login | deterministic (session token) | forward | drop session link | |
| verified email = verified email | both verified by flow | forward | split + reattribute from log | |
| user-typed email match | REVIEW QUEUE, not auto | — | n/a (never auto-merged) | |
| shared device match | never auto — flag only | — | n/a | |
| support email = profile email | verified via ticket auth | forward | split + notify owner |
A failure worth checking
The family-email merge: two people share home@family.com, a user-typed-email rule joins their profiles, and one partner's 'we miss you' win-back exposes the other's purchase history. The rule wasn't malicious — it was a default nobody read, and without a log nobody could say which rule fired, when it shipped, or what else it joined. The log converts that forensic nightmare into a lookup.
Common questions
Who should own the merge log?
Whoever owns lifecycle messaging outcomes — because merges land in their campaigns — with data engineering as co-signer on every rule. Vendor-default rules count as unapproved until someone signs the row.
How often do wrong merges actually happen?
Rarely as a percentage, constantly as an absolute at scale — and each one is maximally visible to the affected user. The asymmetry (invisible benefit, vivid failure) is why the evidence bar should be set by the failure case, not the average case.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.