First-Party ID Solutions (UID2, RampID)
Why the Industry Built New IDs At All
With third-party cookies unreliable across Safari and Firefox (and increasingly user-controllable in Chrome) and mobile IDFA largely opt-out by default post-ATT, the ad tech ecosystem needed a durable, interoperable identifier that doesn't depend on a browser-set cookie surviving across sessions and sites. The answer that gained the most adoption: build the identifier from consented first-party data (an email address a user gave directly to a publisher or advertiser) and resolve it into a shared, hashed, interoperable ID that works across participating platforms — hence 'first-party' ID solutions, as opposed to third-party cookie-based IDs.
Unified ID 2.0 (UID2)
UID2, originally developed by The Trade Desk and now governed by an independent organization (Prebid.org-adjacent governance structure), generates an identifier from a hashed, salted email or phone number. The key architectural idea is salt rotation and token refresh: UID2 doesn't expose a permanently static identifier — it issues short-lived, refreshable advertising tokens derived from the underlying identity, which can be revoked or refreshed, and the raw hashed identifier used to generate tokens is itself periodically re-salted, limiting the window in which a leaked token remains useful for tracking. UID2 is open-source and designed to be used across many DSPs, SSPs, and publishers rather than being locked to one platform.
RampID (LiveRamp)
RampID (formerly IdentityLink) is LiveRamp's identity resolution product, built around a persistent, pseudonymous ID tied to resolved offline and online identity graphs that LiveRamp maintains and licenses access to. Unlike UID2's more narrowly scoped, email-hash-token model, RampID leans on LiveRamp's broader identity-resolution infrastructure (built from years of offline data onboarding relationships) to stitch together a person's various device and cookie-level identifiers into one durable graph node, which partners can then target and measure against consistently across channels.
UID2 vs. RampID
| Dimension | UID2 | RampID |
|---|---|---|
| Governance model | Open-source, independent governance | Proprietary, LiveRamp-owned |
| Core input | Hashed email/phone, directly consented | Resolved identity graph (online + offline) |
| Token lifecycle | Refreshable, salt-rotated tokens | Persistent pseudonymous identifier |
| Primary adoption base | The Trade Desk ecosystem and partners adopting the open spec | LiveRamp's extensive publisher/advertiser integration network |
// Simplified conceptual flow — actual SDK handles crypto details
async function getUid2AdvertisingToken(rawEmail: string): Promise<string> {
const normalizedEmail = rawEmail.trim().toLowerCase();
// Server-side call to UID2 operator service; the operator hashes +
// salts the email and returns a short-lived advertising token,
// never the raw identifier itself.
const response = await fetch("https://prod.uidapi.com/v2/token/generate", {
method: "POST",
headers: { Authorization: `Bearer ${process.env.UID2_API_KEY}` },
body: JSON.stringify({ email: normalizedEmail }),
});
const { advertising_token, refresh_token } = await response.json();
return advertising_token; // short-lived, used in bid requests
}Consent Infrastructure Is Load-Bearing, Not Optional
What's Next?
First-party ID solutions are one entrant in a broader, still-fragmented universal ID landscape — comparing them against the full set of competing approaches clarifies which fits a given publisher or advertiser's existing data and partner relationships.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.