Consent Mode v2 is often described as a switch that turns advertising tags on or off. It is not. It is a signaling layer that sits between your consent banner and Google’s tag infrastructure, and its job is to tell Google tags what they are allowed to do with storage and user data before those tags decide whether to fire, what to send, and what to suppress. The ad request itself is downstream of that decision. This article traces the path from the ad_storage flag to the cookieless ping to the modeled conversion, using Google’s own documentation as the primary artifact.

What Consent Mode v2 actually defines

Consent Mode was updated in November 2023 to add two parameters beyond the original ad_storage and analytics_storage. The four parameters Google documents are:

• ad_storage — allowed values 'granted' or 'denied'. Controls whether advertising cookies may be read or written.
• ad_user_data — allowed values 'granted' or 'denied'. Sets consent for sending user data related to advertising to Google.
• ad_personalization — allowed values 'granted' or 'denied'. Sets consent for personalized advertising.
• analytics_storage — allowed values 'granted' or 'denied'. Controls analytics cookie read/write.

That list comes directly from Google’s Set up consent mode on websites guide. The guide is explicit that ad_user_data and ad_personalization are the v2 additions, and that sites already using the original two parameters need to add them.

Two implementation details matter more than most teams realize. First, defaults must be set before any command that sends measurement data. Google’s example places gtag('consent', 'default', ...) ahead of the config call, and the guide warns that “if your consent code is called out of order, consent defaults won’t work.” Second, if your banner loads asynchronously, you can pass wait_for_update with a millisecond value so tags wait for the CMP to call gtag('consent', 'update', ...) before firing. Google’s example uses 500 ms.

Region scoping is also part of the spec. A default command can carry a region array using ISO 3166-2 codes, and the most specific region wins. Google’s own example sets ad_storage to granted for US and denied for US-CA, with the California visitor receiving the denied state.

What fires when ad_storage is denied

This is where the common mental model breaks. Denying ad_storage does not stop network requests to Google. It changes what those requests contain and what they are allowed to do.

Google Analytics’ Consent mode on websites and mobile apps page describes the behavior directly: “When visitors deny consent, instead of storing cookies, tags send pings to Google.” The same page enumerates the ping types:

• Consent state pings for Google Ads and Floodlight tags — communicate the default consent state and any update when the visitor grants or denies consent for each consent type. These are sent from each page where consent mode is enabled, and are also triggered for some tags when state changes from denied to granted.
• Key event pings — indicate that a key event has occurred.
• Google Analytics pings — sent from each page where GA is implemented, on load and when events are logged.

The documented payload of these pings is deliberately coarse. Google lists functional information such as timestamp, user agent, referrer, and headers added passively by the browser; coarse information such as whether the current or prior page in the navigation included ad-click information in the URL (GCLID/DCLID); boolean consent state; a random number generated on each page load; and information about the consent platform used, such as a Developer ID.

When ad_storage='denied', the documented behaviors are specific:

• No new advertising cookies may be written.
• No existing first-party advertising cookies may be read.
• Requests are sent through a different domain to avoid previously set third-party cookies being attached in request headers.
• Google Analytics will not read or write Google Ads cookies, and Google Signals will not accumulate data for that traffic.
• IP addresses are used to derive IP country but are never logged by Google Ads and Floodlight systems and are immediately deleted upon collection.

If ads_data_redaction='true' is also set, ad-click identifiers such as GCLID and DCLID in consent and key event pings are redacted. That is a separate flag from ad_storage and is configured via gtagSet in Tag Manager or the equivalent in gtag.js.

The practical consequence: a denied ad_storage state still produces a request to Google. It is a request stripped of cookie identity, stripped of persistent identifiers, and carrying only the coarse signals above. The ad request path is not severed; it is downgraded.

Basic versus advanced: the difference is whether tags load at all

Google’s documentation distinguishes two implementations. In basic consent mode, Google tags are blocked until the consent dialog appears and the user consents. In advanced consent mode, Google tags load before the consent dialog appears and send cookieless pings when consent is declined.

The tradeoff table in the Analytics documentation is blunt about the consequence. Advanced implementation enables behavioral modeling in Google Analytics, conversion modeling in Google Analytics, and conversion modeling in Ads. Basic implementation does not. The footnote is the part most teams miss: “When tags are blocked due to consent choices, no data is collected, and conversion modeling in Ads is based on a general model.” The models use features such as browser type, key event action type, time of day, and other high-level, non-identifying variables.

So the choice is not “do I want modeling or not.” It is “do I want modeling informed by my site’s cookieless pings, or modeling based on a general model that has no signal from my traffic.” Both are modeled. Only one is calibrated to your observed consent-denied population.

How modeled conversions are produced

The mechanism, as documented, is a gap-fill. Google Analytics receives cookieless pings from consent-denied traffic. Those pings carry coarse dimensions — user agent, screen resolution, IP address (used transiently, not logged by GA), and whatever fields the advertiser explicitly sets such as user_id and custom dimensions. Google then uses that data for behavioral and conversion modeling to fill gaps in observed data.

