Universal ID explained from the publisher's side

A universal ID is a shared, pseudonymous user identifier that a publisher sets in its own first-party storage and passes to every bidder in the auction, so buyers can recognise the same visitor without third-party cookies. Common examples are Prebid's SharedID and Unified ID 2.0 (UID2), which is built from a hashed email address or phone number.

Why should you care? On Safari and Firefox, third-party cookies are already blocked, so buyers often see those visitors as strangers and bid less, or don't bid at all. A universal ID gives them something to match on. On Chrome, Google decided in October 2025 to keep third-party cookies, so the gap there is smaller than the old headlines suggested.

This guide explains what each ID is built from, which ones a site without logins can use, how to switch them on in Prebid and Google Ad Manager, and how to test whether they actually earn you more. If you'd rather have it set up and tested for you, that's part of our header bidding service.

What is a universal ID?

A universal ID is one identifier for a visitor that many ad-tech companies agree to read. The publisher creates or fetches it, stores it on its own domain, and sends it along with each bid request.

That last part is the whole trick. A third-party cookie is set by an ad-tech company on its own domain, and each buyer needs its own cookie and a "cookie sync" to line up with the others. A universal ID flips this round. The ID lives in your first-party cookie or local storage, and you hand the same value to every bidder at once.

Prebid's docs describe it plainly: the User ID module "supports multiple ways of establishing pseudonymous IDs for users". Pseudonymous is the key word. The ID isn't a name or an email address, but it does single out one browser or one person, so privacy law treats it as personal data.

IAB Tech Lab calls these tools a new category of technologies and publishes a framework for choosing and evaluating them on its ID solutions page. It doesn't endorse one ID over another, and neither do we. What matters is which ones fit your audience.

How do universal IDs work?

Universal IDs work in four steps: create or fetch the ID, store it on your domain, add it to every bid request, and let each buyer match it to its own data. All of it happens before the auction starts.

1. Create or fetch. When the page loads, an ID module either makes a random ID (SharedID does this) or turns something you know about the user, such as a login email, into an ID (UID2 does this).
2. Store. The module saves the ID in a first-party cookie or in the browser's local storage, so the next page view reuses it.
3. Attach. Prebid adds every available ID to the bid request in a standard list called extended IDs, or EIDs.
4. Match. Each DSP looks the ID up against its own records. If it knows that ID, it can apply frequency caps, audiences and its own bidding models, which is what lifts the bid.

The EID list is part of the OpenRTB 2.6 specification, which lists EIDs as "Extended identifiers support". In Prebid, bid adapters read it from bidRequest.userIdAsEids, and Prebid Server bidders read user.ext.eids. A trimmed bid request looks like this:

{
  "user": {
    "ext": {
      "eids": [
        { "source": "sharedid.org", "uids": [{ "id": "c29cb2ae-769d-42f6-891a-f53cadee823d" }] },
        { "source": "uidapi.com", "uids": [{ "id": "AgAAAAT...token" }] }
      ]
    }
  }
}

The source tells the buyer which ID system the value belongs to. A DSP that works with only one of them just ignores the rest.

If the auction itself is new to you, our guide to real-time bidding for publishers shows where the bid request fits, and our ad auction explainer covers what happens once the bids come back.

Types of universal ID solutions

Universal ID solutions fall into three groups, sorted by what they're built from: a login (deterministic), signals like device and network data (probabilistic), or a random first-party ID the publisher owns. The right mix depends mostly on whether your visitors sign in.

Here's the honest trade-off. Deterministic IDs match best, but only on the share of visitors who give you an email. First-party IDs reach almost everyone, but a buyer can only link them to what it has seen on your site before. Probabilistic IDs sit in between, and how well they match depends on the vendor, so judge them on a test rather than a sales deck.

Universal ID solutions publishers actually use

Most publishers start with three: SharedID because it's free and needs no login, UID2 if they have logged-in users, and PPID for Google Ad Manager. Vendor IDs come after that, one at a time.

SharedID

SharedID is Prebid's own first-party ID. The SharedID docs say it "stores an unique user id in the first party domain and makes it accessible to all adapters". It's sent with the source sharedid.org. You'll sometimes see it under its older name, the publisher common ID or pubcid.

SharedID won't follow a user from your site to another site. Its value is that every bidder sees the same stable ID for your returning visitors, including on Safari, so frequency capping and repeat-visitor bidding work again.

Unified ID 2.0 (UID2)

Unified ID 2.0 is an email-based ID framework. Its documentation calls it "a framework that enables deterministic identity for advertising opportunities on the open internet." The source code for its component services is public, and anyone who signs the participation agreement can use it.

