Unified ID 2.0 vs. RampID: Which Identity Framework Fits Your Ad Stack?

Set the gdprApplies flag to true on a page running the Unified ID 2.0 Prebid module and the module goes quiet. It reads the consent data you pass it, refuses to operate, and sends no token to any bidder. That single behavior settles more of the UID2 versus RampID question than any cryptography: where your traffic sits, what consent it carries, and which buyers can read the identifier on the other end decide which framework actually pays. Both frameworks promise deterministic identity built from first-party email data, but they arrive through different plumbing, different licensing, and opposite consent behavior.

What each framework actually is

Unified ID 2.0 is a framework enabling deterministic identity for advertising on the open internet, built as an open-source standalone solution with its own namespace and licensed under Apache License 2.0. The official UID2 overview documents the participants, the operator role, and the open-source model in full. The source code was contributed to IAB Tech Lab, and the Tech Lab Privacy and Rearc Commit Group governs future development of both the specification and the code.

Governance matters operationally, not just on paper. A spec held by a standards body cannot get repriced mid-quarter by a single vendor, and a format change has to move through a commit group instead of a product roadmap. You still depend on UID2 operators to mint and refresh tokens, but the rules of that relationship sit in public documents rather than in a contract you negotiate alone.

RampID, formerly known as IdentityLink, is a single person-based identifier. In Prebid it arrives as an identity envelope that LiveRamp encrypts with a rotating key, so the stored value stays opaque to other scripts on your page. LiveRamp's Authenticated Traffic Solution resolves consented user data to a RampID envelope in real time whenever a user provides an email address, through hashing, salting, and private key encryption. One company's identity graph gives RampID its reach, and the same company's roadmap sets its limits.

Deterministic identity is the shared premise, and it separates both frameworks from the fingerprinting approaches regulators keep shutting down. Each identifier starts from data the user handed over, an email address or a phone number, and each derives a stable value from it. Buyers trust deterministic signals enough to bid against them, and consent frameworks can govern them because the data source is explicit.

The distinction in one sentence: UID2 is an open standard surrounded by operator infrastructure; RampID is a commercial identifier anchored to a commercial graph. Everything else in this comparison follows from that difference.

How each identifier reaches the bid request

UID2 tokens never originate in the browser. You generate them server side through an API call to a UID2 operator, using encrypted email and phone number data, and the operator returns a token the page can forward. The Unified ID 2.0 Prebid submodule documents the token flow and the client-side configuration that reads the token into the userId structure of the bid request. That sequence carries a hard operational consequence: UID2 needs a backend. Someone, your engineers or a partner acting for you, has to receive the email, encrypt it, call the operator, and surface the token to the page or to your server-side adapters.

RampID generation runs on the page itself. When a user provides an email address, ATS resolves consented data to an envelope in real time, through hashing, salting, and private key encryption, and stores it where the RampID Prebid submodule can read it. The module guidance sets a 15-day TTL for GDPR and CCPA compliance, with envelope refresh every 30 minutes so the stored value keeps pace with the rotating key. Your backend never touches the encryption. LiveRamp owns key rotation, and you own consent gating.

From storage, both identifiers travel the same road. Prebid writes them into the userId structure, and the bid request carries them in the OpenRTB user.eid array, the standard slot for extended identifiers. A bidder that has onboarded the namespace resolves the value and prices the user accordingly; a bidder that has not, ignores it. Neither framework adds meaningful request weight, so the config work is cheap and the payoff question is purely buyer readability.

Server-side header bidding changes none of this. Tokens and envelopes ride along in the same userId structure when Prebid forwards the request server side, and adapters attach them to OpenRTB 2.6 bid requests the same way the client does. If you run a hybrid setup, header and server-side demand together, configure identity once in Prebid and both paths inherit it.

The engineering bill differs in kind, not in degree. UID2 asks for server-side work before anything reaches a browser: an endpoint, an operator relationship, token lifecycle management. RampID asks for a tag integration and acceptance of a third party's key schedule. Teams with thin backend capacity usually ship RampID first. Teams with an established first-party data pipeline often find the UID2 operator model a cleaner extension of what they already run.

