WTF are shared identity solutions?

But exactly how do they work? Here’s a primer.

First, why all the hoo-ha around the need to create shared user IDs?
The concept of shared user IDs has been around for several years, but it’s getting more air time currently because of two rather pressing market trends: Apple Safari and Mozilla’s Firefox browsers culling third-party cookies, and the tightening of data-privacy laws, namely the General Data Protection Regulation and, in time, the California Consumer Privacy Act.

So these IDs are a cookie-less alternative for ad targeting and tracking?
Not quite. They are a third-party cookie-less option. But they rely very much on first-party cookies — audience data obtained directly from the publisher (rather than via a third party). It is the third-party cookie — not the first-party cookie — that is in on the hook. Not only have Apple and Mozzila blocked them, but the way third-party cookies also spread personal user information across the web in the name of buying and selling ads on the open exchange is massively problematic, and a huge GDPR compliance headache and likely violation. “The walls are closing in,” said Mathieu Roche, co-founder and CEO of shared ID provider ID5. “Both on the technical side with the browsers and on the legal side with [U.K. data protection regulator] the Information Commissioner’s Office.”

How do you create a digital identifier?
Typically, to create it from scratch a publisher can integrate via an ID provider’s API, which can be achieved via open-source Prebid. Once a person visits that publisher’s site and gives their consent (or rejects it) for that publisher and its digital ad partners to use their data for various purposes like ad targeting, those data preferences will be collected in the publisher’s consent management platform. Once the information is read by the CMP is is stored in a first-party cookie and passed to the ID provider’s API. There is still no ID yet, but the ID provider will know whether there is permission to create an ID for that user for the purpose of ad targeting. Not all ID solutions generate an ID only when they have user consent. Ones like ID5 do. An ID, which is a string of random numbers and letters (some call it a token), will then be generated for that user, which is shared back with the publisher for them to store in a first-party cookie on their site. All other digital partners are then given access to the same shared ID so supply-side and demand-side platforms can both read it.

Why is it important that it’s a shared ID?
The sheer volume of third-party cookies on an average publisher’s site is staggering. For mainstream, mass volume publishers that rely heavily on programmatic advertising, it’s an even bigger problem. Those millions of cookies all have to be matched in order to isolate an individual in order to target an ad to them. Currently, every website has its own way of identifying users, meaning every individual that goes online has hundreds of different third-party cookie-based IDs that then all have to be matched by SSPs and DSPs in order to target ads. That’s very expensive from a technical infrastructure point of view, and it causes other headaches like slowing page-load times, as well as the (now critical under GDPR) long-standing data leakage issue. “It means in future instead of having to have hundreds of thousands of cookies on their website, publishers can transact on one shared ID (per user),” said Jakob Bak, co-founder and CTO of Adform and member of shared ID consortium DigiTrust. “Where the user can be given a much stronger opt-out and ability to exercise their rights.”

And these don’t use third-party cookies at all?
Currently, most shared-ID solutions are compatible with third-party cookies (so the ID can be stored in a third-party cookie) because most of the ad tech ecosystem still operates on them, and they’re enabled in Google’s browser Chrome. But these shared IDs have been designed to work without them, so once the third-party cookie has finally died, these shared IDs will live on, using first-party cookies. “An ID is a key in a database,” said Roche. “It is the first bit of code that you can attach all you know about the user to, but it has to be unique. The purpose is for the same ID to be shared between publishers and brands — it has to be the same key. It is a common language for ad tech.”

There is more than one shared-ID solution?
Like any hot-button issues, there are hoards of opportunists touting they have an ID solution. But there are only a handful of shared-ID consortiums and businesses worth paying attention to and you can count them on one hand: DigiTrust, ID5, Ad Consortium. They’re working on shared versions, meaning the creation of one (anonymous) unified ID per individual that publishers and their programmatic ad partners can use to serve and target ads.

So, what are the drawbacks?
Mainly, the fact that pretty much the entire digital ad trading ecosystem works with the third-party cookie. The onus is on the publisher to get involved with the shared IDs also and prompt them to be created from their CMP data. Publishers that have log-in strategies can supplement these shared IDs with log-in data like email addresses in theory, but the scale doesn’t yet match that of third-party cookies.