Data Cloud Unification: Identity Resolution at Scale

The Identity Resolution Problem

A modern consumer interacts with a brand across a dozen channels — website visits as an anonymous cookie, email opens as a hashed email, in-store purchases as a loyalty card, customer service calls as a phone number, and CRM records as a name and company. Each of these interactions generates a separate identifier in a separate system. Identity resolution is the process of determining that all these identifiers belong to the same real person and linking them into a single unified profile.

The challenge is that no single identifier is universal. Email addresses change. People use multiple email addresses. Phone numbers are shared within households. Cookies are cleared and regenerated. Names have variations (legal name vs. preferred name, maiden name vs. married name). A resolution algorithm that is too strict (requires exact matches on multiple identifiers) will produce many separate profiles for the same person. One that is too lenient (matches on weak identifiers like common names) will merge profiles that belong to different people. Calibrating this balance is the core challenge of identity resolution configuration.

Data Cloud approaches this through configurable rulesets — ordered sequences of matching rules that each specify which identifiers to match on, whether matching must be exact or approximate, and the confidence threshold at which a match is accepted. The output is an identity graph — a network of nodes (individual source records) connected by edges (match relationships) that Data Cloud traverses to determine which records should be unified into the same Unified Individual profile.

The Data Model Foundation: Individuals, Contact Points, Party Identifiers

Identity resolution in Data Cloud operates on three foundational DMO types. The Individual DMO represents a single entity in a single source system — one Contact record from Salesforce CRM, one registered user from the e-commerce platform, one loyalty member from the POS system. Each source system contributes Individual records.

The Contact Point DMOs (Contact Point Email, Contact Point Phone, Contact Point Address) represent the specific identifier values associated with an Individual — the email address associated with a CRM Contact, the phone number from a loyalty member record. Contact Points are how the identity resolution engine finds connections between Individual records that share a common identifier across different sources.

The Party Identifier DMO represents system-specific identifiers — a Salesforce Record ID, a loyalty member ID, a cookie value, a device ID. Party Identifiers link Individual records to their unique identifiers in each source system. When two Individuals from different source systems share a Party Identifier value (e.g., the same email address), the resolution engine uses this as evidence that they may represent the same person.

-- Conceptual view of identity resolution data model
-- Individual: one per source-system entity
Individual_Source: { Id, SourceSystem, SourceRecordId, Name, ... }

-- Contact Point Email: email addresses per Individual
ContactPointEmail: { IndividualId, EmailAddress, isPrimary }

-- Party Identifier: cross-system linking identifiers
PartyIdentifier: {
  IndividualId,
  IdentifierType: 'email' | 'phone' | 'loyalty_id' | 'cookie',
  IdentifierValue: 'john.smith@example.com'
}

-- Resolution creates a Unified Individual linking matched records:
UnifiedIndividual: {
  UnifiedId,
  SourceIndividuals: [crm-contact-001, ecomm-user-445, loyalty-mb-78],
  PrimaryEmail: 'john.smith@example.com',
  IdentityGraph: { edges: [...match relationships...] }
}

Deterministic vs Probabilistic Matching

Deterministic matching uses exact matches on high-confidence identifiers. Two Individual records match deterministically if they share the same email address, the same phone number, or the same loyalty member ID. Deterministic matches produce high-precision results — when two records share an exact email address, there is high confidence they represent the same person. False matches from deterministic rules are rare but do occur (shared email addresses within families, corporate email addresses used by multiple employees over time).

Probabilistic matching uses weighted scoring across multiple weaker signals. Two records score highly if they share a similar name (phonetic match), a similar address (normalised and compared), and a similar phone number (last 7 digits match). No single signal is definitive, but the combination exceeds a configurable confidence threshold. Probabilistic matching captures matches that deterministic rules miss but produces more false positives, particularly at large scale where coincidental attribute similarity increases.

Best practice for ruleset design is deterministic-first, probabilistic-as-supplement. Deterministic rules run first and capture high-confidence matches quickly. Probabilistic rules run on records that deterministic rules did not match, capturing the remaining lower-confidence connections. This ordered approach maximises precision for the easy matches and applies probabilistic scoring only where it is genuinely needed — avoiding the false positive amplification that comes from applying probabilistic matching to records that could be matched deterministically.

The Identity Graph and Profile Merging

When identity resolution runs, it produces an identity graph — a directed graph where nodes are Individual records and edges represent match relationships. A cluster of connected nodes (nodes connected directly or transitively via match edges) constitutes a single Unified Individual. The resolution engine traverses these clusters and creates a Unified Individual record for each, inheriting attributes from all the source Individual records in the cluster according to survivorship rules.

Survivorship rules determine which attribute value "wins" when multiple source records have different values for the same attribute — name, address, email. Data Cloud supports several survivorship strategies: "most recent" (use the value from the most recently modified source record), "most complete" (use the first non-null value found, ordered by source priority), and "source priority" (always use the value from the highest-priority source system, regardless of recency). Define survivorship rules explicitly for every key attribute — allowing them to default can produce unexpected profile values.

Profile merging is not instantaneous — identity resolution runs as a batch job on a configurable schedule (hourly, every 4 hours, daily, depending on data volume and org configuration). When a new Individual record is ingested, it does not immediately appear in the Unified Individual profile. It participates in resolution at the next scheduled run. This latency window is architectural — design downstream processes that depend on unified profiles to tolerate it.

Over-Merge and Under-Merge Failure Modes

Over-merge occurs when the resolution algorithm incorrectly links records that belong to different people into a single Unified Individual profile. Common causes: matching on email domains rather than full email addresses (merging everyone at the same company), probabilistic matching with a too-low confidence threshold, or matching on non-unique phone numbers (shared household numbers or call center phone numbers used as customer service contacts). Over-merged profiles contaminate personalisation — sending a "welcome back" email based on a profile that combined two different customers' purchase histories creates incorrect recommendations.

Under-merge occurs when the resolution algorithm fails to link records that do belong to the same person, leaving multiple separate Unified Individual profiles for the same real customer. Common causes: email address format variations (john@company.com vs. j.smith@company.com for the same person), phone number format differences (+1-555-0101 vs. 5550101), or missing Party Identifier mapping for a source system. Under-merged profiles cause duplicate communications — the same customer receiving the same promotional email twice from two separate profile activations.

Measuring resolution quality requires a ground truth dataset — a sample of known-same-person records that you can test the resolution rules against. Resolution quality metrics are precision (what percentage of matches are correct) and recall (what percentage of true same-person pairs were matched). Improving precision reduces over-merges; improving recall reduces under-merges. These metrics trade off against each other — a stricter ruleset improves precision at the cost of recall. Set target thresholds based on the business impact of each error type in your specific use case.