For Ads specifically, the Analytics documentation states that conversion modeling in Ads is available under advanced implementation, and that under basic implementation it falls back to a general model. The inputs to the general model are the high-level variables listed above. The inputs to the calibrated model are the cookieless pings plus those same high-level variables.

What the documentation does not provide is a formula, a coefficient, or a per-conversion confidence interval. Google does not publish the model architecture or the training data composition. Any vendor claiming to know the exact uplift from consent mode modeling is extrapolating from their own account data, not from a published specification. That distinction matters when someone presents a percentage as if it were a documented constant.

Where TCF v2.2 fits — and where it does not

Consent Mode v2 and IAB Europe’s Transparency & Consent Framework v2.2 are separate systems that often coexist on the same page. TCF v2.2, launched 16 May 2023 with an implementation deadline moved to 20 November 2023, is a framework for capturing and communicating consent signals across vendors. Its policy changes include removal of legitimate interest as a legal basis for advertising and content personalization purposes (3, 4, 5, and 6), standardized vendor disclosures, and requirements that users can easily resurface the CMP UI to withdraw consent.

The interaction that matters for this article is documented in Google’s Analytics consent page: “When your users deny consent with a consent solution that uses the TCF, Google Analytics properties aren’t able to model data to fill in the missing information.” That is a hard boundary. A TCF-based denial does not feed the same modeling pipeline that a Consent Mode denial does, at least not for Google Analytics properties.

On the OpenRTB side, the relevant fields are regs.ext.gdpr and user.ext.consent, which carry GDPR applicability and the TCF consent string respectively. Google’s Consent Mode signals are not the same artifact as a TCF consent string. They are Google’s own parameter set, transmitted through Google’s tag infrastructure. The mapping between the two is not a one-to-one translation, and Google’s documentation does not publish a field-level mapping table. Where behavior is undocumented, the honest answer is that it is undocumented.

What to check in your own implementation

Given the above, a few concrete checks follow from the documentation:

1. Verify default ordering. The gtag('consent', 'default', ...) call must precede config and any event command. Google’s guide states that out-of-order consent code causes defaults to fail.
2. Confirm all four parameters are set. Sites that implemented the original two-parameter version need to add ad_user_data and ad_personalization. The v2 upgrade note is explicit about this.
3. Decide basic versus advanced deliberately. If you block tags until consent, you are choosing the general model for Ads conversion modeling. If you load tags before consent, you are choosing the calibrated model. Neither is free; the first trades modeling fidelity for a stricter tag posture.
4. Check whether ads_data_redaction is set. It is a separate flag from ad_storage and changes what appears in consent and key event pings.
5. Check region scoping. If you set denied globally when only EEA visitors require it, you are suppressing measurement everywhere. Google’s guide recommends scoping defaults to the regions where banners are surfaced.
6. If you use a TCF-based CMP, understand the modeling boundary. Google’s documentation states GA properties cannot model data from TCF-based denials. That is a documented limitation, not a configuration error.

FAQ

Does denying ad_storage stop requests to Google?

No. Google’s documentation states that when consent is denied, tags send cookieless pings instead of storing cookies. The request path remains; the payload and storage behavior change.

What is the difference between ad_storage and ad_user_data?

ad_storage governs cookie read/write for advertising. ad_user_data governs whether user data related to advertising is sent to Google. They are separate parameters with separate allowed values, both added or confirmed in the November 2023 update.

Can I get modeled conversions without loading Google tags before consent?

Google’s documentation distinguishes advanced implementation (tags load before the dialog, cookieless pings sent) from basic implementation (tags blocked until consent). Under basic implementation, conversion modeling in Ads is based on a general model rather than one informed by your site’s pings.

Does a TCF v2.2 denial feed the same modeling pipeline as a Consent Mode denial?

For Google Analytics properties, no. Google’s documentation states that when users deny consent through a TCF-based solution, GA properties cannot model data to fill in the missing information.

Where does the consent state attach to the ad request?

Google’s documentation describes consent state pings sent from each page where consent mode is enabled, carrying the default and updated state for each consent type. The ad request itself is downstream of the tag’s decision about what it is permitted to send. Google does not publish a field-level mapping between Consent Mode parameters and OpenRTB fields such as user.ext.consent; that mapping is not documented in the sources reviewed here.

Primary sources

• Google, Set up consent mode on websites — parameter definitions, default/update commands, region scoping, wait_for_update, v2 upgrade note.
• Google, Consent mode on websites and mobile apps — ping types, ping payload contents, ad_storage='denied' behaviors, ads_data_redaction, basic vs. advanced tradeoffs, TCF modeling limitation.
• IAB Europe, TCF 2.2 Launches! All You Need To Know — policy changes, implementation timeline, GVL v3.

Sources not retrieved during research and therefore not cited for factual claims: Google Ads help page on conversion modeling (timeout), OpenRTB 2.6 specification on GitHub (HTTP error), Google Tag Platform developer guide on consent mode (HTTP error). Claims about those documents are not made here.

