The Trade Desk formally launched Unified ID 2.0 this month, and the rollout has been met with a response that could fairly be described as enthusiastic skepticism. The technical proposal is sound. The governance questions are real. And the industry’s discomfort with a buy-side company owning the infrastructure for a shared identity system that publishers depend on is a legitimate concern that UID2’s proponents have not yet fully resolved.

To be clear about what UID2 is and what The Trade Desk is proposing: this is not a proprietary walled garden play in the same way that Google’s Privacy Sandbox or Facebook’s audience network is. The Trade Desk has published UID2’s technical specification, committed to open governance, and invited SSPs, publishers, measurement companies, and data providers to participate as operators. The intent — at least as stated — is a community-owned identifier that replaces the third-party cookie as a durable user identifier for programmatic advertising.

But stating an intent and building the governance structures that give it legal and operational credibility are different things, and the industry is right to scrutinize both.

What UID2 Actually Is

Unified ID 2.0 is, at its core, a standardized method for converting a user’s email address into a pseudonymous identifier suitable for use in programmatic advertising without requiring cross-site cookie syncing.

The mechanism: a user provides their email address to a publisher, an advertiser, or another data-collecting party. That email address is hashed — run through a cryptographic function that produces a unique, consistent string from the same input — and then encrypted with a key managed by a central operator. The resulting token, called a UID2 token, can be passed in bid requests and used by DSPs and SSPs to match user identity across participating publishers without exposing the underlying email address.

The key insight is that UID2 creates a portable, cross-site identifier that is not a cookie — it does not live in the browser’s cookie store, it is not blocked by Safari or Firefox’s cookie restrictions, and it survives the Chrome third-party cookie deprecation. Where it does depend on user behavior: users must authenticate with a participating publisher by providing their email, which means UID2 tokens are only available on authenticated inventory.

The Trade Desk’s UID2 specification is published publicly on GitHub and covers the API structure, token format, key rotation mechanics, and operator requirements. The technical quality of the specification is generally regarded as high by the adtech engineers who have reviewed it.

Why Publishers Are Cautious

Publishers are the swing vote on UID2’s success. UID2 tokens are valuable in proportion to how many publishers are generating them, because an identifier that appears on a handful of sites provides limited scale for cross-site frequency management and campaign reach. For UID2 to work as a cookie replacement across the open web, publishers need to authenticate their users and pass UID2 tokens in their bid streams at meaningful scale.

Publisher hesitation comes from two sources. The first is structural: UID2 was designed by The Trade Desk, which is primarily a demand-side platform. Publishers looking at UID2 governance are looking at an identity infrastructure designed by a buyer, optimized for buyer use cases, with a governance structure that may not give publisher interests equal weight. When The Trade Desk controls the encryption keys in the central UID2 operator model — even temporarily, until independent operators take over — publishers are dependent on a DSP’s infrastructure for the identity signals that determine their inventory value.

The second concern is less structural and more competitive. Publishers investing in first-party identity infrastructure are building an asset. The publisher with strong user authentication and rich first-party data has a competitive advantage in a post-cookie world. Sharing that first-party data into a shared identity system that a DSP can use to match across competing publishers reduces some of that competitive advantage. The value exchange needs to be clear.

Governance: Who Owns the Key?

The central governance question for UID2 is who controls the cryptographic key that transforms hashed email addresses into UID2 tokens — and therefore, who can see the relationship between a user’s real identity and their UID2 pseudonym.

In the initial UID2 architecture, The Trade Desk operated the key management infrastructure as the central operator. The long-term model calls for independent third-party operators — parties who are neither buyers nor sellers in the advertising ecosystem — to manage the keys, with The Trade Desk transitioning out of the operator role. The Trade Desk has pointed to potential operators including Prebid.org or an independent non-profit structure.

This transition has not happened yet, and the commitment to independent governance is currently a statement of intent rather than a binding structural reality. Publishers and SSPs evaluating UID2 are being asked to trust The Trade Desk’s governance intentions while the current architecture retains central operator control with a buy-side company.

IAB Tech Lab is engaged with the UID2 working group and has published technical feedback. A genuinely neutral central operator for UID2 — with governance structures that give publishers, SSPs, and DSPs equal representation — would address many of the structural concerns. Whether that structure gets built, and on what timeline, will determine whether UID2 achieves the broad publisher adoption that makes it viable.

The Alternative Identity Landscape

UID2 is not the only post-cookie identity approach in development, and the competition among identity solutions is itself a governance question: does the industry want one shared identifier or a competitive identity ecosystem?

LiveRamp’s Authenticated Traffic Solution (ATS) and its RampID identifier are a direct competitor to UID2. ATS is publisher-operated and positioned as publisher-first: the matching infrastructure lives with LiveRamp as a neutral third party, and publishers have more direct control over the identity signals flowing through their inventory. RampID is more established at scale than UID2 today, with a larger publisher network, but it is a proprietary LiveRamp product rather than an open standard.

ID5 is another independent identity graph attempting to provide a cookie-syncing replacement that works across authenticated and modeled traffic. Criteo’s Shared ID, the UTIQ from European telcos, and the Prebid ID modules provide additional alternatives.

The multiplicity of identity solutions creates its own problem: DSPs and publishers building integrations must support multiple ID types in bid requests, and the signal that accumulates around any single ID type will be diluted by the fragmentation. The industry arguably needs consolidation, but consolidation around a buyer-controlled identity infrastructure like UID2 is not the same as consolidation around a truly neutral shared standard.

FAQ

How does UID2 actually work in a bid request? In a UID2-enabled programmatic transaction, a publisher with authenticated users generates UID2 tokens from users’ hashed email addresses by calling the UID2 operator API. These tokens are passed in the bid request’s user.buyeruid field or similar OpenRTB extension fields. A DSP that has integrated with UID2 can decrypt the token (using keys the DSP has obtained from the operator) to derive the UID2 for that user and match it against audience segments, frequency caps, and attribution records keyed to that UID2. The token is time-limited and rotated to prevent persistent tracking, while the underlying UID2 identifier remains consistent for the same email address.

Does UID2 solve the privacy problem or just move it? UID2 moves the privacy mechanism from browser cookies — which users can delete and browsers are blocking — to email-based authentication, which requires explicit user action (logging in, providing an email) but is then persistent in a way that users may not fully understand. Whether UID2 is genuinely more privacy-respecting than cookies depends on implementation: if users are clearly informed that their email-based login is used for programmatic advertising and they are given meaningful control, it is arguably better. If it becomes a covert tracking mechanism through widespread publisher authentication, it replicates the privacy problems of cookies in a different technical form. The privacy calculus depends on transparency and consent implementation.

Will UID2 work on Safari and Firefox where third-party cookies are already blocked? In authenticated environments — where users have logged in and provided their email — yes. UID2 tokens are passed server-side rather than through the browser cookie store, so they are not subject to browser-level cookie blocking. However, on non-authenticated inventory — which is the majority of the open web — UID2 provides no signal. Safari and Firefox users who browse without authenticating remain unaddressable by UID2, the same as they are by cookies on those browsers.

Should publishers integrate UID2 now or wait? Given that the governance structure is still evolving and the independent operator transition has not happened, publishers have legitimate reasons to evaluate UID2 integration carefully rather than moving immediately. The practical question is whether the current authentication infrastructure investment is wasted if UID2 governance doesn’t resolve satisfactorily. Since publisher-side user authentication is valuable regardless of which identity framework wins — authenticated users enable first-party data activation on any platform — the authentication investment is durable. The specific UID2 integration is the more selective decision.