In the pantheon of replacements for third-party cookies, Unified ID 2.0 (UID 2.0) is perhaps one of the best known. UID 2.0 quickly picked up support from a lot of players in the ad tech space, and is increasingly being adopted by publishers and agency groups too.
But for a while it wasn’t really clear exactly what UID 2.0 was, or how it would work. That’s because at the start it was a concept rather than a working tool – an upgrade to The Trade Desk’s original Unified ID, fit for the post-cookie world.
Since it was first announced last summer, UID 2.0 has undergone significant change. While the project was always open source, The Trade Desk has now formally passed it into the hands of industry group IAB Tech Lab and its Partnership for Responsible Addressable Media (PRAM) initiative. And full draft technical standards, outlining exactly how UID 2.0 works, have been developed.
Here’s how UID operates, as things currently stand:
The concept
Tech Lab emphasises that UID 2.0, like every other identity solution, isn’t a like-for-like replacement for the third-party cookie. It won’t just easily slot into the gap left by cookies as if nothing had ever changed. Tech Lab’s VP of privacy and data protection Alex Cone says instead it is one of a portfolio of solutions which together will govern addressability and measurement in the post-cookie world.
But UID 2.0 will facilitate many of cookies’ use cases. Cone says that UID 2.0, when available, will enable advertisers to:
-
Estimate cross-site/app reach
-
Manage frequency caps and control recency across digital properties
-
Create targetable audience segments
-
Attribute conversions and measure return on ad spend
-
Connect and analyse ad campaign details to user lifetime value
Cone classifies UID 2.0 as a ‘linked 1:1 audiences’ solution. This means advertisers and publishers can use it to connect their data, in order to match up information they each have about the same user. This stands in contrast to ‘unlinked 1st part audiences’ solutions, which allow advertisers and publishers to use their first-party data, but without the ability to match up their data sets.
UID 2.0 won’t handle data matching itself though, unlike a clean room solution. And it will be interoperable with commercial ID solutions, meaning it will connect with commercial ID solutions of a publisher or advertiser’s choice.
So while UID 2.0 isn’t a plug-and-play replacement for the cookie, it fulfils a fairly similar role, acting as a neutral piece of the puzzle which other players can use to facilitate targeting and measurement.
The blueprint
To achieve all this in a privacy-safe manner, the UID 2.0 set of standards have four key components.
The first is UID 2.0 itself, which much like a cookie is a random string of numbers and letters. It might look something like ‘ID1902338541’.
There are several major differences from cookies. Firstly the unified identifier will be created by one of a number of specifically chosen neutral ‘operators’, one of which will be industry body Prebid. Storage of UID 2.0 will be decentralised with advertisers and data providers storing the identifier, rather than it sitting on the user’s web browser.
The ID itself will also be encrypted and regularly changed (which occurs through a method called ‘salting’) to better protect privacy. And everyone who uses it must agree to a set of terms and conditions governing how it can be used, which isn’t the case with cookies.
The final big difference is that when UID 2.0 is generated, a piece of personally identifiable information (PII) is used as an input, for example an email address (the process of transforming the PII into a string of numbers and letters is called ‘hashing’). This allows it to recognise users across different websites, without being stored on the web browser.
The second component needed for UID 2.0 to work, a single sign-on interface, is responsible for collecting this piece of PII. This interface will ask users to consent to cross-site targeting and measurement. Users will be asked for consent just one time per each website and app which uses UID 2.0
The third part is a user consent framework, which ensures that a users’ consent preferences are passed to all the relevant players, without each company having to talk directly with each other. This ensures that a user’s preferences can be set on their iPhone, and passed across to an Android device they log in on, for example.
And the last component is the publisher consent framework, which governs how users are able to grant or withdraw consent to use of their data, without having to set their preferences multiple times across sites.
The play-by-play
How do all these pieces work in practice?
When a user visits a publisher website, mobile app, or CTV app for the first time, that publisher is responsible for collecting the authenticated PII, as well as their consent preferences.
The publisher then sends these bits of information to their chosen UID 2.0 operator, which uses them to generate the raw UID 2.0 itself. This is hashed and salted as described above.
The publisher doesn’t receive the UID itself, but rather an encrypted form of it called a UID 2.0 token. The operator encrypts the UID using an encryption key provided by the UID 2.0 Administrator service – which is just the centralised service that manages access to the UID 2.0 system. The publisher then passes this token on to the SSP whenever it has an impression to sell, and the SSP includes this UID 2.0 token in the bid request.
Meanwhile on the buy-side, demand-side platforms (DSPs) receive raw UID 2.0s from brand and data providers, who themselves have collected consented use of the same piece of PII from users.
The DSPs also get decryption keys from the UID 2.0 Administrator. Then, whenever it receives a bid request containing a UID 2.0 token, it can decrypt it in order to get the raw UID 2.0. This allows the DSP to then recognise which user the bid relates to, and to bid accordingly.
The DSP will also be told by the administrator whenever a user has opted out, and block use of the UID 2.0 accordingly.
Thus, when it all comes together, an advertiser remains able to recognise that a bid request relates to someone they themselves are familiar with, and overlay their data in order to adjust their bid accordingly. And they’re also able to recognise users across different websites, helping them to manage reach and frequency. But this happens without passing any personal information through the bid stream.
