Identity resolution in a customer data platform (CDP) is the process of finding and matching the fragmented signals a business collects about a person across devices, channels, and systems, determining which ones belong to the same individual. It’s the foundation the CDP builds an accurate, current profile or Customer 360 from. Get that foundation wrong, and the profile it produces is wrong too.
Not every CDP does this equally well. Identity resolution is one of the most consequential and most overlooked variables in how a CDP performs, and a weak implementation undermines everything downstream of it, from segmentation and personalization to attribution and AI. That’s true whether you’re evaluating a new CDP or living with one you already bought.
What Identity Resolution Actually Does Inside a CDP
Identity resolution isn’t deduplication with a better name, and it isn’t the same job as a master data management (MDM) system. Deduplication looks for exact or near-exact record matches and collapses them. Identity resolution goes further. It determines which partial, conflicting, and time-delayed signals (an email from a mobile app, a loyalty ID from a point-of-sale system, a cookie from a web session) belong to the same person, and keeps that determination accurate as new signals arrive. Profile unification, the step that actually assembles those linked signals into a usable customer record, depends on identity resolution getting that matching right first. MDM, meanwhile, typically governs reference data across enterprise systems; it’s built for consistency of core records, not for resolving high-volume, high-ambiguity customer signals in something close to real time.
Staying accurate over time depends on persistent identity keys. As a person moves from anonymous browsing to a known, authenticated customer, a persistent key preserves that thread instead of starting the relationship over. Without it, every channel switch resets what the business knows about that person. Continuity is the entire point of resolving identity in the first place, and without a persistent key, it breaks.
That same matching capability also has to work across relationships, not just within one person’s timeline. Household resolution groups people who share an address into one household view. Account resolution rolls an individual’s activity up to the business account they belong to, which matters in B2B contexts. A CDP that resolves individuals well but can’t group them this way will leave gaps that show up downstream, usually as a customer who gets marketed to like a stranger despite months of prior activity from someone in their own household.
Why Deterministic and Probabilistic Matching Both Matter
Good identity resolution uses two matching approaches together, not one or the other. Deterministic matching links records on exact identifiers (the same email address, the same loyalty number) and it’s reliable when those identifiers are clean and consistent. Probabilistic matching weighs multiple imperfect signals and assigns a confidence score, which is what you need when identifiers conflict or don’t exist yet, like a shared IP address, a similar name with a typo, or a device fingerprint. Real customer data produces both kinds of signals constantly, so a platform that only supports deterministic matching will systematically miss the messier case.
How much matching confidence you need depends on the industry. A financial services or healthcare organization has a much lower tolerance for a false match than a retail or travel brand does, because the cost of merging the wrong two people’s records is a compliance problem, not just a bad email. That’s why tunable matching logic matters as much as the matching methods themselves. Identity resolution needs to let you set the confidence bar per use case rather than applying one threshold everywhere.
Not Every CDP Resolves Identity the Same Way
A CDP’s identity resolution capability isn’t a single checkbox you either have or don’t. It’s a spectrum, and where a given platform lands on it determines how much you can trust the profile it produces, and what every downstream use case inherits as a result. Weak identity resolution shows up as segments that underperform for no clear reason, personalization that feels generic despite a large data investment, and attribution numbers nobody fully trusts.
If you’re evaluating a new CDP, identity resolution needs to be part of that evaluation from the start. We wrote a full framework for it, including the specific capabilities to check for, in our CDP Selection Guide.
If you already have a CDP and its identity resolution isn’t holding up, replacing the whole platform usually isn’t necessary. A data readiness layer can sit alongside your existing CDP and take over data quality and identity resolution specifically, feeding a cleaner, better-resolved profile into the CDP you already run. That’s materially smaller lift than a platform migration. Either way, the goal is the same: a profile you can actually trust before anything else gets built from it.
