Unified ID 2.0 (UID2) is an open-source framework that publishers, advertisers, and digital advertising platforms can use to establish identity without third-party cookies.

The Trade Desk set out to develop Unified ID 2.0 following the announcement by Google that they plan to deprecate third-party cookies from their Chrome web browser, by 2022. Third-party cookies provided a way for digital advertisers to precisely target individual users on the web using first or third-party data.

Cookies provide a passive way to track users across the web. The passive nature of cookies led many to condemn the technology as privacy-invasive since ad tech companies often drop cookies on a user’s browser without their knowledge.

Cookies present valid privacy concerns, but many websites that users enjoy for free earn a bulk of their revenue from the advanced user-level ad targeting powered by cookies. When Chrome deprecates third-party cookies, advertisers will lose the precise targeting that makes web advertising such a valuable channel.

UID2 can provide a privacy-compliant identifier to power the advanced data targeting coveted by advertisers.

Unlike cookies, Unified ID 2.0 will require users to directly provide consent to a publisher by providing their email address before a publisher can create a UID2 identifier. Publishers will need to explain to the user the value-exchange of the open Internet and why creating a universal identifier for the ad tech ecosystem is crucial in providing the free content users have come to love.

How does UID2 Work?

The answer to this question depends on a company’s role in the ad tech ecosystem. The UID2 documentation supplies integration guides for:

• Publishers

• DSPs

• Advertisers / Data Providers

The walkthroughs below do not serve as a replacement for the official UID 2.0 documentation. The purpose of this post is to provide a simplified breakdown and additional context that you may not find in the documentation.

Following the breakdowns, you will find a lifecycle diagram that outlines how a UID2 may propagate through the ad tech ecosystem to deliver a targeted advertisement to a user. Click here to jump straight to that section.

But first, it is necessary to define several key terms:

UID2

The unencrypted alphanumeric identifier created from a user’s email address. A UID2 is the actual value that DSPs, data providers, and advertisers will store, but this value should never enter the bid stream.

This value is created by a UID2 operator (see below) by adding a secret salt to the email address and then passing that value through a hashing function.

Hold up, what is hashing? And what does salt have to do with anything?

Passing a value through a hashing function will turn it into a new and different value, obfuscating the original value. However, hashing the same value will always produce the same hashed output. "Salt'' is arbitrary data added to a value passing through a hashing function to increase the security of the hash.

UID2 Token

An ephemeral value that is the result of encrypting a raw UID2. Even though it may represent the same UID2, a UID2 token is a different value each time it enters the bid stream. This prevents the unauthorized building of profiles based on UID2 tokens. Since the values change, building profiles based on UID2 tokens is a useless endeavor.

Publishers, Single-sign on providers, and SSPs store UID2 tokens and DSPs decrypt the values into UID2s.

UID2 Administrator

The centralized service that manages access to the UID2 ecosystem. The UID2 Administrator will distribute encryption keys and salts to UID2 Operators and decryption keys to DSPs decrypting UID2 tokens. The UID2 admin will also send user opt-outs to UID2 Operators and DSPs.

It is expected that the IAB Tech Lab will serve as the UID2 Administrator.

Update 3-5-2022: The IAB said they will not take on the UID2 administrator role, "until wider industry adoption and evolution of the spec has been achieved."

UID2 Operator

Organizations that operate the infrastructure required to generate and manage UID2s and UID2 tokens.

Operators will receive salts and encryption keys from the UID2 Administrator. They will also operate an API that participants can call to receive UID2s or UID2 tokens.

PreBid.org will serve as the first UID2 Operator.

How does UID2 work for Publishers?

Publishers can choose to work with single-sign-on services or identity providers like Liveramp ATS already integrated with UID2, or they can choose to integrate UID2 directly into their existing login systems.

If publishers choose to integrate UID2 directly, they can follow either the web or app / CTV integration path.

UID2 for Web Publishers

Web publishers can utilize the Client-Side Identity SDK to simplify the integration. The JavaScript SDK provided by The Trade Desk can handle storing identity in a browser, refreshing tokens, and checking for user opt-outs.

