Identity Resolution in CDPs: How Customer Profiles Get Stitched Together

The Identity Problem in Digital Analytics

A single customer might interact with your business as:

• An anonymous visitor on desktop (assigned a random cookie ID)
• A mobile app user with a device ID
• A registered user with a user_id
• An email recipient identified by email address
• A CRM contact with a Salesforce ID

Without identity resolution, these appear as five different people in your data. Identity resolution is the process of recognizing that they're the same person and merging their histories into one unified profile.

This is one of the most technically complex aspects of CDP implementation, and it's where our CDP implementation team spends significant time ensuring correctness.

Deterministic vs. Probabilistic Identity Resolution

Deterministic Resolution

Uses definitive identifiers to match profiles. Two profiles with the same email address, user_id, or phone number are definitively the same person. This is the most accurate form of identity resolution.

How it works in practice:

1. Anonymous user browses your site — CDP assigns an anonymous ID (anonymousId)
2. User fills in an email form — CDP fires an identify() call with their email
3. CDP merges the anonymousId history into the user's profile
4. User logs in on mobile — CDP fires identify() with the same email
5. CDP recognizes the email, merges the mobile device history into the same profile

The identify() call is the trigger for deterministic resolution. Every time you call it with a known identifier, the CDP can stitch the current session to any previous profile with the same identifier.

Probabilistic Resolution

Uses statistical signals to infer whether two profiles are likely the same person when no deterministic identifier is available. Signals include IP address, device type, browser fingerprint, behavioral patterns, and location.

Probabilistic resolution is less accurate by definition (false positives possible), but can stitch profiles before a user identifies themselves. Enterprise CDPs like mParticle have sophisticated probabilistic engines; most standard CDPs focus primarily on deterministic resolution.

The Identity Graph

CDPs maintain an identity graph — a database of how different identifiers relate to each other. When a new identifier is linked to an existing profile, the graph updates and the profile is merged.

The graph typically includes:

• Anonymous IDs (CDP-assigned, session-based)
• User IDs (your own system's identifier)
• Email addresses
• Phone numbers
• Device IDs (mobile)
• Third-party IDs (Salesforce ID, Stripe customer ID)

When Identity Resolution Fails

Common failure scenarios:

• Missing identify calls: If users are never identified (no login, no form fill with identify call), the CDP can't stitch profiles
• Inconsistent user IDs: If your system assigns different user IDs to the same person (e.g., different IDs in web app vs. mobile app), profiles won't merge
• Shared devices: Family members sharing a tablet will appear as one profile — important for retail or consumer apps
• Email case sensitivity: "User@Example.com" and "user@example.com" are technically different strings. Most CDPs normalize to lowercase, but verify this in your implementation

Privacy and Consent in Identity Resolution

Identity resolution stores persistent links between user identifiers — this is personal data under GDPR and CCPA. Users who withdraw consent for tracking need their data deleted from the identity graph. Your CDP must support profile deletion APIs (often called "right to be forgotten" endpoints).

Additionally, consent must be collected before identity resolution begins. Our consent mode implementation service ensures that identify calls only fire after appropriate consent is obtained, keeping your CDP compliant. Contact us to review your identity resolution architecture.