Customer identity across channels: merge carefully

When is there enough evidence to merge two customer records across retail channels—and when must those records remain separate? There is enough evidence to merge automatically only when the same individual authenticates both channel identities or explicitly confirms a link via a verified multi-factor flow. A shared mobile phone number at a POS counter, a shared delivery address, or a fuzzy name match is never sufficient evidence to auto-merge profiles.

In Indian omnichannel and multistore retail, family members routinely give a single household mobile number at store checkout to collect loyalty points or digital receipts, while maintaining separate online accounts, payment instruments, and in-store credit balances. If the CRM or customer data platform (CDP) runs an overnight job that merges every profile sharing a 10-digit phone number, one family member logging into the mobile app suddenly sees another family member's private purchases, prescription/beauty orders, saved addresses, and store credit wallet. The CRM data owner and Privacy lead need a conservative identity-resolution table that separates deterministic account linking from fuzzy review candidates and guarantees clean reversal.

Separating household contact sharing from individual customer identity

Why do retail CRM migrations so often create privacy incidents? Because implementation teams treat a mobile phone number as a globally unique primary key for a human being. In reality, a phone number at a retail store counter is often a shared household lookup token. Under data protection frameworks—including India's Digital Personal Data Protection (DPDP) Rules 2025 resources and official PIB notifications on DPDP implementation—a data fiduciary must maintain reasonable security safeguards to prevent personal data breaches, including unauthorised disclosure of one individual's personal data and transaction history to another individual.

To prevent cross-customer disclosure while still supporting omnichannel service, the CRM data owner and Privacy lead must enforce three architectural rules:

• Never use Phone_Number alone as an auto-merge key: When a POS cashier types a phone number that matches an existing online profile with a different name or unverified identity, the POS must allow creating a distinct store profile (or attaching the phone number as a non-unique contact attribute) without merging the underlying Customer_ID or exposing the online customer's past orders on the POS screen.
• Keep financial instruments and store credits bound to Original_Customer_ID: As shown in Shopify POS store credit and return controls, store credit is a financial liability owed to a specific customer. Commingling two people's store credits through an unverified phone merge creates immediate disputes when one person spends the other's refund balance.
• Maintain an immutable Merge_Lineage_Ledger for reversibility: Whenever an authorised merge does occur (Profile_101 + Profile_102 -> Master_101), every child record (Order_ID, Store_Credit_Ledger_ID, Address_ID, Consent_Log_ID) must retain its Source_Customer_ID column. If a merge ever needs to be undone—or when executing verified customer service order-status workflows—the system can cleanly unmerge Profile_102 in seconds without manual database surgery.

Worked example: two family members sharing a contact number with separate orders and store credits

Illustrative example (hypothetical scenario): The following customer profiles, order counts, and store credit balances are an illustrative teaching scenario created to demonstrate customer identity matching controls, not a customer result.