The integration path is broken down into four parts:

1. Establish Identity

2. Bid Using UID2 Token

3. Refresh Tokens

4. Use Logout

Establish Identity

1. User registers or logs into a publisher website and authorizes the creation of UID2

2. Publisher sends email address to the UID2 operator token generation service

3. Token generation service returns UID2 token

4. Publisher passes UID2 token to the Client-Side Identity SDK:

<script>
__uid2.init({
identity : <Response from the generate token api>
});
</script>

The SDK will store the token in local web storage until the user logs out. Web storage is an alternative storage mechanism to a first-party cookie that can store data client-side in the browser.

Bid using UID2 Token

1. Publisher retrieves UID2 token from the SDK

<script>
__uid2.getAdvertisingToken();
</script

2. Publisher passes UID2 token to the SSP

The publisher will send the UID2 token in an ad request to their SSP, who will, in turn, include the UID2 token in a bid request to the DSP. The DSP will decrypt the UID2 token into a UID2 and match it to data stored in their system.

For now, think of the SSP or DSP using the decrypted UID2 value just like they would any identifier like a cookie ID, PPID, or IFA. They can use it for frequency capping purposes or match it to audience data stored in their system.

Refresh Tokens

UID2 tokens are constantly updated to ensure that unapproved entities with access to the bid stream cannot build profiles based on the UID2 token. The benefit of using the SDK is that it will handle refreshing the UID2 Token, and there is no action required from the publisher.

If the user has opted out of UID2 at any point, the SDK will return an empty string.

User Logout

1. User logs out of publisher property

2. Publisher calls the SDK disconnect mechanism:

<script>
__uid2.disconnect();
</script>

Calling the disconnect function clears out any UID2 tokens from web storage.

UID2 for App / CTV Publishers

Publishers who integrate UID2 into mobile or CTV apps will not have an SDK to assist them with storing and refreshing tokens. Instead, developers will need to develop mechanisms to accomplish these tasks.

Publishers can leverage APIs made available by a UID2 Operator to generate a UID2 token and refresh a UID2 token. The generation API expects an email address as an input, and it will return a UID2 token as an output along with a refresh token.

{
"body": {
"advertising_token": "NewAdvertisingTokenIjb6u6KcMAtd0/4ZIAYkXvFrMdlZVqfb9LNf99B+1ysE/lBzYVt64pxYxjobJMGbh5q/HsKY7KC0Xo5Rb/Vo8HC4dYOoWXyuGUaL7Jmbw4bzh+3pgokelUGyTX19DfArTeIg7n+8cxWQ=",
"refresh_token": "NewRefreshTokenAAAF2c8H5dF8AAAF2c8H5dF8AAAADX393Vw94afoVLL6A+qjdSUEisEKx6t42fLgN+2dmTgUavagz0Q6Kp7ghM989hKhZDyAGjHyuAAwm+CX1cO7DWEtMeNUA9vkWDjcIc8yeDZ+jmBtEaw07x/cxoul6fpv2PQ=="
},
"status": "success"
}

Publishers can call the token refresh API endpoint and pass the refresh token. The refresh API response will either include a new UID2 token and refresh token or no tokens and an opt-out status if the user has opted out of UID2. Publishers should check for refreshes every five minutes.

How does UID2 work for DSPs?

DSPs need to do two things:

1. Decrypt UID2 tokens to use in RTB

2. Honor user opt-outs

Decrypt UID2 tokens to use in RTB

DSPs need to use the UID2 RTB SDK Client to decrypt UID2 tokens to access the raw UID2. The SDK libraries are available for C# or C++ and require several initialization values to get started.

DSPs need to register with the UID2 Administrator to receive an authkey used to initialize the SDK. DSPs will contact The Trade Desk to gain approval until the system moves to independent governance.

The DSP does not need to worry about storing or managing decryption keys when using the SDK, but they will need to specify how often the SDK should fetch new decryption keys (recommended every 5 minutes).

