A user ID module is plumbing, not a cookie replacement itself

The revenue mechanism

Header bidding lets a publisher offer one ad impression to many demand sources at once, and each bidder's willingness to pay more for that impression has long depended on recognizing the same user across sites, historically through third-party cookies. As browsers restrict that cookie, publishers using the open-source Prebid.js software have turned to its User ID module, whose own documentation, retrieved 16 September 2026, states it supports multiple ways of establishing pseudonymous IDs for users as a way of increasing the value of header bidding, so that a publisher can integrate with one of a number of ID schemes rather than have every exchange separately sync cookies with dozens of demand sources.

What the documents show

Prebid's documentation describes the module as plumbing, not an identity source of its own: a publisher chooses which ID sub-modules to add when building their Prebid.js package, for example specifying sharedIdSystem, unifiedIdSystem or a similar named module, and configures them through the standard setConfig() call. If the user has consented to local storage, the module either calls the identity provider's URL or reads a locally stored value, then injects the resulting identifier into the bid request the module labels userId. The documentation names GDPR consent as a gating condition on this process and states the choice of which ID schemes to run, and what disclosures to give users, rests with the publisher and its own legal counsel, not with Prebid.org, which describes itself as an independent, community-run header-bidding project.

The assumptions exposed

The module is a technical framework for carrying an identifier, not a guarantee that any given identifier will be recognized or valued the same way by every bidder; each named scheme is a separate company's product with its own coverage among buyers, and Prebid's page does not claim uniform buy-side support for any of them. Adding an ID module does not by itself replace the reach of third-party cookies, since a bidder still needs integrated support for that specific scheme. The documentation's own note that, without third-party cookies, mechanisms like the Network Advertising Initiative's opt-out link stop working is a reminder that a new identifier also changes which existing consumer-control tools still function.

What to check before you rely on it

This is an editorial checklist, not legal advice. Before adopting a specific ID sub-module, a publisher can check which demand partners actually bid against that identifier today, confirm with counsel what consent and disclosure the chosen scheme requires, and verify that any existing opt-out mechanism promised to readers still functions once third-party cookies are no longer the basis for that opt-out.

• Which of my current demand partners actually recognize this specific identifier in a bid?
• What consent does Prebid's own documentation say this module requires before it will store or send an ID?
• Does adopting this identifier change how an existing reader opt-out mechanism, such as an NAI link, actually works?

A User ID module changes how a publisher's ad stack passes an identifier along; it does not, by itself, restore the exact revenue that third-party cookie-based targeting once supported.