Suppose a specialty lifestyle retailer audits 500 candidate duplicate pairs flagged by an legacy CRM rule because both records in each pair share the same 10-digit mobile number (+91-98201-XXXXX). Before allowing any bulk merge, the CRM data owner inspects a representative pair (Pair #42) involving two family members in Pune who share a primary household contact number (+91-98201-44910):

• Profile 1 (CUST-POS-4012, created at Pune Store POS): Name: Anil Deshmukh; Email: anil.d@example.com; Historical Orders: 4 in-store purchases (₹14,200); Active Store Credit Balance from a prior in-store return: ₹1,200.
• Profile 2 (CUST-WEB-8839, created on D2C App): Name: Priya Deshmukh; Email: priya.deshmukh@example.com; Historical Orders: 6 online D2C orders (₹22,800) shipped to both a home address and an office address; Active Store Credit Balance from an online exchange: ₹850.

Look at what happens across the 500 candidate pairs when the retailer applies a strict 3-tier identity evaluation instead of a naive phone-number merge:

• Total Candidate Pairs Sharing a Mobile Number = 500 pairs (1,000 customer profiles)
• Tier 1 Deterministic Verified Same-Person Matches (Exact Name + Verified Email + Dual-Channel OTP Auth) = 310 pairs (62.0%)
• Tier 2 Distinct Individuals Sharing Household Phone (Different First Name / Distinct Verified Email, like CUST-POS-4012 & CUST-WEB-8839) = 135 pairs (27.0% — Blocked from Merge)
• Tier 3 Ambiguous / Incomplete Guest Profiles Held Separate Pending Customer Self-Verification = 55 pairs (11.0% — Held Separate)
• Protected Store Credit Balances Preserved from Cross-Person Commingling in Pair #42 = ₹1,200 (Anil) + ₹850 (Priya) = ₹2,050 total kept strictly separate

By blocking the merge on all 135 Tier 2 household-shared pairs and 55 Tier 3 ambiguous pairs (190 pairs / 38.0% of the candidate batch), the retailer prevents 190 potential cross-customer data disclosures and preserves separate financial store-credit ledgers for every distinct shopper.

Handling erroneous-merge incidents and governing the identity pilot

What must happen if a support agent or legacy integration script does mistakenly merge two different people (CUST-POS-4012 and CUST-WEB-8839), and Priya logs into the app and reports seeing Anil's orders and addresses? That event is not merely a "CRM data cleanup ticket"—it is an unauthorised cross-customer disclosure of personal data.

To govern identity matching and incident response safely, run a 4-week pilot with CRM, engineering, and privacy/security leads:

1. Disable automatic merges on single-attribute matches (Owner: CRM data owner): Prohibit any background job or POS lookup from merging two Customer_ID records based solely on Phone_Number, Last_Name + Pin_Code, or fuzzy string similarity. Fuzzy matching may populate an internal review table (Candidate_Matches), never an active merge.
2. Require immutable Source_Customer_ID lineage on every merge (Owner: Retail data / CRM engineer): Before any Tier 1 verified merge executes, write a snapshot to Merge_Lineage_Ledger recording Survivor_ID, Merged_ID, Verification_Method (OTP_Dual_Auth or Reviewer_ID), Timestamp, and the exact list of re-pointed order, address, consent, and store-credit IDs.
3. Execute immediate access isolation and incident review on erroneous merges (Owner: Privacy lead with Information security officer): If an incorrect merge exposes another person's order history or address, immediately trigger Access_Isolation_Unmerge: revoke active web/app session tokens on the affected profile, run the automated lineage unmerge script to restore CUST-POS-4012 and CUST-WEB-8839 to their pre-merge states, audit access logs to determine which records were viewed, and follow statutory incident evaluation procedures (including assessing applicability of CERT-In cybersecurity incident directions and DPDP breach notification rules with legal counsel).
4. Pilot exit and rollback criteria (Owner: CRM data owner with Privacy lead): Approve the identity matching workflow only when 100% of test merges can be reversed cleanly via Merge_Lineage_Ledger within 5 minutes and access control tests reject cross-customer order or credit visibility on shared phone numbers. Roll back any CRM deduplication job immediately if it merges profiles with distinct verified email addresses or different first names.

Choosing the right tool: Configure deterministic, authenticated account linking inside your native ecommerce and POS platform first. If you use an external CDP or CRM that computes probabilistic "golden customer profiles" for analytics, keep those probabilistic household clusters strictly in an analytics-only namespace and never write fuzzy merges back into the transactional order, support, or store-credit database.

Acceptance checks (ACT-R063-01 to ACT-R063-03)

Next steps for your team

1. Turn off phone-only auto-merging across POS and CRM: Allow multiple customer profiles to reference a shared household mobile number without collapsing them into a single Customer_ID.
2. Build a Merge_Lineage_Ledger before running any deduplication: Ensure every order, address, consent timestamp, and store-credit transaction retains its Original_Customer_ID so any merge can be reversed cleanly.
3. Separate analytical household clustering from transactional access: Never allow fuzzy or probabilistic CDP identity graphs to control which orders or store credits a logged-in user can view or spend.
4. Test the Access_Isolation_Unmerge playbook quarterly: Verify that your team can revoke session tokens, split an erroneously merged profile, and audit viewed records within minutes.