Once initialized, DSPs can call the SDK at auction time to decrypt a UID2 token into a UID2. The SDK will return the UID2 along with a timestamp of when a user first established the UID2. The SDK will also notify the DSP if the UID2 token is expired.

If the SDK returns a UID2, the DSP can use the value to match audience data or conduct frequency capping.

Honor User Opt-Outs

When a DSP registers for UID2, they will need to establish a webhook or API endpoint to receive opt-outs from the UID2 Administrator. A webhook and API are methods used between two systems to send and receive data from each other, but webhooks are one-way where a service would set up a URL to only receive data from an application (UID2 Administrator).

The UID2 Administrator will send both the UID2 and the time the user opted out within seconds of the opt-out. An example webhook the UID2 Administrator would call could look like:

https://dsp.example.com/optout?user=%%identity%%&optouttime=%%timestamp%%

Where %%identity%% would be dynamically replaced with the UID2 and %%timestamp%% would be replaced by a UNIX timestamp of when the user opted-out. The DSP would then need to maintain a database that holds each UID2 and its associated opt-out time.

When DSPs decrypt UID2 tokens found in bid requests, they will receive an established_timestamp value that represents when the user established the UID2.

The DSP will need to check if established_timestamp is less than the timestamp of when the user opted out. If the established_timestamp is greater, the DSP can assume the user opted back in after opting out.

If the user opted out, the DSP should not use UID2 in their bidding logic.

How does UID2 work for Data Providers?

To target individuals utilizing the Unified ID 2.0 framework, data providers will need to push audience data based on UID2 to DSPs. Similar to how a data provider pushes data sets based on cookie or device IDs today, the DSP will match the UID2s in the pushed data sets to a UID2 present in incoming bid requests to target individual users.

Data providers will need to devise strategies to collect user email addresses to build data based on UID2. Once they collect user emails, they will need to:

1. Retrieve a UID2 for an email using the identity map endpoints

2. Send UID2 audiences to a DSP

3. Monitor for salt bucket rotations related to your stored UID2s

4. Use an incremental process to continuously update UID2s

Retrieve a UID2 for an email using the identity map endpoints

A UID2 Operator will host identity mapping API endpoints that data providers can call to retrieve a UID2 based on an email address. The API response will include both the UID2 and a salt bucket_id that rotates annually.

The bucket_id will remain the same even when the UID2 updates, but the data provider must store the bucket_id alongside the UID2 to properly check for UID2 updates (see step 3 below).

Send UID2 audiences to a DSP

The data provider can then use the UID2s they receive from a UID2 operator to build audience segments. They can then push the audience data constructed using UID2 for targeting in the DSP. If you are interested in learning more about this process, check out this article:

Monitor for salt bucket rotations related to your stored UID2s

Each UID2 is assigned a salt bucket_id that is an alphanumeric value between 1 and 1,000,000. Each bucket will have a secret salt. The salt is arbitrary data added onto the end of email addresses that ensures the resulting UID2 is secure.

A user’s UID2 will rotate at least once per year since its associated bucket_id will update its salt once per year, and it is unknown when exactly they may change in the year. For this reason, the UID2 documentation recommends checking for salt bucket rotation every day.

Data providers can call an API endpoint provided by a UID2 Operator that will return all salt buckets changed since a provided timestamp. Data providers can then check if any of the stored UID2s have an associated salt bucket that has been updated.

If the salt bucket for a UID2 is updated, the data provider must resend the email address to the identity mapping endpoint to obtain the new UID2.

Use an incremental process to continuously update UID2s

Data providers must continually check for salt bucket updates to obtain new UID2s. When a bucket updates, the data provider must update the UID2 in their database and push any changes to their DSP partners.

With each update, the data provider may want to let the old UID2 expire or specifically inform the DSP to delete a UID2 from a particular audience segment.

How does a user opt out of UID2?

The documentation mentions a Transparency and Control Portal where a user can opt-out of UID2 globally. The portal will notify the Unified ID 2.0 Administrator, and they will propagate the opt-outs to UID2 Operators and DSPs.

The opt-out will only prevent publishers from creating UID2 tokens or DSPs from using UID2 to bid. Users will need to contact advertisers directly to opt-out from a specific advertiser using their email for targeted advertising,