Both frameworks also do their best work in a first-party context. Because each identifier derives from data the user gave you directly, neither depends on third-party cookies, which major browsers have already disabled or restricted. The identifier lives in your storage, on your domain, which is why identity built this way survives the browser changes that killed the last generation of tracking.

Consent behavior decides the geography

The UID2 Prebid module is not designed for use where GDPR applies. It checks the consent data you pass it, and if the gdprApplies flag is true, it does not operate. There is no partial mode and no workaround at module level: pages serving the EU, the EEA, or the UK produce no UID2 tokens in a Prebid context, even when the TCF string carries valid consent.

RampID takes the opposite path inside the same consent framework. The envelope lives for its 15-day TTL, refreshes every 30 minutes, and consented European traffic still carries an identifier, one that expires on a schedule a privacy team can audit. Unconsented traffic carries nothing, which is the point. The TTL and refresh figures are guidance written for GDPR and CCPA compliance, not defaults to tune upward.

This split forces a geo-segmented identity config. Publishers with heavy EU and UK footprints get more from RampID, because consented GDPR traffic still monetizes through an envelope while UID2 output stays at zero for the same sessions. Publishers concentrated in the US, LATAM, or APAC can lean on UID2, where its buyer adoption concentrates anyway. Gate the userId modules per geo, wire the CMP signals through the consentManagement config correctly, and QA storage after release: a module that writes under a true gdprApplies flag is a compliance defect, not a monetization win.

None of this strands your European inventory. GDPR traffic without consent still bids on contextual signals, page category, device, geo, and consented sessions still carry the RampID envelope where coverage exists. Identity adds a premium layer on top of demand that never went away, so segment your reporting from day one and keep the lift measurement clean.

The US sits in between. UID2 runs there without the GDPR gate, RampID's TTL guidance covers CCPA compliance, and both frameworks expect you to honor opt-out signals from your CMP or US privacy string. Identity config is regional, never global, so write it that way from the start.

The input decides more than the framework

Both frameworks monetize the same thing: sessions where a user gave you an email address. No identifier, open-source or commercial, can price a fully anonymous pageview, so the share of authenticated sessions bounds the upside before any module loads. If logins and newsletter forms cover a thin slice of your traffic, the choice between UID2 and RampID is worth less than the capture work you have not done yet.

Walk the funnel before you walk the config. Login flows, newsletter forms, comment systems, account creation, subscription and paywall steps: each is an identity touchpoint with a measurable conversion rate you can improve through placement and timing. The cheapest identifier win is often a better-placed signup form, not a new submodule. After capture improves, pick the framework that matches where those users actually are.

Who on the buy side reads the identifier

An identifier pays only when a bidder recognizes it. UID2's readability concentrates among the major DSPs: The Trade Desk originated the framework, and its seats read the namespace natively. The other large buyers, DV360, Amazon DSP, and Criteo among them, parse the same user.eid array; what differs is which namespaces each has onboarded against its own graph. A UID2 token no buyer has onboarded earns exactly nothing, which is why buyer mix, not philosophy, should drive the choice.

RampID's readability comes from the graph behind it. LiveRamp built its business onboarding advertiser CRM data and resolving it to person-level identifiers, so a DSP holding a RampID envelope has a strong chance of mapping it to a profile it can price. LiveRamp claims RampID delivers up to 50 percent better match rates than other identifiers. Treat that figure as the vendor's own until your logs confirm it, but the mechanism is real: an identifier anchored to a commercial graph converts to a recognized user more often than a namespace the buyer has never onboarded.

Ask two questions before committing engineering time. Which identifiers do your top-revenue buyers actually consume, and do they consume them in the geos where your traffic sits? We work the same question from the agency side of the house: buyers plan campaigns against verified audiences and curated supply paths and buy through OpenRTB 2.6 seats, and they pay more for impressions an identifier has already resolved.

A buyer-mix check takes one report, not one quarter. Pull revenue by buyer seat and by geo, cross-reference which buyers hold which identity integrations, and the framework choice usually writes itself. Buyer concentration can settle the question outright: if one buyer dominates your revenue and it bids against UID2, the debate ends there.