In February 2019, WebKit shipped Intelligent Tracking Prevention 2.1. The release notes describe two changes that, taken together, broke a class of measurement architecture that had been quietly standard for years: a seven-day expiry on persistent cookies written through document.cookie, and the removal of partitioned cookies for domains classified as cross-site trackers. The first change capped the lifetime of the identifier most client-side attribution vendors relied on. The second removed the fallback that had let those vendors keep a separate cookie jar per top-level site.

This is a mechanism-level account of what ITP 2.1 actually did, what it did not do, and why the CNAME cloaking crackdown that followed was a policy consequence rather than a separate technical feature. The primary sources are WebKit’s own release posts and its tracking prevention policy. Where behavior is undocumented, this article says so and stops.

What ITP 2.1 changed, in the exact words of the release

The ITP 2.1 post states the rule plainly: “With ITP 2.1, all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry.” The post gives three stated reasons: cross-site trackers were using first-party cookie jars for persistent tracking; cookies readable via document.cookie are exposed to speculative execution and cross-site scripting attacks; and cookie proliferation slows page loads.

The scope matters. The cap applies to persistent cookies created through the document.cookie API, in both first-party contexts and third-party iframes. It does not apply to session cookies, which remain session cookies. It does not apply to cookies set in HTTP responses. And it does not apply to cookies with an expiry shorter than seven days, which keep their shorter expiry.

The same release removed partitioned cookies for classified domains. ITP 1.0 had introduced partitioning as a compromise: a tracker’s cookies were isolated per top-level site rather than purged outright. ITP 2.0 removed the 24-hour cookie access window. ITP 2.1 removed partitioning entirely, so classified third parties “now have to use the Storage Access API to get any cookie access.”

Why the cap hit measurement specifically

Client-side attribution vendors had a standard pattern: a JavaScript tag on the publisher’s page writes an identifier into a first-party cookie via document.cookie, then reads it back on subsequent pageviews and on conversion pages. The identifier is first-party in name because it is set on the publisher’s registrable domain, but it is written by a third-party script. That is exactly the pattern ITP 2.1 targeted.

The seven-day cap means the identifier expires after seven days unless it is rewritten. Rewriting is possible on every pageview where the tag fires, so the practical effect is not that the identifier disappears after seven days of active browsing. The effect is that it cannot survive a gap of more than seven days without a pageview on a property where the tag fires. For a measurement window that spans a consideration period longer than a week, the identifier is gone.

WebKit’s stated rationale for the cap is explicit about the first-party cookie jar: “Say social.example writes a user tracking ID as a news.example first-party cookie. Now analytics.example, adnetwork.example, and video.example can leverage or cross pollinate that user tracking ID through their scripts on news.example.” The cap is a limit on how long any script-written identifier can persist, regardless of which script wrote it.

The CNAME cloaking problem

CNAME cloaking is a DNS-level workaround. A publisher creates a subdomain such as metrics.publisher.example and points it, via a CNAME record, at a third-party tracking vendor’s domain. The browser sees a request to a subdomain of the publisher’s registrable domain. Cookies set on that subdomain are first-party cookies by the browser’s default rules, because the registrable domain matches the top-level site.

WebKit’s tracking prevention policy defines a first party as “a website that a user is intentionally and knowingly visiting, as displayed by the URL field of the browser, and the set of resources on the web operated by the same organization.” It then states the operational test: “In practice, we consider resources to belong to the same party if they are part of the same registrable domain: a public suffix plus one additional label.”

That definition is the crackdown. A CNAME-cloaked subdomain is part of the publisher’s registrable domain, so under a naive reading it is first-party. But the policy’s definition of first party requires that the resources be “operated by the same organization” as the site the user is visiting. A subdomain that resolves to a third-party vendor’s infrastructure is not operated by the publisher in the sense the policy means. The policy does not name CNAME cloaking as a technique, but the definition of first party is the hook that makes it a circumvention.

The policy’s circumvention clause is unambiguous: “We treat circumvention of shipping anti-tracking measures with the same seriousness as exploitation of security vulnerabilities. If a party attempts to circumvent our tracking prevention methods, we may add additional restrictions without prior notice.” CNAME cloaking is a circumvention of the registrable-domain test, and the policy reserves the right to respond without notice.

What the policy does and does not promise

The policy lists “Measuring the effectiveness of advertising” and “Audience measurement” under “Unintended Impact” — practices WebKit does not intend to disrupt but which may be affected because they rely on techniques that can also be used for tracking. The policy states: “When faced with a tradeoff, we will typically prioritize user benefits over preserving current website practices.” It also states that WebKit “will try to limit unintended impact” and may “design and implement new web technologies to re-enable these practices without reintroducing tracking capabilities,” citing the Storage Access API and Private Click Measurement as examples.