Criteo announced that they will co-develop the Transparency and Control Portal for Unified ID 2.0.

UID2 Overview

This post presented quite a bit of information, so it will be helpful to walk through a hypothetical UID2 journey to solidify our understanding.

1. Johnny User visits his favorite news site

2. Johnny is presented with a login prompt

Johnny reads three articles, but on his fourth article, the news website explains to ol’ Johnny that this content does not write itself. It takes time and effort from expert journalists to craft the stories Johnny enjoys.

The website explains that if Johnny registers using his email address, advertisers can deliver more relevant advertising and generate revenue for the website. The website can use this revenue to create more of the content Johnny loves.

“I love this website, and I sure am tired of seeing ads for weight loss pills,” Johnny thinks to himself as he admires his svelte athletic physique in the mirror. Johnny registers for the website and provides his email address.

3.  The news website then sends Johnny’s email to a UID2 Operator.

4. UID2 Operator returns the news website a UID2 token

5. The news website passes the UID2 token to the client-side SDK

Now the news website can call the SDK while Johnny is logged in. Johnny is logged in and continues to use the website.

6. Johnny loads the fourth article that contains ad slots

7. News website calls the client-side SDK for the UID2 token

8. Client-side SDK returns UID2 token

9. News Website calls their SSP for an ad and includes the UID2 token in the ad request

10. SSP initiates a bid request to the DSP that contains the UID2 token

Now the DSP will decrypt the UID2 token into a UID2 to match the identifier to audience data stored in the DSP.

11. DSP passes UID2 token to the RTB SDK

12. RTB SDK returns a decrypted UID2

13. DSP finds that Johnny’s UID2 is in a targeted “Ultra Athletic Males” audience segment

14a. DSP returns a bid response containing an ad for home gym equipment

14b. SSP returns a bid response containing the ad for home gym equipment

15. News website displays an ad for home gym equipment alongside Johnny’s fourth article.

Will users log in?

Users have enjoyed a mostly open and frictionless content browsing experience since the dawn of the Internet. Websites have made content freely available to all users, and even if those websites inundated users with ads, users mostly understood the tradeoff.

The value exchange was simple. Websites create and provide content to users in exchange for those users viewing ads. But now, the narrative has changed, and the story has grown more complex.

The onus is now on publishers to explain why they need an email address and how it powers the free and open web users appreciate. They will also need to explain how technologies like UID2 work — no easy task since it took me about 2,500 words to explain how it works to you.

Is it realistic to expect an everyday user to understand? Will users know what they are opting into? Will publishers annoy users into logging in without properly explaining the tradeoff?

Even if users understand, the number of addressable individuals on the web will drop precipitously. This drop will lead to several consequences:

1. Addressable users will become more valuable

The price of placing an ad will follow the principles of supply and demand. Assuming that the demand of advertisers targeting users using data stays unchanged or increases and the supply of users that advertisers can target with data decreases, the CPMs (price) will increase.

2. Alternate business models will gain popularity

Subscription-based business models will continue to gain popularity. Publishers will look for alternate revenue sources given the uncertainty of digital advertising on the web. If a publisher cannot convince users to log in, they will want to prepare for a future with decreased advertising revenue.

3. The overall quality of content will increase

To convince a user to log in, publishers will need to create a compelling value exchange by producing premium content.  Publishers will have to entice users to log in by gating premium content that entertains, informs, educates, and delights the user behind a login wall.

One thing is for sure, advertising on web-based media will change dramatically in the coming years. Digital advertisers can no longer rely on persistent identifiers like cookies and device IDs but will instead need to employ strategies that include UID2, contextual advertising, and the Google Privacy Sandbox.

Publishers will also need to implement strategies using these emerging concepts and weigh the pros/cons of pursuing a subscription-based content strategy that may or may not include advertising.

Subscribe to the Ad Tech Explained Newsletter

Ad Tech Explained provides explainers, insights, and analysis on the latest trends in advertising technology.

Photo by Maxim Hopman on Unsplash