The direct answer: do not begin by attempting a universal single customer view. Select one commercial decision—such as suppressing messages during a support case, measuring second purchase, or routing a lead to the right account—and define the minimum identity needed for it. Use deterministic rules for strong matches, AI to propose ambiguous pairs, and human review for high-impact merges. Consent, source lineage, and history must not disappear when records meet.
Five similar records may represent one person, household members, employees at the same company, separate franchises, or namesakes. Treating them as five customers creates duplicate contact and missing context. Merging them without control can mix preferences, service cases, opportunities, commercial limits, or opt-outs. Identity resolution is an operating policy supported by technology, not a cleanup button.
Write the Commercial Identity Contract
- Grain — person, household, B2B account, location, device, or a relationship between entities.
- Decision — the action that depends on identity and the harm caused by error.
- Sources — systems, owner, refresh, native key, and known quality.
- Match evidence — exact identifier, normalized attribute, address, domain, transaction, or observed relationship.
- Confidence — automatic, probable and reviewable, insufficient, or conflicting.
- Survivorship — which value wins by field, date, source, and use; one record does not win everything.
- Relationship versus merge — when to link records without destroying them and when to consolidate.
- Consent — purpose, channel, market, source, and validity remain traceable.
- Lineage and rollback — who decided, what changed, and how it can be undone.
- Downstream use — authorized systems, refresh window, and expected outcome.
The Contract prevents a common mistake: confusing a record with an identity. A corporate email may identify a contact for one B2B campaign, but it does not prove two subsidiaries are the same account. A shared phone may represent a household or call center. Define what same entity means for each decision before choosing an algorithm.
Use rules first and AI where ambiguity remains
- Deterministic match — customer ID, verified email, stable key combination, or confirmed relationship.
- Normalization — phone formats, accents, abbreviations, domains, and addresses while preserving raw values.
- Graduated rules — evidence combinations with explicit limits by entity type.
- AI or ML — proposes pairs with variations, errors, and missing fields and returns confidence plus available reasons.
- Human review — decides conflicts, strategic accounts, sensitive records, and cases near the threshold.
- No-match — a valid outcome. For many uses, two separate records cost less than a false merge.
AWS documents rule-based and ML matching workflows that assign Match IDs. Microsoft and HubSpot document duplicate detection and merging within their objects. These features accelerate processing; they do not define grain, survivorship, consent, or commercial consequence. Test difficult pairs from your CRM before buying another platform.
An eight-week pilot
- Week 1 — select one decision and domain, such as B2B contacts or ecommerce customers.
- Week 2 — sample known duplicates, true singletons, and historical false merges.
- Week 3 — define the Contract, keys, survivorship, review, and rollback.
- Week 4 — run deterministic rules in shadow mode and measure coverage and conflicts.
- Week 5 — test probabilistic matching only on unresolved records and calibrate thresholds.
- Week 6 — blind-review a sample and release one cohort with reversible writeback.
- Week 7 — feed one downstream use and compare data quality, operations, and customer response.
- Week 8 — decide batch versus real time, automation by confidence tier, and integrations to scale.
Start with hundreds or a few thousand reviewable pairs, not the entire database. Preserve a reviewed gold set and include adversarial cases: changed email, recycled phone, common surname, job change, shared account, and subsidiaries. A confidence threshold without a representative sample creates false precision.
Measure both error types and commercial value
- Quality — match precision, coverage, false merges, missed matches, and consistency by segment.
- Operations — reviewed pairs, review time, backlog, reversals, and refresh delay.
- Customer — duplicate contact, incorrect suppression, conflicting personalization, and complaints.
- Business — attributable conversion, second purchase, account expansion, avoided media cost, and contextual service.
- Risk — mixed consent, data sent to the wrong destination, and error concentration by group.
- Economics — integration, processing, review, backfill, and maintenance cost per useful identity.
Compare simple rules, rules plus review, and rules plus AI on the same sample. The objective is not maximum merge volume. For sensitive suppression, a false merge may block the wrong person; for aggregate analysis, a missed match may be more tolerable. Define the cost function by use case and preserve a comparison cohort or period when measuring conversion.
Ownership, architecture, and cost
The CRM or customer data product owns policy; marketing owns the use case; sales and service validate relationships; privacy and counsel assess purpose and retention; engineering maintains integration and rollback; data measures; source-system owners maintain input quality. Cost grows with sources, volume, languages, countries, refresh cadence, history, survivorship rules, human review, backfill, and destinations. Batch is often sufficient for measurement and planned campaigns; real time pays only when a decision loses value quickly.
Adapt identity to market and channel
U.S. B2B teams must separate contacts, accounts, parent accounts, and locations. Brazil and Latin America may add WhatsApp, marketplaces, distributors, and regional systems that create parallel identities. Do not use national identifiers, sensitive data, or external enrichment merely because they improve match rates. Preserve legal basis, purpose limitation, minimization, and local review. NIST recommends governing, mapping, measuring, and managing risk across the lifecycle; here that includes sources, thresholds, downstream actions, and reversals.
Bring the hard pairs, not a perfect demo
Start with the minimum data loop at https://makinai.co/insights/en/cdp-ai-marketing-minimum-customer-data-loop-revenue, choose batch or real time at https://makinai.co/insights/en/real-time-ai-crm-when-batch-is-enough, connect next-best action at https://makinai.co/insights/en/ai-next-best-action-crm-personalization, and protect journeys during service events at https://makinai.co/insights/en/service-aware-ai-crm-pause-marketing-support-issue. MAKINAI structures CRM, commerce, and integration at https://makinai.co/services/en/crm-ecommerce-commerce-transformation. Bring the field dictionary and a de-identified sample of difficult pairs; we can bound a pilot before consolidating the full database.
The sources document matching, duplicate detection, merging, and risk management. They do not demonstrate that one universal rule improves conversion or authorize data processing for every purpose. The Contract, pilot, thresholds, and measures are MAKINAI editorial recommendations to validate with local data, accountable owners, and legal guidance.