Alternative ID - Next Advertising Era
Alternative IDs are now the most widely used technology to replace 3rd party cookies. Let's find out what they are.
In H2 2024, Google Chrome will phase out 3rd party cookies. Interestingly, Google's browser is the last one still supporting them. Others like Safari, Edge, and Firefox, along with smaller browsers, have already stopped using 3rd party cookies for advertising. Apple's Safari holds a significant market share, with 49.5% in the U.S. mobile market and 30% in Europe. This is a user base that advertisers cannot afford to ignore.
With the end of 3rd party cookies, several key advertising functions stop to operate:
Interest-based targeting
Remarketing
Post-impression conversion tracking, and even post-click tracking is not in great shape
Alongside 3rd party cookies, Mobile Advertising IDs, which are fundamental for in-app advertising, are also disappearing.
The Ad Tech world had to quickly find an alternative solution: the alternative IDs.
What are Alternative IDs?
Alternative IDs, just like 3rd party cookies, are unique, pseudo anonymous identifiers for a user. They are stored in the browser and persist across different domains, potentially even across devices. When present, they seamlessly replace 3rd party cookies, allowing the use of the same advertising infrastructure. However, they share the same privacy issues as 3rd party cookies since they enable user identification and facilitate data sharing among various entities.
How Alternative IDs work?
There are three types of alternative IDs:
Statistical IDs: These are based on the ability to collect unique information from a user's browser. They do not uniquely identify a user, but allow for statistical identification. A key element in this type of ID is the user's IP address, although many other data points are collected. A GitHub project named CreepJS explores the weaknesses of browsers in preventing user fingerprinting. This open-source library uses various techniques, from extracting information from your user agent and collecting your IP address to launching a WebGL rendering on your graphic card to obtain a unique device identifier (A Device Identification Technique based on Remote GPU Fingerprinting).
Apple has introduced solutions that hide the user's IP address, and Google has announced plans to do the same. Both aim to limit fingerprinting solutions, but it seems like it will be an ongoing chase. Commercial fingerprinting libraries exist, like the one developed by FingerprintJS. Their open-source version provides 50% confidence on my browser (identifying me correctly half the time), but their commercial version claims 99.5% confidence, regardless of whether I use Chrome or Safari. The open-source project supercookie uses a technique based on favicons to create a unique user identifier, originating from a study by the University of Illinois titled "Tales of FAVICONS and Caches: Persistent Tracking in Modern Browsers."
Deterministic IDs: These are based on hashed personal data of the user, the most commonly used being email, with mobile numbers as an alternative. Hashing the personal data makes it indecipherable, but under GDPR, it is still considered pseudo-anonymized data and thus personal data that can be collected and shared only with the user's consent.
Mixed IDs: This is the most commonly used solution. When personal data is not available, the alternative ID is created using statistical methods. If personal data is available, deterministic methods are used. This approach allows for expanding the coverage and precision of the alternative ID.
Below is an explanatory diagram of the elements an alternative ID can collect.
Additionally, here is a list of elements that can be used to create an ID (note that this list is illustrative and not exhaustive).
IP address
MAC address
Hashed email (HEM), primarily used in the American and European markets
Hashed phone number (HPH), primarily used in the APAC market
Hashed home address
User agent string
ID for Vendor (IDFV) by Apple, a unique device identifier that is unique only to the app developer; an app developed by another company will have a different device identifier
First Party Cookie
Local Storage
Session Storage
Link decoration
How many alternative IDs are there on the market?
It's tough to give a precise count because new ones are introduced every day. To keep track, I personally consult Prebid's list of User ID modules. As of now, there are 36 Alternative IDs supported. The most used in the Western market are:
ID5 ID: developed by a European company
Lotame Panorama ID: created by the data provider of the same name
Liveramp Ramp ID: developed by the data collaboration platform also called Liveramp
Unified ID 2.0: an open-source standard from the DSP The TradeDesk
Handron ID by Audigent: developed by the data activation platform Audigent
Criteo ID for Adexchange: brought to market by Criteo
What are the limitations of Alternative IDs?
Alternative IDs run into two main issues due to their characteristics:
Lack of stability: A statistical alternative ID is by definition unstable, leading to errors in user identification and greatly reducing precision compared to 3rd party cookies.
Coverage: A deterministic alternative ID can only track users whose identity is known, domain by domain, as there's no way to share IDs across domains without 3rd party cookies. The identified users are a small subset of the total web user base.
Hybrid alternative IDs attempt to mitigate the above issues, but there's a third problem:
Interoperability. Alternative IDs are owned by their developers and aren't interoperable: the 'recipe' isn't revealed to others. This was also a problem for 3rd party cookies in their early days, which was excellently solved by Ad Exchanges. Universal ID 2.0 seeks to solve this issue, but only for deterministic IDs. The standard allows for interoperability and has so far been embraced by a long list of partners, ranging from publishers to DSPs, data providers, and clean rooms.
What to do to take advantage of Alternative IDs?
For both publishers and advertisers, leveraging first-party data is key—it's not just for navigating the world of alternative IDs. Having direct data, particularly email addresses, and integrating them into your web platform is critical. It's your starting line; without it, you're at a significant disadvantage.
For advertisers, the approach is pretty clear-cut. Your ad platforms will guide you on how to harness first-party data for targeting and tracking. It's about balancing user privacy with implementation—do it swiftly. Platforms like Meta Ads and Google Ads are prime starting points, especially with tools like Customer Email Lists. Get the basics down, then move on to more sophisticated tactics like Enhanced Conversion Tracking and Enhanced Bidding.
Publishers face a trickier landscape. Monetizing traffic means juggling multiple partnerships. Engage in conversations with your partners. If you're on Google Ad Manager, familiarize yourself with its offerings, such as PPID and Secure Signals, and then branch out to SSPs to incorporate their suggested alternative IDs. As you gain savvy, look to data providers for collaboration. A piece of advice: capitalize on the assets you already possess. If you're not yet proficient in collecting user emails, or if your database is poor, prioritize devising a strategy to bolster that collection. This foundational step is non-negotiable.
Previous Episode of: Next Advertising Era
Reading Suggestions
Be Data Literate by Jordan Morrow that is driving my professional choice
Present Beyond Measure: Design, Visualize, and Deliver Data Stories That Inspire Action by Lea Pica that is supporting my data storytelling
IAB Tech Lab Identity Solution guide from IAB to understand Alternative ID
Marketing in the messy middle Google's document to guide us through the Messy Middle, Mountain View's perspective on summarising the user's decision-making process.
IPA-PAM-ARA Comparison and Tradeoffs: This document contains the original comparison presented at TPAC. A working item from that was to create a steelman version for each proposal which we’ll do in this document: