Identity resolution in marketing data is the problem of connecting three systems that were never designed to talk to each other: the ad platform's exposure log (who saw what ad, identified by a cookie, device ID, or login token), the CRM (who your customers are, identified by email or customer ID), and the conversion record (who bought, identified by whatever the checkout system captured).
The gap between these three systems is not a data problem — all three systems have data. It's an identity problem: the same human being is represented by a different identifier in each system, and there is no universal bridge between them. Identity resolution is the infrastructure that builds that bridge, and the quality of the bridge determines the reliability of every measurement program downstream.
Layer 1: Deterministic Identity
Deterministic identity uses a known, verified signal to create a stable link between an ad exposure and a customer record. Two standards dominate:
UID2 (The Trade Desk)
Both the publisher and the advertiser submit hashed email addresses to the UID2 Operator. The Operator produces an encrypted, rotating token — the UID2. Both parties receive the same UID2 for the same underlying email address, enabling matching without exchanging raw emails.
Key properties: deterministic (exact match, not probabilistic), encrypted (neither party sees the other's raw email), rotating weekly (privacy compliance — a UID2 from six months ago cannot be correlated with today's). Coverage: 40–65% of exposed audience, limited to logged-in users.
Best for: programmatic activation through The Trade Desk ecosystem, logged-in premium streaming environments, any use case where real-time or near-real-time matching is required. The weekly rotation makes it unsuitable for long-window batch measurement programs where you need a stable join key across a 90-day campaign.
RampID (LiveRamp)
The brand submits hashed emails or other PII to LiveRamp's batch resolution process. LiveRamp produces a stable pseudonymous RampID that maps to the same underlying identity consistently across partners and campaigns.
Key properties: stable (does not rotate), batch (not real-time), higher coverage than UID2 (60–80% of addressable audience because it includes offline-matched records and probabilistic extension). Best for: batch measurement programs, clean room iROAS calculations, any use case where you need a stable join key across a multi-week or multi-month measurement window.
The trade-off between UID2 and RampID is not a preference — it is a use-case decision. Use UID2 for real-time activation. Use RampID for batch measurement. For a complete identity program, you need both.
Layer 2: Probabilistic Identity
Deterministic identity stops at logged-in users. For linear TV viewers, CTV households with no login, and desktop users without persistent cookies, there is no direct email-to-exposure link. Probabilistic identity fills this gap using signals that correlate strongly with household membership without being individually verified.
IP-based household matching
An IP address at exposure time (the household that saw the ad) is matched to an IP address at conversion time (the household that visited the site or completed a purchase). Dynamic residential IPs change — but slowly enough that a same-day match has meaningful accuracy. A 30-day window match is much weaker.
Problems: dynamic IPs, VPNs, apartment buildings (hundreds of households sharing one IP), and carrier-grade NAT (many mobile users sharing one IP). IP matching is a probabilistic signal, not a deterministic one. It is useful as a fallback for CTV and linear measurement where no login exists, but it should never be treated as equivalent to deterministic matching in measurement programs.
Device graph (commercial providers)
Commercial providers — Experian, TransUnion, LiveRamp's device graph — build household-level device graphs by correlating multiple signals: IP address patterns, location data, app identifiers, and modeled household membership. A device graph can say "this iPhone and this laptop are probably in the same household" with some confidence level.
Snowflake Marketplace makes these graphs available natively — Experian ConsumerView, TransUnion TruAudience — without ETL. The match is probabilistic, with an associated confidence score. High-confidence matches (85%+) behave similarly to deterministic in measurement programs. Low-confidence matches should be excluded or analyzed separately.
Layer 3: Consent and Governance
Identity resolution at scale without consent governance is a liability, not an asset. The third layer of the identity stack is the infrastructure that ensures: (1) only consented identifiers are used for matching, (2) deletion requests propagate through the identity graph, and (3) the right segments activate on the right channels given the consent that was captured.
CCPA/GDPR deletion propagation
When a customer requests deletion, their record must be removed not just from the CRM but from every system that received an identity-linked record: the identity graph, the clean room program, the audience segments that were activated to DSPs. This propagation is the part most teams have not fully implemented. The risk: a deleted customer continues to be targeted because their RampID is still in an audience segment that was synced to The Trade Desk three months ago.
The architecture that handles this: a consent events table (customer_id, consent_type, timestamp, action: grant/revoke) that is checked before any identity-linked record enters the identity resolution pipeline and before any segment is synced to activation. Revoked consent blocks the record at both entry points.
Consent signal management
Not all consent is equal. A customer who opted in to "marketing communications" may not have consented to cross-device tracking or sharing with third-party measurement partners. The identity stack needs to track not just binary consent but the specific consent scope — what the customer agreed to and at what point in time.
This is stored as a consent attributes table: customer_id, consent_scope (email_marketing, cross_device_tracking, third_party_sharing, etc.), granted_at, source. Every downstream use of identity-linked data checks against this table before including the record.
Match Rate Quality: What 65% Actually Means
Two programs can both report 65% match rate with very different underlying quality:
- 65% deterministic — 65% of matched records are verified via hashed email → RampID or UID2. Strong match quality, stable join keys, suitable for incrementality measurement.
- 40% deterministic + 25% probabilistic — 40% verified, 25% household-matched via IP or device graph. The aggregate looks the same but the measurement quality is different. The 25% probabilistic match introduces household-level noise — the conversion may be from a different household member than the one exposed.
Always report match quality composition alongside match rate. In a clean room program, "58% match rate (52% deterministic, 6% probabilistic)" is a materially different number than "58% match rate (30% deterministic, 28% probabilistic)."
Where Identity Resolution Lives Architecturally
Identity resolution belongs in the warehouse, not in a SaaS tool. The common mistake is using a SaaS identity resolution product as a black box — you send data in, you get matched records back, you don't know the methodology or coverage breakdown.
The right architecture: Silver Step 2 (identity resolution) runs in the warehouse using the identity providers' Snowflake-native integrations. LiveRamp's Snowflake Native App processes hashed emails to RampID without data leaving the warehouse. The UID2 integration runs through Snowflake's Native App framework. The device graph data (Experian, TransUnion) is licensed directly through Snowflake Marketplace and joined in-warehouse.
This means the match is observable, auditable, and controllable. You can see the match rate per identity provider, per campaign, per channel. You can rerun the matching with different parameters. You can audit which records were matched deterministically vs. probabilistically. You cannot do any of this with a SaaS black box.
The output of Silver Step 2 is a canonical identity spine: customer_id, ramp_id, uid2_token, household_ip, match_type (deterministic / probabilistic), match_confidence, consent_scope. Everything downstream — measurement, activation, reporting — reads from this spine.