That is the honest boundary of the primary sources. The policy commits to trying to limit unintended impact on measurement. It does not commit to preserving any specific measurement technique. It does not name CNAME cloaking. It does not specify how detection works at the network layer. WebKit’s public posts describe the classification model in general terms — on-device statistics, a machine learning classifier, vectors including subresource under number of unique domains, sub frame under number of unique domains, and number of unique domains redirected to — but they do not publish the CNAME detection logic. Any claim about the specific signals WebKit uses to identify a cloaked subdomain would be speculation, and this article does not make one.

The economic consequence, stated narrowly

The measurable consequence of ITP 2.1 is a hard ceiling on the lifetime of a script-written first-party identifier: seven days, with no partitioned fallback for classified domains. For any measurement method that depends on that identifier surviving a longer gap, the method fails in Safari. That is not a claim about how much revenue was lost or what percentage of conversions were affected. Those numbers would require data this article does not have. It is a claim about the mechanism: the identifier’s maximum lifetime is bounded, and the bound is enforced by the browser.

The CNAME crackdown is a policy consequence, not a separate release. Once WebKit defined first party by operation rather than by DNS, a cloaked subdomain became a circumvention target. The policy’s no-exceptions clause reinforces this: “We do not grant exceptions to our tracking prevention technologies to specific parties. Some parties might have valid uses for techniques that are also used for tracking. But WebKit often has no technical means to distinguish valid uses from tracking.”

What operators can actually verify

Three things are checkable against the primary sources without speculation:

1. Whether a cookie is set via document.cookie or via an HTTP response header. The ITP 2.1 cap applies only to the former. Authentication cookies set in HTTP responses with Secure and HttpOnly are not affected by the lifetime cap, as the release post states.
2. Whether a subdomain resolves via CNAME to a third-party domain. That is a DNS query, not a browser behavior, and it is observable.
3. Whether a domain has been classified by ITP. WebKit does not publish a list. The classification is on-device and algorithmic. The ITP 2.0 post states there is no whitelisting feature and no centralized blacklist.

What is not checkable from public sources is the exact detection logic for CNAME cloaking or the exact classifier weights. WebKit has not published those, and this article does not invent them.

FAQ

Does the seven-day cap apply to cookies set by the server?
No. The ITP 2.1 post states the cap applies to “persistent client-side cookies, i.e. persistent cookies created through document.cookie.” Cookies set in HTTP responses are not covered by this specific change.

Does the cap apply in first-party contexts?
Yes. The post states: “The change covers cookies created in first-party contexts as well as in third-party iframes.”

Does ITP treat subdomains as separate parties?
No. The ITP 2.0 FAQ states: “ITP captures statistics and applies its rules for the effective top-level domain plus one, or eTLD+1.” A subdomain of the publisher’s registrable domain is the same party under that test — which is why CNAME cloaking was possible in the first place, and why the policy’s operation-based definition of first party is the relevant counter.

Is there a whitelist for legitimate measurement domains?
No. The ITP 2.0 FAQ states: “Is there a way for users to whitelist my domain to be excepted from ITP’s rules? No, there is no such whitelisting feature.” The policy’s no-exceptions clause restates this.

What replaced the removed techniques?
The policy names the Storage Access API and Private Click Measurement as technologies designed to re-enable specific practices without reintroducing tracking capabilities. The Storage Access API requires user interaction with embedded content, as described in the ITP 2.0 post. Private Click Measurement is referenced in the policy but not detailed in the sources retrieved for this article.

Sources

• WebKit, “Intelligent Tracking Prevention” (June 5, 2017) — https://webkit.org/blog/7675/intelligent-tracking-prevention/
• WebKit, “Intelligent Tracking Prevention 2.0” (June 4, 2018) — https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/
• WebKit, “Intelligent Tracking Prevention 2.1” (February 21, 2019) — https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/
• WebKit, “Tracking Prevention Policy” — https://webkit.org/tracking-prevention-policy/
• W3C, “Tracking Preference Expression (DNT)” (Working Group Note, January 17, 2019) — https://www.w3.org/TR/tracking-dnt/

What Retargeting Is, Mechanically

Retargeting is the practice of serving ads to users who previously interacted with a site, app, or product catalog. The mechanism depends on a persistent identifier—a third-party cookie, a mobile advertising ID, a hashed email, or a first-party identifier—that lets a demand-side platform (DSP) recognize the same browser or device across publisher inventory. That identifier is matched against a retargeting audience, a list of users who fired a specific event: a product view, an add-to-cart, a checkout abandonment.

The economic premise is simple. Users who have already expressed intent convert at higher rates than cold traffic, so advertisers bid more for them. That higher bid should, in theory, win more auctions and produce cheaper conversions. In practice, the chain from event to impression has at least six links, and any one of them can break. This article traces that chain using primary-source artifacts—the IAB Tech Lab’s OpenRTB specification, the IAB Europe Transparency and Consent Framework, Google’s Ads and Privacy Sandbox documentation, and the public record of antitrust testimony—and identifies where retargeting fails.

The Retargeting Pipeline, Step by Step

1. Event capture and audience construction