A UID2 starts from a user's email address or phone number. The UID2 normalization guide lists those two types of directly identifying information, normalizes them, then hashes them with SHA-256. It also says "Publishers are the only participants who generate UID2 tokens using directly identifying information."

Don't mix UID2 up with the first Unified ID. That older ID was built on cookies. Several guides still describe the two as one product, which leads publishers to think UID2 works without a login. It doesn't.

The Prebid UID2 module spells out the rules: you "need to apply for publisher access on the UID2 website", UID2 "relies on user consent before an ID can be added to the bid stream", and your privacy policy should take UID2 into account. Users can opt out at any time through the Transparency and Control Portal.

PPID for Google Ad Manager

A publisher provided identifier (PPID) is your own first-party ID sent straight to Google Ad Manager. Google's PPID page sets the rules: at least 22 and at most 150 characters, "hashed or encrypted, so meaningless to Google", and never raw personal data. PPID is an Ad Manager 360 feature.

PPID helps Google's own demand with frequency caps and audience segments on your inventory. It doesn't go to Prebid bidders. That's what the next section's secure signals are for.

Other vendor IDs

Prebid supports dozens of ID modules, including id5IdSystem, identityLinkIdSystem (LiveRamp) and criteoIdSystem. Each one needs its own vendor account and terms, and each adds a script call. Add them only if a buyer you care about asks for that ID, and test them like anything else.

How to pass universal IDs to Google with secure signals

Secure signals let Google Ad Manager pass your universal IDs to the bidders you choose. Without them, IDs in Prebid reach Prebid bidders but not Google's Authorized Buyers or Open Bidding partners.

Google's secure signals page says publishers "can share secure signals on requests through Authorized Buyers, Open Bidding, SDK Bidding", and that signals "will only be shared at the publisher's explicit instruction". Prebid calls the same feature Encrypted Signals for Publishers (ESP).

The easy path on the web is the deploy option Google labels "Prebid UserID module (Beta)". Once you pick it, Google's page says, "Secure Signals automatically collect any signals you configure in Prebid UserID." So you set the IDs up once in Prebid, then in Ad Manager's secure signals settings you turn on sharing for each signal and each bidder.

Universal ID vs third-party cookies

A universal ID is set by you on your own domain and shared with all bidders at once. A third-party cookie is set by each ad-tech company on its own domain, and browsers decide whether it survives. That difference is why universal IDs still work on Safari and Firefox.

The last row is the one people forget. A universal ID is still personal data. Prebid's User ID module checks the GDPR consent string and, without consent, makes no calls to outside ID vendors. Since Prebid 11.14, any change in consent data (TCF, GPP, USP or COPPA) refreshes every ID module.

For the cookie side of the story, see our guide on what third-party cookies are and where they still work.

Do you still need a universal ID now Chrome keeps cookies?

Yes, for most sites, but for a smaller reason than before. Chrome's cookies stay, so the big win is on Safari, Firefox and any other browser that blocks third-party cookies, plus the users who turn cookies off in Chrome.

Google's Privacy Sandbox update of 17 October 2025 said Chrome will keep its current approach to offering users third-party cookie choice. In the same post Google retired most Privacy Sandbox APIs, including Topics, Protected Audience and Attribution Reporting. So there's no browser-side replacement coming for that targeting, and IDs in the bid request carry more of the load.

Many older guides still say Chrome is about to kill cookies. One page-one result says it would happen "by 2022". Plan for the browsers your visitors really use instead. Open your analytics, check the Safari and Firefox share by country, and you'll know how much of your traffic a universal ID can help.

How to set up the Prebid user ID module

Set up the Prebid user ID module in this order: consent, then SharedID, then any login-based ID, then secure signals, then a check that the IDs really appear in bid requests. Skipping the first step is the most common mistake we see.

1. Get consent working first

Load your consent management platform (CMP) before Prebid and add Prebid's consent management modules for the regions you serve. Without a valid consent string, the User ID module won't call ID vendors for EU and UK users, so a broken CMP quietly switches your IDs off.

2. Add SharedID

Build Prebid with the userId and sharedIdSystem modules, then add a config like this. Our Prebid.js setup guide covers the build step.

pbjs.setConfig({
  userSync: {
    userIds: [{
      name: "sharedId",
      storage: {
        type: "cookie",
        name: "_sharedid",
        expires: 365
      }
    }]
  }
});

