Identity resolution over-merges household members
A health-and-wellness retailer has 4.1M source records from CRM, web signup, and a POS loyalty system, and expects roughly 2.6M unique customers. After identity resolution, Data Cloud shows 2.05M unified profiles. Contact-center agents report that family members with different first names are being merged, and callers see order history they did not create. The ruleset uses three match rules: exact email, exact phone, and fuzzy first name plus last name plus postal code. Phone is often a household landline shared by three or more adults. The fuzzy name rule was added to catch nicknames. Reconciliation is set to most recent for all fields.
1. Which rule is most likely causing the over-merge, and why does most-recent reconciliation make the problem worse?
Read the worked answer
The exact-phone rule is the strongest over-merge candidate. A household landline is not a person identifier; it is a contact point shared by multiple adults. Matching on phone alone forces those adults into one unified profile. The fuzzy name plus postal code rule is a secondary contributor: common surnames and shared postal codes create high similarity between relatives, and fuzzy matching on names is weak when no other attribute corroborates it.
Most-recent reconciliation compounds the damage. If every field takes the most recently updated value, a name or birth date from one household member can overwrite another member's authoritative CRM value. The unified profile then looks clean but contains a blend of people. Reconciliation should be field-specific and source-aware, not a global most-recent rule. The over-merge is the primary defect; the reconciliation setting makes the resulting profile misleading rather than obviously wrong.
2. Redesign the match ruleset. State which attributes you would treat as exact, normalized, or fuzzy, and how you would combine them.
Read the worked answer
Start with normalized exact email as the primary high-confidence rule: trim, lowercase, and standardize before matching. Keep phone exact, but do not let phone alone create a match. Combine phone with a corroborating attribute, such as last name or date of birth, in an AND-style rule group. A shared landline linked to multiple individuals is valid data; it should be a contact point relationship, not a merge trigger.
Remove or sharply restrict the standalone fuzzy name plus postal rule. If fuzzy name is retained to catch nicknames, require an additional exact attribute and use it as a lower-confidence rule, not the main identity driver. Reconcile by field and source: CRM as the priority source for legal name and date of birth, most recent for email and phone where recency is meaningful. The goal is to let strong identifiers merge and weak ones merely associate.
3. What test and monitoring plan would you use before promoting the ruleset?
Read the worked answer
Clone the ruleset and test in a sandbox or lower environment against a representative data sample, not just the full volume. Compare the unified-profile count against the expected 2.6M and inspect a sample of matched pairs for false positives, especially household phone matches and fuzzy name matches. Replay known contact-center cases where family members were previously merged.
After promotion, monitor match rate, unified-profile count, and a periodic sample of new matches. Track complaint categories from the contact center and compare order-history accuracy. If Data Cloud exposes match review or profile inspection, use it to sample borderline matches. The ruleset should be treated as a governed asset: any change to phone handling or fuzzy thresholds should go through the same test-and-review cycle, because identity changes propagate into every segment and activation.