A retargeting audience begins with a pixel, SDK, or server-side event. The advertiser’s site fires a request to the DSP or ad network, which records the user identifier and the event type. The DSP then adds that identifier to a segment. In OpenRTB 2.6, this segment is represented in the User.data object, where data.id names the data provider and data.segment[].id names the segment. The spec is explicit that segment IDs are provider-defined; there is no universal taxonomy. That means two platforms can both claim to target “cart abandoners” while using different definitions, lookback windows, and exclusion rules.

Failure mode: event loss. If the pixel does not fire—because of a consent blocker, a JavaScript error, a server-side timeout, or a browser that partitions storage—the user never enters the audience. The advertiser sees a smaller addressable pool and attributes the shortfall to “low match rates” without checking whether the event itself was recorded.

2. Identifier resolution and match rates

Once an audience exists, the DSP must recognize the same user on publisher inventory. This is the match rate problem. On the open web, the DSP compares its identifier (often a cookie) against identifiers available in the bid request. If the user’s browser has blocked third-party cookies, the DSP may fall back to a first-party identifier, a hashed email, or a probabilistic signal. Each fallback has different coverage and different error rates.

Google’s documentation for Privacy Sandbox APIs describes how Protected Audience (formerly FLEDGE) moves audience matching into the browser: the browser stores interest groups and runs an on-device auction. That changes the failure surface. Instead of a server-side cookie match, the browser decides whether the user is in an interest group and whether to generate a bid. If the interest group is not present—because the user cleared storage, used a different browser profile, or never visited the advertiser’s site in that browser—the retargeting ad cannot be served, regardless of the advertiser’s bid.

Failure mode: identifier mismatch. The advertiser’s CRM says the user is a high-value cart abandoner. The bid request carries no identifier the DSP can resolve. The impression goes to a cold audience or not at all.

3. Consent and legal basis

In the European Economic Area and the UK, retargeting depends on a legal basis for processing personal data. The IAB Europe Transparency and Consent Framework (TCF) v2.2 defines how consent signals are encoded and transmitted in the bid stream. Under TCF, a vendor must have a registered purpose and legal basis to use data for advertising. If the user denies consent for purpose 1 (store and/or access information on a device) or purpose 4 (select personalised ads), the DSP should not use the identifier for retargeting.

The failure here is not technical but procedural. A DSP may receive a bid request with a TCF string that indicates consent is absent, yet still bid if its configuration does not enforce the signal. Conversely, a publisher may pass a consent string that is technically valid but does not cover the specific vendor. The result is either non-delivery (the compliant case) or delivery without a valid basis (the enforcement case). Both look like “retargeting doesn’t work” to the advertiser, but only one is a legal risk.

4. Auction dynamics and bid shading

When the DSP decides to bid, it submits a bid price. On many exchanges, the auction is first-price, meaning the winner pays the amount they bid. To avoid overpaying, DSPs use bid shading: they estimate the market clearing price and bid below their true valuation. The algorithm is proprietary, but the economic consequence is documented in exchange and DSP materials: shading reduces the effective bid for retargeted users, which can cause the DSP to lose auctions it would have won at its unshaded valuation.

Failure mode: shading error. If the shading model overestimates the clearing price, the DSP bids too low and loses. If it underestimates, the DSP overpays. Retargeting campaigns are especially sensitive because the advertiser’s willingness to pay is high; a shading model trained on cold traffic may systematically underbid for retargeted users.

5. Frequency capping and creative fatigue

Retargeting audiences are small relative to cold audiences. A user who abandoned a cart may see the same ad dozens of times across publishers. Frequency capping is supposed to limit this, but caps are often set per campaign, per device, or per exchange, not per user across all channels. The result is over-delivery to a narrow pool, declining click-through rates, and rising cost per acquisition.

Failure mode: saturation. The audience is not exhausted in the sense of having no users left; it is exhausted in the sense that the users who remain are unresponsive. The advertiser blames the creative or the audience definition, but the mechanism is frequency.

6. Measurement and attribution

Finally, the advertiser must attribute conversions to retargeting. This is where the chain is most fragile. If the conversion pixel fires on a different device or browser than the ad impression, the attribution system may not connect them. If the advertiser uses a last-click model, retargeting gets credit for conversions that would have happened anyway. If the advertiser uses a view-through window, the credit may be overstated.

Failure mode: misattribution. The campaign appears to fail because the measurement system cannot see the conversions it caused, or it appears to succeed because it takes credit for organic demand. Neither is a mechanism failure in the ad serving path, but both determine whether retargeting is judged to work.

Why Retargeting Fails: A Diagnostic Framework

When a retargeting campaign underperforms, the cause is usually one of the six links above. The diagnostic order matters because fixing a downstream link will not help if an upstream link is broken.

