Concept
Identity resolution is the process that decides which signals belong to the same person. A cookie on a phone, a device ID in the app, an email address, a loyalty number and a CRM record all arrive separately, and something has to rule on which of them describe one customer and which describe different people who happen to share a device, a household inbox or a call-centre placeholder. That ruling contains three decisions that usually get collapsed into one word: which identifiers are allowed to link profiles together, which identifiers must never appear twice in the same profile, and which value survives when two sources disagree about a name, an address or a consent flag. Matching is only the first of the three, and it is the one vendors demo.
Why it matters
Every downstream decision inherits the answer. Segmentation, suppression, frequency caps, consent enforcement and measurement all assume that a profile describes one person, so an identity error never stays in the data layer; it surfaces as a discount sent to someone who just paid full price, or an opt-out that holds on one channel and fails on another. Errors run in both directions, with different symptoms. Link too cautiously and one customer splits into several fragments, which shows up as thin personalisation and inflated customer counts. Link too eagerly and several people collapse into one, which is worse, because a single profile now carries two people’s purchases, preferences and consent. The CDP node argues that identity is a single-owner problem, and this is the reason: the rules that prevent both failures have to be written once, by someone accountable for them, and then applied to every event for as long as the stack runs.
A simple example
A family shares a tablet. The mother signs in to a retailer’s app to buy a coat, and a week later her son signs in on the same tablet, with his own account, to buy trainers. The device ID now connects two CRM IDs. A matching rule that says “same device, same person” merges them, and from then on the mother receives trainer recommendations, the son’s marketing opt-out suppresses his mother’s order updates, and the lifetime value report counts one customer where there are two. The fix is a rule that a profile may hold only one CRM ID, so the tablet can link to either account without ever becoming the bridge that joins them. The packaged platforms have made this policy explicit in their configuration: Adobe Experience Platform lets you declare a namespace unique so that the graph splits instead of collapsing, Twilio Segment sets per-identifier limits and a priority order that decides which identifier gets demoted when a limit is exceeded, and Salesforce Data Cloud separates match rules from reconciliation rules, which choose the single value that survives in a unified field.
The architecture view
Three rules, one owner. The never-merge rule is what keeps two customers from becoming one broken profile.
Placement follows the layer or product logic. Identity can be resolved inside a packaged CDP, inside a suite’s shared profile, in the warehouse with a composable approach, or inside the engagement platform itself, and the CDP and CEP patterns show that each of these can be coherent. What decides the placement is coverage, because the system that resolves identity has to see every source whose identifiers you need to join. A CEP that observes only its own email, push and app traffic can resolve those identities well, and it will quietly miss the store receipt and the call-centre record it never ingests.
The mistake I often see
The recurring error is treating identity resolution as a matching project that finishes at go-live. The team configures match rules during implementation, tests them on a clean sample and moves on, while the policy questions stay open: which identifiers are trustworthy, which values are placeholders, who may split a wrongly merged profile, and who gets told when a merge rule changes. Then a new source arrives, perhaps a marketplace feed or a call-centre system that writes noemail@brand.com for every customer who declines to give an address, and the graph starts joining strangers. Nobody notices for months, because the symptom looks like a personalisation quality problem rather than an identity one. Almost as common is assuming that marketing-grade matching on email and device ID will also serve finance, service and compliance. As Part 1 of the patterns sets out, marketing-grade identity and enterprise master data answer different questions, and deciding which one a programme needs is a governance call to make before configuration begins.
Go deeper
For where the resolved profile lives and who reads from it, start with what a CDP is, and for how the policy’s owner changes between architectures, the CDP and CEP patterns walk through all three. The acronym piece on the CDP tells how identity became the category’s defining job before it began moving into warehouses and suites, while the one on the CRM takes the record-layer view of who is allowed to change the truth about a customer. The DMP covers the anonymous, third-party version of the same problem, and why it lost. Once the profile is resolved, what a customer attribute is takes up the next question, who owns what the profile says about the customer.
Sources
Platform documentation
- Adobe Experience League, Identity Graph Linking Rules overview. Unique namespaces, namespace priority and the identity optimization algorithm that prevents graph collapse.
- Twilio Segment, Identity Resolution Settings. Per-identifier limits, priority order and the shared-device case.
- Salesforce Help, Identity Resolution Reconciliation Rules. How a single surviving value is chosen after match rules link profiles.