Per the Prebid docs, name is required, storage.type is cookie, html5 or cookie&html5, and expires is the number of days to keep the ID. Pick an expiry your privacy policy and cookie notice can explain.

3. Add UID2 only if you have logins

If users sign in or subscribe, apply for UID2 publisher access, then add the uid2IdSystem module. You can pass a token generated on your server, or let the module build one in the browser from the email or phone (or their hash) with a subscription ID from the UID2 team. No login, no UID2: don't add the script just in case.

4. Turn on secure signals in Ad Manager

In Google Ad Manager, choose the "Prebid UserID module (Beta)" deploy option and switch on sharing per bidder. Then your IDs reach Google's demand as well as Prebid's.

5. Check the IDs are really sent

Open the page, open the browser console and run pbjs.getUserIds(). You should see each ID you configured. Then open a bid request in the Network tab and look for the EID list (here's how to read bid request data field by field). Test once with consent given and once with it refused, and on Safari as well as Chrome.

The Prebid docs warn that IDs can come back partial "depending on auctionDelay and/or syncDelay". If an ID only shows up on the second page view, that setting is usually why.

How to measure if a universal ID pays

Measure a universal ID with a split test, not with the vendor's uplift claim. Run the same pages with and without the ID for a couple of weeks and compare revenue per 1,000 page views on the traffic it's meant to help.

What we look at, in order:

• ID coverage. The share of bid requests that carry the ID. A login-based ID on a site where 3% of visitors sign in can't move much.
• Bid rate on Safari and Firefox. More bidders responding is the first sign the ID is being matched.
• Win price on those browsers. Compare the median winning bid, split by country.
• Revenue per 1,000 page views. The number that counts, because page weight and slower auctions can cancel a CPM gain.
• Page speed. Each vendor ID adds a script or a network call. Check that your LCP and INP don't slip.

If an ID doesn't move revenue per 1,000 page views after a fair test, take it out. If your reports can't split by browser and bidder, our reporting and yield service sets that up first.

Common universal ID mistakes we see

Most universal ID setups that don't pay fail for setup reasons, not because IDs don't work. These are the ones we fix most often:

• Stacking every ID. Ten vendor IDs add weight and delay. Buyers use one or two of them. Keep the ones that win a test.
• CMP loads after Prebid. The ID module sees no consent and skips the vendors, so the IDs never appear for EU and UK users.
• IDs never reach Google. Secure signals were never switched on, so Authorized Buyers bid blind.
• Treating hashed emails as anonymous. A hash of an email still points to one person. It needs consent and a line in your privacy policy.
• Judging on Chrome traffic. Chrome users with cookies are already matched. Test on the browsers the ID is meant to help.

IDs are one part of your data story. Our guide to DMPs for publishers covers the audience segments you can build on top of them.

Universal ID FAQ

These are the questions publishers ask us most about universal IDs, answered briefly.

What is a universal ID in simple terms?

It's one shared ID for a visitor that you store on your own site and send to every bidder in the auction. Buyers use it to recognise returning visitors without third-party cookies, which helps them bid on Safari and Firefox traffic.

Is a universal ID the same as a first-party cookie?

Not quite. A first-party cookie is just a place to store data on your domain. A universal ID is the value stored there, in a format many ad-tech companies agree to read. Most universal IDs live in a first-party cookie or local storage. The ID is one piece of a wider first-party data plan, alongside consent and segments.

Can a site without user logins use a universal ID?

Yes. SharedID and other first-party IDs need no login, and you can send a PPID to Google Ad Manager 360. What you can't use without logins is an email-based ID like Unified ID 2.0, because it's built from the user's email or phone number.

Is Unified ID 2.0 free for publishers?

UID2's source code is public, and publishers get access by applying and signing a participation agreement. Check the current terms on the UID2 site before you start, since they set what you must tell users.

Do universal IDs need consent under GDPR?

Yes. A universal ID is pseudonymous personal data, so in the EU and UK you need a valid legal basis, which in practice means a consent string from your CMP. Prebid's User ID module won't call outside ID vendors without it.

Will a universal ID raise my CPM?

It can raise CPM on traffic where buyers can't match users today, mostly Safari and Firefox, and do little on Chrome users who already carry cookies. The only way to know for your site is a split test on revenue per 1,000 page views.

Your next step

A universal ID helps buyers recognise visitors that cookies can't reach. For most publishers, that means getting consent right, adding SharedID, adding UID2 only if users really sign in, and switching on secure signals so Google's buyers see the IDs too. Then test, and keep only what pays.

If you want us to check which IDs reach your bidders today and what they're worth, send us your site and we'll take a look.