What identity does to auction outcomes

Identity changes bids before it changes revenue. A bidder that recognizes the user prices the impression against its own data instead of contextual inference alone, and in a first-price auction that recognition moves the shaded bid closer to the buyer's true value. Shading is the hedge buyers take against overpaying for an unknown user, and identity shrinks the hedge. Our seats run the same auction mechanics and bid shading as the open market, with expected-value ranking and reserve prices, and identity-driven demand clears differently against those floors than anonymous traffic does.

Three effects follow. Frequency management moves buyer side, so a buyer who recognizes the user stops wasting budget on repeat impressions and concentrates spend where it counts. Audience-based bidding replaces approximation, because campaigns built on CRM segments find their actual users on your inventory. Measurement improves for the buyer, and buyers who can measure their spend tend to renew it.

Reserve prices interact with all of this. Authenticated, identity-carrying impressions attract stronger demand than the same pageview from an anonymous session, so a single sitewide floor now underprices one segment or overprices the other. Test floors per segment, anonymous versus authenticated, rather than raising them globally on the promise of identity.

What you should not do is promise finance a fixed uplift. Match rates vary by buyer, by geo, and by the share of your traffic that ever enters an email address, and a site with thin authenticated sessions sees a fraction of the benefit a login-first property sees. Test instead: hold out a control cohort, measure CPM by authenticated state and by geo, and let the deltas decide. Publishers tracking that split in a ten minute reporting console catch the signal within days, because identity-driven lift shows up buyer by buyer rather than as a sitewide blur.

Running both is the usual answer

The two modules coexist in Prebid without conflict. They write to separate storage keys, different bidders read different fields, and the userId structure carries whatever each submodule found. There is no licensing collision either: Apache 2.0 terms bind the UID2 side, LiveRamp's commercial terms bind the ATS side, and they never touch. Stacks above one million monthly pageviews typically end up carrying both, weighted by geography and buyer mix: RampID where GDPR governs and consent coverage is real, UID2 where its buyers concentrate and the law permits it.

We run that exact setup at scale. At OnlyMedia we are an ad network, an SSP and an agency in one company, and we integrate OpenRTB 2.6 seats and Prebid for header and server-side demand for thousands of publishers, each above one million monthly pageviews. The curated programmatic demand network behind those seats is where the buyer-mix questions above get answered, because a seat that cannot read an identifier never prices it. We pay publishers Net 30, CPM based, so a lift you measure this month reaches your payment run inside the next cycle, no chasing, no sliding terms.

One legal review belongs on the critical path. Adding an operator call or an ATS tag changes your data flow, so update the privacy notice to describe identifier generation from email, and have counsel confirm controller and processor roles before the modules ship. Both frameworks exist to operate under exactly this scrutiny, and clean consent records keep them running.

Rollout sequence, whichever you pick

The order below gates each step on the one before it. Email capture comes first, because both frameworks monetize only sessions that hand you an address.

1. Audit capture points: logins, newsletter forms, comment systems, subscription and paywall flows. Fix the leaks before touching Prebid, since no identifier monetizes an email you never received.
2. Stand up generation: deploy the ATS tag for RampID, and build or contract the server-side operator calls for UID2. Decide who owns the backend work early, because that decision is the real cost of UID2.
3. Configure the userId submodules with geo gating: keep the UID2 module out of GDPR regions, and set RampID storage to the 15-day TTL with the 30-minute refresh per the guidance.
4. QA consent behavior in storage: confirm the UID2 module writes nothing under a true gdprApplies flag, and confirm RampID envelopes expire on schedule and re-encrypt on refresh.
5. Measure by cohort: CPM by authenticated state, by geo, and by buyer, with a control group held out for the test window. Revisit quarterly, since buyer onboarding shifts the answer.

UID2 versus RampID is a traffic-mix question wearing a technical costume. GDPR-heavy publishers need RampID's consent-native envelope; publishers concentrated outside Europe can push UID2's buyer adoption harder; most stacks above one million monthly pageviews run both and let the bidders sort it out. Configure per geo, gate on consent, measure by cohort, and the choice stops being a debate and starts showing up as line items on a payment report.