Imagine a Gulf retailer bringing store purchases, website orders and WhatsApp enquiries into one marketing platform. A customer uses a personal email online and a work number in the store. Two relatives share a delivery number. A corporate buyer orders for several branches. The dashboard celebrates fewer duplicate profiles. Customer identity resolution has improved only if the business can explain which records belong together and which must stay apart.
I would not approve the project against a target such as “merge more customers.” An incorrect merge can send a message based on somebody else’s purchase, expose the wrong service history or move a valuable customer into the wrong segment. A missed match creates fragmentation. A false match can create a false relationship that every connected system then treats as fact.
Customer identity resolution needs a decision boundary
Define the job before choosing a matching engine. Recognising a returning shopper for an aggregate report, displaying order history to a signed-in customer and deciding who receives a WhatsApp offer have different consequences. They should not inherit one universal confidence threshold simply because the platform produces one customer ID.
Keep people, households, devices and business accounts distinct. A shared phone may connect a household without proving that every order belongs to the same person. A purchasing manager may represent several legal entities. Model those relationships explicitly. Flattening them into one profile makes the database smaller while making the commercial meaning less reliable.
This is a narrower question within a first-party data strategy: what evidence allows two source records to influence the same decision? The useful deliverable is a matching policy with tests, owners and a correction path. A customer data platform can execute parts of that policy. It cannot choose the consequences the business is prepared to accept.
Use five gates before joining histories
1. Define the authority of each identifier
List the identifiers arriving from each source and how they were obtained. Separate an authenticated account ID from a phone typed at checkout, an email supplied to receive a receipt and a browser identifier. Record whether a field was verified, when it was last confirmed and whether it may legitimately be shared. An exact match between weak fields remains weak evidence.
Preserve source namespaces. Customer 123 in the UAE POS is not automatically customer 123 in the Saudi commerce system. Normalise phone formatting and compare Arabic and English name variants where useful, but preserve the original values. Formatting helps comparison; transliteration or spelling similarity alone should not authorise a person-level merge.
2. Make every match explainable
Begin with rules whose meaning the business can review. A trusted source’s stable account identifier may support a strong link within its own boundary. A name and shared address might support only a candidate for review. Contradictory verified identifiers should stop automatic joining until someone resolves the disagreement. Keep an explicit “unresolved” outcome.
AWS Entity Resolution’s rule-based workflow documentation describes configurable matching rules and output that includes both a match ID and the rule responsible. That is a useful purchasing criterion: ask the supplier to explain an individual match, including source records and rule version. A cluster number without its reasoning is poor evidence for a disputed customer relationship.
Also test chains. If record A shares an email with B, and B shares a phone with C, should A and C become one person? Perhaps B contains an entry error or a household contact. Review the entire group produced by the rule, not only each apparently reasonable pair. One weak bridge can connect several unrelated histories.
3. Control what a match is allowed to trigger
Use the least consequential application first. A candidate relationship might be visible to an authorised analyst while remaining unavailable to customer-facing personalisation. Do not let uncertain matching unlock an account, change authentication details or expose order history. Those actions need their own verified authority.
Twilio Segment documents customisable identifier rules, source-based associations and merge protection. These controls make configuration part of the business decision. Ask which identifiers can create links, which limits prevent shared devices from joining people and what happens when incoming evidence conflicts. Default settings deserve the same scrutiny as custom rules.
Keep communication permission attached to its recorded purpose and channel. Joining two profiles does not answer whether a particular message is permitted. Carry opt-outs and disputed permissions into the decision, and suspend affected activation until the owner resolves uncertainty. Have the privacy owner determine applicable requirements; an identity match is not a legal conclusion or fresh consent.
4. Test wrong joins as well as missed joins
Create a labelled evaluation set with approved handling of any real data. Include known same-person pairs, known different-person pairs and deliberately unresolved cases. Cover shared family phones, reused corporate inboxes, guest checkouts, corrected numbers, Arabic and English spellings, and staff test accounts. Synthetic examples help exercise edge cases without copying private histories into a demonstration.
Report false merges separately from missed matches, with denominators and sample sizes. Match precision asks how many proposed joins were correct; coverage asks how much of the eligible population was resolved. A system can improve coverage by relaxing its rules and become worse for the customer. Inspect large merged groups as well, because pair-level results can hide a damaging chain.
Run the first evaluation without publishing audiences or changing master records. Compare proposed decisions with the current workflow. Set acceptance thresholds according to the consequence of the intended use, and require the commercial owner to sign them. There is no universal percentage that makes every kind of personalisation safe.
5. Prove that a bad merge can be undone
Retain source records, link history, rule versions and the identities that existed before a merge. Ask the supplier to demonstrate a correction rather than merely describe it. Can the team split the profile, restore the right purchase histories and prevent the same incoming data from immediately merging it again?
Follow the correction into CRM, campaign audiences, service tools and exported reports. Some actions cannot be recalled: a message already sent stays sent. Pause affected automation while repairing the relationship, and give service staff a way to raise a suspected identity error. The CRM and WhatsApp integration journey only becomes useful when its customer context is trustworthy.
Approve one use case before a universal profile
Start with one market, two understood sources and one bounded decision. Review disputed merges, correction time and the business outcome alongside coverage. Expand only when the team can operate those exceptions. Within marketing automation, recognising a customer is valuable because it improves the next action, not because it produces a larger audience.
Customer identity resolution is a continuing judgment about relationships. Before connecting the next source, pick one merged profile and ask the team to explain every link, the actions it enables and how it would be separated. If they cannot, the single customer view is still an assumption wearing a dashboard.