UID2 vs RampID: What Data Buyers Should Know

What Each Identifier Is and Who Runs It

Unified ID 2.0, usually written UID2, is an identity framework for advertising on the open internet. The Trade Desk wrote the original code and contributed the UID2 source code to the IAB Tech Lab for open-source development. The plan from the start was for independent organizations to run it. That handover has not finished. The UID2 documentation's overview of participants names The Trade Desk as the current Core Administrator, the role that distributes encryption keys and salts to operators and passes opt-out requests on to operators and DSPs. The Trade Desk also runs a public operator.

You will still see Prebid.org described as the operator of UID2. That was the plan when Prebid.org announced in February 2021 that it would serve as an operator. AdExchanger later reported that Prebid paused that integration because its community did not think Prebid should hold such a central role until an independent administrator was in place. Prebid still supports UID2 in the header, as described below, but it does not administer or operate it.

RampID is LiveRamp's identifier. It was called IdentityLink until LiveRamp renamed it in May 2021. LiveRamp's developer documentation describes RampIDs as pseudonymous identifiers tied to a record in the LiveRamp identity graph, used to recognize and consolidate records across systems. It is a proprietary product. LiveRamp builds it, maintains the graph behind it and sets the terms for its use.

How Each One Is Built

UID2 starts with normalization. The UID2 normalization and encoding guide has you trim and lowercase the email address, apply the Gmail rules, create a 32-byte SHA-256 hash and then Base64-encode it. Phone numbers are normalized to international format before hashing. According to how the UID2 token is created, a UID2 operator then adds a secret salt to produce the raw UID2, and salts rotate over time. Encrypting the raw UID2 produces a UID2 token, and because a nonce is added each time, the token is different every time it is generated, even for the same person. The raw UID2 is what advertisers and data providers store. The token is what travels in the bid stream.

RampID starts with LiveRamp's graph. If LiveRamp holds a maintained record for the input, it returns a maintained RampID. If it does not, it returns a derived RampID for each touchpoint it received, such as a name and postal address, an email or a phone number. LiveRamp's guide to interpreting RampID says maintained RampIDs start with XY and derived ones with Xi, and that a derived RampID converts to a maintained one once LiveRamp can resolve the touchpoint to a person.

The other design choice to know about is encoding. Each RampID carries a partner encoding that makes the value unique to the company receiving it, and LiveRamp's RampID Translation endpoint exists to convert RampIDs from one partner encoding to another. In practice, two companies cannot join their files on RampID by themselves. The join happens through LiveRamp, or in an environment LiveRamp supports. On the publisher side, LiveRamp's Authenticated Traffic Solution turns an email a visitor provides into an encrypted envelope containing a RampID, which is what reaches the bid stream.

How Consumers Opt Out

UID2 has one global opt-out. The UID2 opt-out documentation points consumers to the Transparency and Control Portal, where they enter an email address or phone number. After that, the person's UID2 is no longer accepted for targeted advertising anywhere in the UID2 ecosystem, and participants are expected to honor it. Individual publishers can also run their own site-level opt-outs.

LiveRamp runs its own consumer choice process. Its opt-out page offers an opt-out of all LiveRamp products by email address, plus separate opt-outs for its mobile identifier, its third-party cookie and cross-screen measurement. A buyer should not assume that an opt-out filed with one program reaches the other. They are separate systems, so ask each partner how both kinds of opt-out reach your audiences and your stored files.

Interoperability and Where Each Is Accepted

Both identifiers reach the open-web auction through Prebid.js, which ships a UID2 user ID module and a LiveRamp RampID module. On the buy side, The Trade Desk and LiveRamp said in a February 2022 announcement that marketers could already buy on both RampID and UID2 inside The Trade Desk's platform, and that LiveRamp would make RampID interoperable with the European Unified ID.

Geography matters. UID2 is not the framework for Europe. The European Unified ID, EUID, builds on UID2 with its own namespace and follows European and UK rules on consent and data subject rights. If your campaigns run in the EEA or the UK, the question is EUID or RampID, not UID2.

On cost, we found no published price list for either identifier that a buyer could compare, so we do not quote one. Identifier use is usually priced inside a media, data or platform contract. Ask each partner to show where it appears on the invoice.

UID2 vs RampID at a Glance

When You Need One, the Other or Both

You probably need UID2 if most of your programmatic spend runs through The Trade Desk or other DSPs that read UID2, if your first-party data is mostly emails and phone numbers you can hash yourself, and if you want to generate identifiers without sending your file to a graph provider. You also need to be ready to handle salt rotation for raw UID2s you store, and to honor the global opt-out.

You probably need RampID if you already onboard CRM files through LiveRamp, if your measurement or clean-room partners key on RampID, or if you want person-level resolution across several touchpoints rather than one identifier per email. The maintained and derived distinction matters here: ask what share of your file comes back maintained, because a derived RampID is not yet a person.

Many larger buyers carry both, because publishers and platforms differ in what they pass and read. If you do, keep them as separate keys in your warehouse rather than forcing one into the other, and record which input produced each. Our cookieless activation primer covers how these identifiers sit next to contextual targeting and first-party data, and the GSDSI vs LiveRamp comparison sets out where a data supplier and an identity network differ.

How Hashed Email and MAID Data Relate to Each

Both identifiers are downstream of an email address, which makes a hashed email (HEM) the practical bridge into either one. The UID2 token generation endpoint accepts an email hash as input, as long as it is the Base64 encoding of a SHA-256 hash of a normalized address. Many HEM files are delivered as 64-character hexadecimal strings instead. That is the same hash written differently, so the fix is to convert hex to bytes and re-encode, not to hash again. LiveRamp's Lookup endpoint accepts SHA-256, SHA-1 or MD5 hashed emails and returns a maintained RampID where one exists and a derived one where it does not.

A mobile advertising ID sits one step further away. UID2 does not take a MAID as input, so a MAID reaches UID2 only through a link to an email. That is the job a MAID-to-HEM linkage does. GSDSI's identity graph carries a hem field, a SHA-256 hashed email for CRM onboarding and deterministic matching, next to MAIDs and a link_type field that separates deterministic from probabilistic edges. The MAID feed supplies the device side. Normalization has to match on both ends, so check the spec before you judge a match rate.

Hashing is not anonymization, and the link carries the same obligations as the email it came from. Before licensing any linkage, run a matched test on your own file as described in seed-match testing, ask about freshness using the questions in device graph decay, and read identity graphs 101 for how the keys fit together. The Identity and Activation topic hub collects the rest of our identity guides.