Life After Third-Party Cookies: Evaluating Alternative ID Solutions for Publishers

On July 22, 2024, Google scrapped the retirement of third-party cookies in Chrome and replaced it with a user choice. Chrome will introduce an experience that lets users make an informed choice applicable to browsing, changeable at any time, rather than deprecating cookies outright. On October 17, 2025, Google confirmed that Chrome maintains this approach and announced the retirement of the Topics and Protected Audience APIs, citing low levels of adoption. Publishers that spent years preparing for a fixed deprecation date now face a slower and less predictable problem: identifier coverage that varies user by user and shrinks one choice at a time.

The reversal does not close the identity question. Safari and Firefox already block third-party cookies by default, so a mixed web exists today whatever Chrome users decide. The two Sandbox APIs built to replace interest targeting and remarketing are gone, which removes the option of waiting for Google to solve targeting on your behalf. What remains is an evaluation problem, and it belongs to mechanisms rather than vendor claims: deterministic email identifiers, person-based graph identifiers, publisher-owned first-party IDs, and identifier-free signals built on taxonomy segments. Each mechanism earns its complexity at a different combination of login rate, consent rate and demand recognition, and those three inputs decide the order in which you build.

What the Chrome reversal settles, and what it does not

Google's July 2024 update matters for two reasons. First, the direction flipped from a version sunset to a per-user decision, and a choice a user can change at any time produces coverage you cannot forecast the way you forecast a release date. Second, the October 17, 2025 confirmation retired the replacements: Topics fed interest signals into bid requests, Protected Audience carried on-device remarketing cohorts, and both APIs shut down because adoption stayed low. Publishers that deferred identity work while waiting on those APIs have nothing left to wait for.

The practical reading is narrower than "cookies are safe". Chrome's third-party cookies survive, but their coverage depends on choices individual users make in the browser, and those choices can change at any time. Add default blocking in Safari and Firefox and you get a web where identifier coverage is permanently partial, unknowable in advance and different for every site's audience mix. Treat coverage as a variable you measure, not a constant you assume.

Four mechanisms, judged by how they work

Prebid's User ID module is where most publishers meet this market, and it supports more than 20 different flavors of global IDs, per Prebid's identity overview. The consent behavior is common to every flavor: the User ID module reference states that the module skips vendor calls and ID storage without a TCF consent string or without Purpose 1 consent. Keep that rule in mind, because it caps every vendor's reach before any match rate matters. The differences between solutions sit in how the identifier is created, who can read it, and how long it survives.

Deterministic email identifiers: UID2

UID2 is a deterministic identity framework for the open internet. The project runs under Apache License 2.0, IAB Tech Lab holds the source code, and the Tech Lab Privacy and Rearc Commit Group governs development. Determinism is the mechanism: a user supplies an email at login, the framework derives identifiers from it, and buyers match against the same derivation, so the match points at a verified person rather than a probabilistic guess.

The decisive constraint sits in the Prebid integration. The UID2 module checks consent data and halts if gdprApplies is true, so the module does not operate where GDPR applies. A publisher with significant EEA traffic gets zero European reach from UID2 through Prebid, whatever its strengths elsewhere. A US-heavy site with meaningful login share gets the strongest signal in this list, because accuracy comes from verification rather than inference. The login rate is the ceiling either way: an identifier derived from email cannot exist for anonymous traffic, so measure authenticated sessions per geography before you write any integration code.

Person-based graph identifiers: RampID

RampID, formerly IdentityLink, is a single person-based identifier, and Prebid receives it as an encrypted identity envelope, encrypted with a rotating key. The mechanics carry three operational consequences. The envelope decays: Prebid guidance sets a 15-day TTL for GDPR and CCPA compliance, so envelopes past that window stop qualifying. The refresh cadence is 30 minutes, so the module needs a functioning refresh loop rather than a set-and-forget configuration. Decryption requires the buyer to hold the key, which concentrates value in demand partners inside the graph.

Evaluate it as a matching product, not a coverage product. A person-based identifier links devices and logins to one person, which suits advertisers buying cross-device frequency control and sequential messaging. The trade is operational: honor the TTL and the refresh guidance, and confirm that the demand you actually clear can decrypt the envelope. Where those conditions hold, person-based matching beats probabilistic cookies on accuracy. Where they do not, the envelope is payload without a reader.

Publisher-owned first-party identifiers

The vendorless path stores an ID in a first-party cookie under the publisher's own namespace, with sharedid as the canonical Prebid example. Prebid 9.0 moved vendorless modules such as sharedid to publisher purpose consent, which changes your obligations: the publisher, not a vendor, declares the processing purposes in the CMP, so consent configuration for these IDs is your configuration. The ID never travels for cross-site recognition, which limits its targeting value on the open market. It still does real work: frequency capping, audience analytics, subscriber modeling and internal segmentation all run on it, and direct buyers can key off it.

This is the baseline layer, not the performance layer. It works in every browser, survives every cookie policy because it rides your own domain, and costs nothing beyond consent setup and TTL policy. Its weakness is demand-side recognition: an anonymous exchange buyer cannot join a first-party namespace it has never seen. Treat it as infrastructure for your own operations and as raw input to curated segments.

Identifier-free signals: publisher provided signals and Curated Audiences

