First-party data and the new IDs: UID2, RampID, MAIDs and more

When a cookie is missing, the ad ecosystem goes looking for another way to say this is the same person as before. The answers range from the very solid (you logged in with your email) to the very shaky (your phone model and IP address look familiar). Knowing which is which is the difference between a smart buyer and a gullible one.

A cookie is a stamp on your hand that washes off. A logged-in ID is more like a membership card with your name on it. A probabilistic ID is a bouncer saying you look like the guy who was here last Tuesday. All three get you recognised, but you would not bet the same money on each.

The data ladder: zero, first, second, third

First-party data became the prize because it is collected with a direct relationship, which usually makes consent clearer and the signal fresher. Publishers push readers to log in, and retailers build loyalty programmes, partly so they own an identity signal that does not depend on any browser's cookie policy.

Hashed emails and why they are not magic

The most common login-based signal is a hashed email. The email is normalised (lower-cased, spaces trimmed) and run through a one-way function like SHA-256, turning [email protected] into a long string of letters and numbers. Two companies that hashed the same email the same way get the same string and can match without swapping the raw address.

The shared ID landscape

Several companies turned hashed emails and other signals into shared identifiers that can travel through the bidstream. The most discussed are listed below. None of them is universal; buyers usually see a patchwork.

The two big techniques behind any identity graph are deterministic matching (two records share an exact key, such as the same hashed email) and probabilistic matching (records are linked because signals like IP address, device type and time of day make it likely they are the same person). Deterministic is more accurate but covers fewer people; probabilistic covers more but is wrong more often.

1. You visit two sites: You browse a shoe store, then read the news. Each site, and the ad tech on it, gives your browser its own ID in a cookie.
2. Different IDs for the same person: Cookie A and cookie B do not know they are the same browser. On their own, the shoe ad cannot follow you to the news site.
3. Cookie syncing joins them: Third-party cookies and cookie syncing let ad platforms swap IDs in the background, so A and B are matched. That is how retargeting works across the web.
4. Where cookies fail: Safari and Firefox restrict third-party cookies, and apps never had them. Chrome still allows them (Google dropped its plan to remove them), but many people still cannot be matched this way.
5. Logged-in IDs: When you log in, your email can be turned into a one-way hashed ID such as UID2. It is stable across sites that use it, and you can opt out.
6. Clean rooms: match without handing over data: In a data clean room, a retailer and a brand match their customer lists in a controlled space and only see aggregated results, never each other’s raw data.

Mobile: MAIDs and the ATT shock

Phones never relied on cookies. Apps used the Mobile advertising ID: IDFA on iOS and GAID on Android. In April 2021, with iOS 14.5, Apple introduced App Tracking Transparency (App Tracking Transparency), which requires apps to ask permission before accessing the IDFA for tracking. Many users say no, so on iOS the IDFA is now missing for a large share of traffic. Android still offers GAID, though users can delete it, and Google's own plans for Android privacy changed alongside the Chrome reversal.

ID bridging: the 2024 controversy

In 2024 trade press, researchers and buyers began scrutinising ID bridging. The practice attaches an ID observed in one environment (say, a Chrome cookie or a hashed email from a login elsewhere) to a request from an environment where that ID was not actually present (say, Safari with no cookie). Some sellers argued it was a legitimate way to restore addressability. Critics said bridged IDs were often not declared, so buyers could not tell whether an ID truly belonged to the person on the page.

• Frequency capping breaks if impressions are counted against the wrong person.
• Attribution gets polluted when conversions are credited to an ID that was guessed.
• Prices get inflated because addressable Safari inventory normally sells at a premium.
• Transparency suffered, which led to industry responses such as the IAB Tech Lab's guidance on declaring how an ID was generated and BidSwitch's ID Provenance Protocol in September 2024.

How to judge an ID

1. Ask how it was createdDeterministic from a login, probabilistic from device signals, or bridged from somewhere else?
2. Check consentWas the person asked, and does the ID carry their opt-out through the chain?
3. Measure match and accuracyCoverage is easy to claim; accuracy against a known truth set is harder and more important.
4. Watch for anomaliesOne ID on thousands of devices, or thousands of IDs on one IP address, is a red flag.