1. Check event capture first. Verify that the pixel or SDK fires on the intended pages and that the event reaches the DSP. Use the DSP’s audience size as a proxy: if the audience is smaller than expected, the problem is upstream.
2. Check match rates. Ask the DSP for match rate reporting by identifier type. If third-party cookie match rates are low, test first-party or hashed-email alternatives.
3. Check consent enforcement. In regulated regions, confirm that the DSP is reading TCF signals and that the publisher’s consent string covers the vendor. Non-delivery may be compliance working as intended.
4. Check bid shading. Compare the DSP’s win rate for retargeting versus prospecting. A low win rate at a high bid suggests shading is too aggressive.
5. Check frequency. Pull frequency distribution reports. If a small share of users receives a large share of impressions, the cap is not working across channels.
6. Check attribution. Run a holdout or incrementality test. If the conversion rate for the retargeted group is not higher than a matched control, the campaign may be harvesting demand rather than creating it.

What the Primary Sources Actually Say

The OpenRTB 2.6 specification, maintained by IAB Tech Lab, defines the data structures but does not mandate how DSPs use them. The TCF v2.2 policy defines consent encoding but leaves enforcement to vendors and regulators. Google’s Privacy Sandbox documentation describes the Protected Audience API but notes that it is subject to change and that availability varies by region. None of these sources promises that retargeting will work; they define the interfaces through which it might work.

Where behavior is undocumented, say so. For example, the exact bid shading algorithm used by a given DSP is not public. The exact match rate for a given identifier type in a given geography is not public. The exact frequency cap enforcement across exchanges is not public. These are gaps, not conspiracies. The practical response is to measure what can be measured and to treat vendor claims as hypotheses to be tested against observed delivery.

FAQ

Why does my retargeting audience size keep shrinking?

Audience shrinkage usually comes from three sources: event loss (the pixel or SDK is not firing), identifier loss (users are clearing cookies or using browsers that block third-party storage), and consent loss (users in regulated regions are denying consent for advertising purposes). Check the event capture first, then match rates, then consent signals.

Is retargeting still possible without third-party cookies?

Yes, but the mechanism changes. First-party identifiers, hashed emails, and on-device APIs like Protected Audience can support retargeting without third-party cookies. Each has different coverage and different failure modes. The advertiser’s job is to understand which identifier is being used and what its match rate is in the relevant geography.

Why do retargeting campaigns sometimes show high click-through rates but low conversion rates?

High click-through with low conversion often indicates that the audience is being served ads after the purchase decision is already made, or that the creative is attracting clicks from users who are not actually in the market. It can also indicate attribution mismatch: the conversion is happening on a different device or is being counted by a different system. Check the audience definition and the attribution window before changing the creative.

What is bid shading and how does it affect retargeting?

Bid shading is a DSP technique for estimating the market clearing price and bidding below the advertiser’s maximum willingness to pay. It reduces overpayment in first-price auctions. For retargeting, where willingness to pay is high, aggressive shading can cause the DSP to lose auctions it should win. The shading algorithm is proprietary, so the advertiser cannot inspect it directly; the practical check is win rate and cost per acquisition by audience segment.

What to Do Next

Retargeting is not a single system; it is a chain of systems, each with its own documentation and its own failure modes. The next time a retargeting campaign underperforms, resist the urge to change the creative first. Trace the chain: event capture, identifier resolution, consent, auction, frequency, attribution. Fix the earliest broken link. If the chain is intact and the campaign still fails, the problem may be that the audience was never going to convert—and that is a targeting problem, not a delivery problem.

For a follow-up, consider a post on how incrementality testing works for retargeting, or a glossary of OpenRTB fields that matter for audience targeting. Both would extend the site’s coverage of mechanism-level explainers.

Retargeting is a two-step identifier pipeline, not a strategy. Step one: a tag on an advertiser’s site writes a visitor into an audience list keyed to an ad platform’s identifier. Step two: when that identifier reappears in an exchange auction, the platform reads the list and lets the advertiser bid on the impression. Everything else people associate with retargeting — the shoe ads that follow you around, the frequency caps, the CPM premiums — falls out of those two steps.

On Google’s stack, the named system is Google Ads remarketing: the list machinery behind the Google tag (gtag.js), the DoubleClick IDE cookie, and the Ad Exchange auction where the list gets read. Its neighbors matter just as much to the mechanism — Remarketing Lists for Search Ads (RLSA) on the search side, OpenRTB 2.6’s user-sync mechanics for third-party DSPs, TCF v2.2’s consent gates, and Protected Audience as the designated successor. This post traces the pipeline from those artifacts to the auction, then works through the five failure points I keep finding in production audits. In practice, retargeting fails for mechanical reasons, not creative ones.

The write path: how a list gets built

Google’s documentation calls the feature “remarketing”; the rest of the industry says “retargeting.” Same mechanism. The write path has three components: a tag, an identifier, and a list definition.

The tag is the Google tag, which replaced the legacy conversion.js tag that carried a google_remarketing_only flag. It fires on every page where it is installed and associates the browser with the advertiser’s conversion ID — the AW-xxxxxxx number.

The identifier is where the pipeline gets fragile: on browsers that accept third-party cookies, the association rides on the IDE cookie set in the doubleclick.net domain. The conversion linker also writes first-party _gcl_* cookies (such as _gcl_dc) that carry DoubleClick click identifiers — useful for measurement, and I’ll come back to why they don’t rescue the read side.