Publisher provided signals and seller-defined audiences, the standard now called Curated Audiences, let publishers ship first-party audience data as standardized taxonomy segments in OpenRTB without user IDs and without raw data leakage. The rename from Seller Defined Audiences to Curated Audiences landed in December 2024, and Google Ad Manager implements the mechanism as publisher provided signals. The mechanism is categorical: you declare that an impression belongs to "auto intenders" or "loyal finance readers" against a shared taxonomy, and the buy side targets the segment, never the person.

This is the only mechanism on the list that does not depend on identifier coverage. It performs identically in Safari, Firefox and Chrome, with or without third-party cookies, with or without logins, because nothing persists on the browser and no identifier is broadcast. The cost is data discipline rather than identity infrastructure: you need a defensible taxonomy mapping, segment definitions your editors apply consistently, and freshness rules so segments reflect current behavior. For publishers with strong first-party data and weak login rates, this layer usually carries the highest revenue per engineering hour.

The consent ceiling

Every mechanism above passes through one gate. Without a TCF consent string, or without Purpose 1 consent inside it, the module skips vendor calls and ID storage, which means your Purpose 1 consent rate is the ceiling on identifier reach for every vendor ID in your stack. That ceiling applies before you evaluate any match rate, any graph quality, any deterministic accuracy. Vendor-reported match rates describe the consented slice only, so multiply them by your consent rate and never take them at face value.

Two consequences follow. First, measure Purpose 1 consent by geography and by template, weekly, because the ceiling moves with CMP configuration, consent copy and region. Second, since Prebid 9.0 moved vendorless IDs to publisher purpose consent, you own the consent declaration for your first-party identifiers and inherit the consequences of it. A CMP that presents purposes poorly caps your own ID reach, and no vendor can fix that for you.

Testing lift: a protocol for sites above one million pageviews

Theory ends at the auction. A site above one million monthly pageviews has enough volume for a clean read, so run one before you pay for anything.

• Split traffic into a control slice with no ID module active and a treatment slice with the module enabled, and run it across a full weekly cycle so buyer pacing and daypart effects average out.
• Read bid density, clear rate and CPM on matched impressions only, because unmatched impressions dilute the denominator and hide real effects.
• Track page latency alongside revenue: each vendor call adds weight to the header, and the consent gate skips those calls on non-consented traffic rather than paying for dead requests.
• Reconcile vendor cost into the result and compute net CPM lift before any renewal, because an ID that adds gross CPM but adds more in fees and latency is a loss.

One auction caveat changes how you read those numbers. Identity raises bid density, and bid density changes first-price dynamics: auction mechanics and bid shading recalibrate when competition thickens, expected-value ranking reorders the field, and reserve prices interact with the new bid distribution. Re-check your floors after enabling any ID, not just your CPM.

We run this comparison on both paths because we integrate OpenRTB 2.6 seats and Prebid for header and server-side demand, so a publisher working with OnlyMedia can test client-side and server-side ID passthrough against identical demand. Server-side integration removes the latency objection for envelope refreshes, since the calls no longer sit in the page header. Match rate and CPM lift surface in the ten minute reporting console, and we pay Net 30 on a CPM basis with no sliding terms, so measured lift converts to cash within the same cycle rather than in a reconciliation months later.

Demand recognition: the half most audits skip

An identifier only has value when a buyer can act on it, and the mechanism determines the buyer set. Hashed email identifiers pay off with seats that buy against logged-in profiles. Encrypted envelopes pay off with buyers holding the key. Taxonomy segments pay off with any seat that targets standard taxonomies. The evaluation question is therefore not "which ID is best" but "which ID do my actual demand partners price".

Ask each partner two questions: which ID namespaces appear in your bid requests today, and what CPM lift did you attribute to them last quarter. A partner that cannot answer is telling you the ID is payload without a reader. On the buy side, demand that values identity concentrates around verified audiences and curated supply paths, so check where your curated demand actually prices before you fund an integration.

OnlyMedia runs an ad network, an SSP and an agency in one company, and we work with thousands of publishers, each above one million monthly pageviews, through a curated programmatic demand network that pays Net 30. That position puts both halves of the equation in one building: we see which IDs our seats price, and we see what publishers actually clear. Apply that lens wherever you test, with us or with anyone else: demand recognition decides whether an identity investment compounds or sits idle.

The stack that survives every scenario

Sequencing matters more than selection, because each layer has different prerequisites and different payback. The order for a publisher building this out now:

1. Instrument consent first. Measure the Purpose 1 consent rate by geography before any ID decision, because it caps every layer downstream.
2. Turn on a vendorless first-party ID with correct purpose declarations. It costs almost nothing, and it powers frequency capping and analytics even where buyers ignore it.
3. Add UID2 where logins exist and GDPR traffic is a small share of sessions, because the Prebid module halts wherever GDPR applies.
4. Add RampID where person-based cross-device matching fits your demand, and commit to the operational load: the 15-day TTL and the 30-minute refresh are compliance and functionality, not suggestions.
5. Ship Curated Audiences and publisher provided signals regardless of login rate, because this layer works under every browser scenario and monetizes data you already own.
6. Re-test every layer quarterly against a no-ID control, because coverage and consent move and last quarter's answer expires.

The third-party cookie did not die on a schedule, and it will not. It is narrowing by individual choice, browser by browser, at a pace no roadmap predicts. Publishers that measure their own consent rate, login rate and demand recognition, then build the layers those numbers support, will monetize the mixed web instead of waiting for it to resolve.