Unified ID 2.0 (UID2)

UID2 relies on hashed and salted email addresses or phone numbers to create a definitive identity token. Unlike probabilistic methods that infer identity from IP addresses or browser fingerprints, UID2 provides absolute certainty in user recognition. This deterministic foundation eliminates the guesswork and confidence scores inherent in statistical matching, ensuring that the user on a mobile device is the same user on a desktop when they authenticate with the same email.

The entire UID2 framework is publicly accessible and auditable. The source code, operator specifications, and cryptographic protocols are available on GitHub, allowing any organization to inspect the security model or run their own private operator instance. This transparency is a direct counterpoint to the opaque, proprietary nature of third-party cookies, fostering trust among publishers, advertisers, and privacy regulators.

UID2 never exposes a raw email address. The framework applies a one-way cryptographic hash combined with a rotating salt to transform the email into a pseudonymous identifier. The salt is regularly refreshed, requiring re-authorization and preventing the creation of a permanent, static identifier. This process ensures that even if a UID2 token is intercepted, it cannot be reversed to reveal the original personally identifiable information (PII) without the transient decryption key.

A core tenet of UID2 is explicit user control. Consumers are presented with a clear, standardized interface explaining how their email is being used for advertising. They can view the specific advertisers targeting them and revoke their consent at any time. This opt-out mechanism is built directly into the protocol, creating a direct value exchange between the user and the publisher, rather than the hidden tracking of third-party cookies.

UID2 is not a single, centralized database controlled by The Trade Desk. It operates through a network of independent administrative operators who manage the cryptographic keys and the salting process. This decentralized architecture prevents any single entity from monopolizing the identity layer and allows for private operator instances, where a brand or publisher can manage their own UID2 ecosystem in complete isolation from the broader network.

A UID2 token is not a permanent identifier. It has a finite lifespan and must be continuously refreshed using a refresh token. This lifecycle management ensures that identity data does not become stale. If a user revokes consent or stops engaging with a publisher, the token simply expires and cannot be regenerated, automatically enforcing privacy preferences without requiring manual data deletion by downstream vendors.

The foundational identifier of UID2. A user's plaintext email is transformed using a one-way cryptographic hash combined with a randomly generated salt before transmission. This ensures the raw personally identifiable information (PII) is never exposed. The salt is rotated regularly to prevent re-identification through rainbow table attacks, creating a privacy-compliant deterministic anchor for identity resolution.

A distributed network of trusted administrators responsible for running the core UID2 infrastructure. Operators manage cryptographic key generation, salt rotation, and access control. By decentralizing the operator role, the framework avoids a single point of failure or control, allowing multiple independent entities to maintain the system's integrity and transparency.

UID2 generates short-lived, rotating tokens to prevent persistent tracking. The lifecycle includes:

• UID2 Token: A temporary identifier generated from the hashed email, valid for a limited time.
• Refresh Token: A longer-lived token used to request new UID2 tokens without re-submitting the email. This rotation mechanism inherently limits the lifespan of any single identifier, reducing the risk of long-term user profiling.

A core privacy requirement where users must be provided a clear mechanism to withdraw consent. When a user opts out, their hashed email is added to a global opt-out list propagated to all operators. The system then ceases generating new UID2 tokens for that identifier, and existing tokens are invalidated at their next refresh cycle, effectively halting all targeted advertising tied to that identity.

Unlike probabilistic methods that infer identity with a confidence score, UID2 relies on an exact match of the hashed email. This provides a 100% match rate for authenticated users, eliminating the ambiguity of IP-based or fingerprinting techniques. For advertisers, this guarantees that the bid request represents a verified human identity rather than a statistical guess, drastically reducing wasted ad spend.

Before hashing, the raw email or phone number must undergo strict Directly Identifying Information (DII) normalization. This process standardizes the input by:

• Lowercasing all characters
• Removing whitespace and periods (for Gmail addresses) This ensures that [email protected] and [email protected] generate the identical hash, preventing fragmentation of the identity graph.