The list definition lives in Google Ads’ Audience Manager. Rules can be URL-based (“all visitors to pages containing /pricing”), event-based, or feed-driven for dynamic remarketing, which requires a Merchant Center feed. Three documented parameters, per Google’s help documentation:

• Membership duration: defaults to 30 days, configurable from 1 to 540 days for display remarketing lists.
• Minimum list size: display lists need roughly 1,000 members before ads can serve.
• The personalization off-switch: setting allow_ad_personalization_signals to false in the tag config stops remarketing collection while keeping measurement.

Two adjacent write paths skip the cookie. Customer Match accepts SHA-256-hashed email uploads, and GA4 audience exports push analytics-defined segments into Google Ads once the accounts are linked. Both carry their own failure modes — Customer Match match rates are invisible to the advertiser, and GA4 exports have a populate step that can sit in a half-linked state without throwing an error.

One thing the documentation does not specify: how Google deduplicates a person across browsers or devices for list membership. I can’t find a primary source that says it does. Treat any cross-device continuity claim from a vendor as unverified.

The read path: how the list is matched at auction

When a display impression comes up for auction — typically Google Ad Manager inventory sold through Ad Exchange — the exchange inspects the identifiers attached to the request. On Google’s own stack the read is trivial: AdX set the IDE cookie, so AdX can read it. No synchronization step, no leakage. That structural advantage is not something a roadmap can buy — Google’s list machinery and Google’s exchange share an identifier that is first-party to both of them.

A third-party DSP retargeting the same user has to sync. The user-sync section of the OpenRTB 2.6 spec describes how: the exchange calls the bidder’s sync endpoint, passing its own user ID along with the gdpr and gdpr_consent parameters that carry TCF consent state. The bidder returns a pixel or redirect that pairs its ID with the exchange’s ID. Every hop is a chance for the pair to fail — syncs get blocked, dropped, or consented out. Retargeting through a third-party DSP is a strictly lossier version of the same mechanism, and the losses compound per intermediary.

The auction itself changed shape when Google moved Ad Manager and AdX to a unified first-price auction, announced in late 2019 and rolled out through 2020. For retargeting this matters economically: many advertisers bid on the same small cookie pool, and in a first-price auction the winner pays its own shaded bid. Bid shading on the buyer side — the subject of an earlier mechanism piece on this site — decides how much of the retargeting premium you actually pay. The consequence is predictable: retargeting segments clear among the highest CPMs in display, because the pool is small, the intent signal is visible to every bidder, and the auction extracts what the signal is worth.

Why retargeting fails: five failure points, traced

1. Consent gates sit upstream of the cookie

Under TCF v2.2, which IAB Europe published in August 2023, personalized ad selection requires consent for Purpose 1 (store and access information on a device) and Purpose 4 (use profiles to select personalized advertising). The v2.2 revision removed the legitimate-interest basis for Purposes 3 through 8 outright, so there is no LI fallback for retargeting anymore. A consent management platform that fires late, mis-encodes the consent string, or applies the wrong regional rule will silently zero out list writes for entire geographies.

Google’s own consent plumbing is Consent Mode v2, with the signals ad_storage, ad_user_data, and ad_personalization. Google’s documented deadline was March 2024 for keeping measurement features on EEA traffic. The documented behavior under denied ad_storage is a cookieless ping used for conversion modeling. What the documentation does not describe is any modeled equivalent for remarketing list membership — as far as I can find, denied consent means the member simply isn’t added. If you’ve observed otherwise in server logs, I’d like to hear about it, because Google hasn’t published it.

The regulator’s paper trail is instructive here: the CNIL’s January 2021 decision fined Google a combined 150 million euros over cookies set without valid consent, and Google committed to capping the IDE cookie at 13 months in the EEA and requiring prior consent. The failure signature of a consent problem is regional — list accrual stalls for EEA traffic while other geographies grow normally. Check the CMP’s consent-rate dashboard by region before touching the tag.

2. Third-party cookie loss breaks the read side

Safari has blocked third-party cookies outright since March 2020 (Safari 13.1), and Firefox’s Enhanced Tracking Protection blocks doubleclick.net by default via the Disconnect list. No IDE cookie means no AdX read-side match for those browsers. The conversion linker’s first-party _gcl_* cookies help Google attribute clicks and conversions, but they live on the advertiser’s domain — AdX has no way to read them when the auction happens on a publisher’s page. First-party storage fixes measurement; it does not fix bid-time matching.

Chrome was the open question for five years. The January 2020 Chromium announcement declared third-party cookies would be deprecated; the July 2024 plan replaced deprecation with a user-choice screen; and in April 2025 Chrome’s Privacy Sandbox team reversed course again, keeping the current third-party cookie approach and scrapping the standalone opt-in. The practical consequence for retargeting: Chrome traffic remains matchable, Safari and Firefox do not, and no one outside Google can tell you the effective match rate inside AdX — Google does not publish it. I looked; it isn’t in the documentation. Measure your own browser mix in analytics and treat that as your reachable ceiling.

3. List floors and membership decay

