Hi everyone, I see this term "identity resolution" thrown around a lot in CDP marketing, and I think it's often presented as this magical black box. Having wired a few of these systems into client stacks, I wanted to break down the actual mechanics in a more grounded way. Think of it less like magic and more like a very meticulous librarian trying to organize a mountain of messy, incomplete index cards.
At its core, identity resolution is the process of taking all the scattered signals you have about a person—a cookie ID from their browser, an email from a newsletter signup, a mobile ad ID from an app, a physical address from an order—and deciding, with some level of confidence, which ones belong to the same individual. The "under the hood" part is really about the **rules** and the **graph**.
First, the system ingests raw signals, which we call **identifiers**. These fall into a few buckets:
* **Deterministic identifiers:** Strong, direct evidence. A user logs into your website with the same email on their laptop and phone. That's a high-confidence link.
* **Probabilistic identifiers:** Weaker, indirect signals. Same IP address, similar device fingerprint (browser type, screen resolution, fonts), or similar behavioral patterns. These are clues, not proof.
The CDP's job is to take these clues and stitch them together. Here’s a simplified version of the logic flow:
1. **Collection & Hashing:** Every raw identifier (like `jane@example.com`) is often hashed (turned into a scrambled string like `a1b2c3d4`) for privacy. These hashed IDs flow into the CDP's processing engine.
2. **Rule-Based Linking:** This is where you set the business logic. The platform uses rules you configure, like:
* "If two records share the same hashed email, merge them into one profile."
* "If a device ID is seen logging into Account A, and later the same device ID is used with a new email for Account B, flag this as a *possible* merge for review."
* "Prioritize the email from the purchase confirmation over the email from a blog comment."
3. **Building the Identity Graph:** All these linked identifiers form a graph—a web of connections. The central node is the **resolved profile** (often called a "customer profile" or "golden record"). Attached to it are all the now-linked identifiers and the collected data from each of those touchpoints.
The real "secret sauce" among CDP vendors is in how they handle ambiguity and scale:
* How do they score the confidence of a probabilistic link?
* How do they resolve conflicts when data from two linked sources disagrees (e.g., different first names)?
* Do they use third-party data or only your first-party data to bolster links?
* How quickly does the graph update in near-real-time?
In practice, when you see a unified customer profile in your CDP dashboard, you're looking at the output of this constant, behind-the-scenes matching process. It's not perfect, but a well-tuned resolution engine is incredibly powerful for turning fragmented data into something you can actually act on in your CRM or ad platform.
I'm curious—for those who have worked with specific platforms like Segment, mParticle, or Lytics—what's one quirk or "gotcha" you've encountered in their resolution logic? I've found the devil is always in the configuration details.
~Jane
Stay connected