Why SAP CDC email-based merge rules break silently

A merge rule keyed on email looks correct because it is correct — until the customer changes their email. SAP CDC (and most CIAM platforms built the same way) treats a merge as a point-in-time decision, not a standing relationship. When the identifier it was keyed on changes, the platform doesn't "un-merge" on purpose — it just re-evaluates identity from scratch on the next write, and email-only rules produce a different answer than they did before.

The sequence

1. A customer has two profiles: one from a marketing sign-up (email: a@brand.com), one from a purchase as a guest (email: a@brand.com, same address). An email-match merge rule collapses them into one UID with a combined order history.
2. Six weeks later, the customer updates their email in one brand's account centre to email: a.new@brand.com. Nothing about the merge itself is touched — this is a profile-field update, not a merge event, so it doesn't get evaluated against merge logic at all.
3. The customer makes another guest purchase, this time entering a.new@brand.com. The merge engine runs its normal identity resolution on the new transaction and finds no existing profile with that email — because the one that matters was updated, not created. A third, disconnected profile is opened.

Nothing errored. Nothing logged a conflict. The pipeline that writes order data completed successfully at every step, because every step was successful by its own definition. The golden record split back into pieces, and the mechanism that split it is indistinguishable, from a monitoring dashboard, from ordinary new-customer growth.

Merge-key strategies compared

Strategy	What it keys on	Survives an email change	Failure mode
Email-only	email	No	Re-splits silently on next transaction with new email
Multi-key OR	email OR phone OR loyalty_id	Partially	False-positive merges when a phone or loyalty ID is reused by a different person
Ranked deterministic	Ordered list of stable IDs (loyalty_id > verified phone > email), with email demoted to a hint, not a merge key	Yes	Requires a stable ID to exist before the first merge — new customers with only an email still need a fallback path
Probabilistic / fuzzy	Weighted signals (device, behavioural, partial PII match)	Yes, but non-deterministic	Hard to audit; a support agent can't explain why two profiles merged

The fix isn't a smarter email-matching algorithm. It's not treating email as a merge key at all once a more stable identifier exists on the profile — email becomes metadata, not the thing identity is anchored to.

This is a mechanism problem at the Unify stage of the identity lifecycle: the merge rule needs to survive the source identifier changing, not just match it correctly the first time.