Google’s help documentation states display remarketing lists need about 1,000 members before serving. The search-side figure has moved across documentation versions, so pin it against the live help page before you model anything. The floor interacts with membership duration in a way that surprises low-traffic advertisers.

Worked example: a B2B site with 60 qualified visits a day and the default 30-day list holds a theoretical pool of about 1,800 members. Subtract the share on Safari and Firefox, the share that declined consent, and the tag fires that happen before the CMP resolves, and the effective pool can sit right at the floor — serving intermittently, with impression share that looks like a bid problem but isn’t. The fix is arithmetic, not bids: lengthen membership duration toward the documented 540-day ceiling, or widen the rule.

The inverse failure is a mismatch between the list window and the purchase cycle. A 90-day enterprise buying cycle against a 30-day default list means members decay before they buy, and the campaign reads as “retargeting doesn’t work” when the list simply expired. Set membership duration from your measured conversion lag, not from the default.

4. Nothing suppresses converters by default

The tag keeps writing members after they buy. “Why am I still seeing ads for the thing I already purchased” is, mechanically, a missing exclusion list: the advertiser never wired the purchase event to a converted-users audience and excluded it from the campaign. Google’s help text tells you to build that exclusion; the machinery will not do it for you. Dynamic remarketing makes the failure more visible because the creative pulls the exact product from the feed — nothing advertises a dead segment like showing the purchased item at full frequency for another 30 days.

5. The incrementality illusion

Retargeting pools consist of people who already signaled intent, which is precisely why platform-reported conversions look so good on them. The field experiments run by Johnson, Lewis, and Nubbemeyer on a large apparel retailer’s retargeting program are the reference point here: measurable lift concentrated among users whose prior engagement was shallow, while deeply engaged users bought whether or not they were retargeted. Paying first-price auction premiums to re-reach people who were converting anyway is the quiet failure — the reports stay green, the economics don’t.

The honest check is a holdout: withhold a slice of the list from ads for a window and compare. Most accounts never run one, which is why the retargeting premium persists.

A diagnostic checklist mapped to the five failure points

• List accrual (floors, decay): in Audience Manager, capture the daily member count for two weeks. A flat line means a write-path problem, not an auction problem.
• Tag firing (write path): use Tag Assistant on a consented browser; confirm the tag fires after the CMP resolves and that ad_storage and ad_personalization read “granted” in the debugger.
• Consent rates by region (consent gates): pull the CMP dashboard for EEA versus non-EEA before blaming the creative.
• Browser mix (cookie loss): compare Safari and Firefox share in analytics against what the campaign could plausibly reach.
• Duration versus cycle (decay): set membership duration from measured conversion lag; the 30-day default is a default, not a recommendation.
• Exclusion lists (suppression): verify a converted-users list exists, is populating, and is attached as a campaign exclusion.

Where the mechanism is heading

Google’s designated successor for the cookie-based read side is Protected Audience (formerly FLEDGE): interest-group membership stored on the device, the retargeting auction run inside the browser with the advertiser’s cached creative and bid logic, and no bid-time user identifier exposed to the exchange. The write path becomes an explicit joinAdInterestGroup call; the read path becomes an on-device auction. With Chrome’s April 2025 decision to keep third-party cookies, the old mechanism and its successor will coexist indefinitely, and advertisers get to maintain both.

That coexistence is the next post in this series: tracing Protected Audience’s on-device auction from its explainer documents to what it does to retargeting economics — and to the parts its documentation declines to specify. If a retargeting setup behaves oddly, the three artifacts I’d want first are the tag debugger output, the CMP’s consent state, and the audience’s daily member counts. Bring those, and the failure point usually identifies itself.

Frequently asked questions

What is the minimum list size for Google Ads remarketing?

Google’s help documentation states display remarketing lists need roughly 1,000 members before ads can serve. The search-side figure has shifted across documentation versions, so pin the current number against the live help page rather than a blog post — including this one.

Does retargeting still work in the EEA after TCF v2.2 and Consent Mode v2?

Yes, conditionally: it requires consent for TCF Purpose 1 and Purpose 4, and Google Consent Mode v2 signals (ad_storage, ad_user_data, ad_personalization) set to granted. Google documents conversion modeling under denied consent; it does not document a modeled equivalent for list membership, so denied consent means no list write.

Why do retargeting ads keep showing after a purchase?

Because nothing in the default mechanism suppresses converters. The tag continues writing list members after conversion. The documented fix is an exclusion: build a converted-users audience from the purchase event and attach it as a campaign exclusion.

How long does a remarketing list keep a member?

Membership duration defaults to 30 days and can be set from 1 to 540 days for display lists, per Google’s help documentation. Set it from your measured conversion lag rather than the default.

Does retargeting work without third-party cookies?

Partially. First-party cookies set by the Google tag support measurement, but bid-time matching on third-party inventory still depends on the IDE cookie, which Safari and Firefox block. The cookieless alternatives are Customer Match (hashed email uploads) and, where deployed, Protected Audience’s on-device interest groups.