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/

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.

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.

Here’s a bid response log line most Google Ads advertisers will never see. It comes from a low-budget campaign targeting the query “plumber emergency [city name]” at a max CPC of $0.85. The campaign has three ads, a landing page with a 92 PageSpeed score, and a historical CTR of 3.1% on closely matched queries. The advertiser has budgeted $40/day. The log shows zero impressions over a 72-hour window. No policy violation. No disapproval. No bid adjustment. The campaign is simply not entering the auction.

The reason is buried in a mechanism that Google’s documentation names but never quantifies: Ad Rank thresholds. These are minimum quality and bid requirements that act as a pre-auction filter, applied before the generalized second-price auction logic executes. They are not floors you can see in your account. They are not reported in auction insights. They do not appear in any diagnostic tab. But they determine whether your bid is even considered—and for a meaningful subset of advertisers, they are the single most important variable governing whether their campaigns can compete at all.

The Two-Stage Filter: What Ad Rank Thresholds Actually Are

Google’s public documentation describes Ad Rank as a function of bid, auction-time ad quality, the context of the search, and the expected impact of ad extensions and formats. What it does not emphasize is that Ad Rank is computed in two stages. The first stage is a gate, not a ranking.

Stage one is the threshold check. Before your Ad Rank score is compared against other advertisers, it must exceed a minimum threshold that Google sets per query context. This threshold is not a single number. It is a composite of two floors: a quality floor and a bid floor, both of which scale with the query’s competitive context.

Stage two is the auction itself—the familiar comparison of Ad Rank scores among all advertisers who passed the threshold. The second-price mechanic, the actual CPC calculation, the ad position assignment—none of that runs until the threshold filter has already narrowed the field.

The economic consequence: thresholds do not just raise prices. They reshape which advertisers can compete at all. A campaign that fails the threshold never enters the auction, never gets a chance to be outbid, and never generates an impression that would show up in diagnostic data. The advertiser sees zero impressions and has no signal explaining why.

The Quality Floor: Context-Dependent, Not Absolute

The quality component of the Ad Rank threshold is the more opaque of the two floors. Google has stated that ad quality in the threshold context incorporates expected click-through rate, ad relevance, and landing page experience—the same three factors that compose the visible Quality Score metric. But the threshold is not a fixed quality bar. It scales with the query context.

Consider two queries: “what is a sump pump” and “emergency plumber near me.” The first is informational. It has low commercial intent, few advertisers competing, and Google typically serves it with a Featured Snippet or an AI Overview rather than a full ad block. The quality threshold for that query is low because the competitive context is thin—Google needs advertisers to fill ad slots and has little reason to exclude marginal participants.

The second query is high-commerciality, high-competition. Multiple advertisers are bidding aggressively. Google’s ad load experiments have determined that showing fewer, higher-quality ads produces better user experience and higher revenue per impression for this query class. The quality threshold is set higher. A campaign with a 3.1% historical CTR and a passable landing page might clear the threshold on the informational query but fail it on the commercial one.

The threshold also scales with competitor density. If ten advertisers are competing for a query and eight of them have strong quality scores, Google can afford to set the threshold high enough to exclude the bottom two. If only two advertisers are competing, the threshold drops—Google would rather show two ads, even if both are marginal, than show none and cede the slot to organic results.

This is why the same campaign can appear for some queries and not others, even when the keyword match type and bid are identical. The threshold is not a property of the campaign. It is a property of the query context that the campaign is attempting to enter.

The Bid Floor: Where Smart Bidding Interacts

The second component of the threshold is a bid floor. This is not the same as the minimum bid that Google reports in the keyword status column. That number—typically $0.01 or a similar nominal value—is a policy floor. The threshold bid floor is higher, dynamic, and invisible.

The evidence for this point is grounded in Federal Reserve Bank of St. Louis, which keeps the article’s claims tied to outside reference material rather than product framing.

For manual CPC campaigns, the bid floor is roughly the minimum bid required for the campaign’s Ad Rank to exceed the quality-adjusted threshold. If the quality component of your Ad Rank is low, the bid floor rises. If your quality is high, the bid floor falls. This is why two advertisers with the same max CPC can have different outcomes—one clears the threshold because higher quality reduces the bid required, while the other fails because lower quality raises it.

For Smart Bidding campaigns, the interaction is more complex. Smart Bidding—Target CPA, Target ROAS, Maximize Conversions—uses a value model to set auction-time bids. The value model predicts the expected conversion value of the impression and sets the bid accordingly. But the threshold still applies. If the value model’s predicted bid falls below the threshold bid floor for that query context, the campaign does not enter the auction.

This creates a particular failure mode for Smart Bidding campaigns with low conversion volume. The value model needs data to produce accurate predictions. Low-volume campaigns have noisy value models. Noisy value models produce conservative bid predictions—particularly for queries that are adjacent to but not exactly matching the campaign’s historical converting queries. The conservative prediction falls below the threshold, the campaign is excluded from the auction, the campaign gets no data from that query, and the value model never learns. A feedback loop: low volume produces low predictions, low predictions fail the threshold, failed thresholds prevent data collection, and the campaign stagnates.

A Concrete Scenario: The $40/Day Plumber Campaign

Return to the opening example. The emergency plumber campaign has a max CPC of $0.85, a Quality Score of 5/10, and a daily budget of $40. The query “plumber emergency [city name]” has an average CPC of $4.20 in the top position, with six advertisers consistently appearing in the ad block.

Here is what happens at auction time:

1. The user query enters Google’s query processing pipeline. Query classification identifies it as high-commerciality, high-competition, local-intent.

2. The system retrieves the Ad Rank threshold for this query context. The threshold is set high because six strong advertisers are competing and Google’s ad load optimization has determined that showing four high-quality ads produces better revenue than showing six marginal ones.

3. The plumber campaign’s Ad Rank is computed. The bid component is $0.85. The quality component is moderate—the landing page is fast, the ad text is relevant, but the historical CTR is below the query class average. The combined Ad Rank is below the threshold.

4. The campaign is excluded from the auction. No bid is submitted. No impression is recorded. No diagnostic is generated.

5. The advertiser sees zero impressions in the campaign report. The keyword status shows “eligible.” The bid strategy tab suggests no changes. The auction insights report shows no data because the campaign never entered an auction to be compared against competitors.

The advertiser’s likely response is to raise the bid. But raising the bid to $2.00 may still fail the threshold if the quality component remains low. Raising it to $5.00 might clear the threshold but would exhaust the $40 daily budget in eight clicks, producing insufficient conversion data for Smart Bidding to optimize. The advertiser is caught between a threshold that demands either higher quality or higher bid, and a budget that cannot sustain the bid level required.

This is the minimum viable campaign budget problem. It is not a marketing concept—it is a structural property of the threshold mechanism. For any given query class, there is a minimum daily budget below which a campaign cannot collect enough impressions to generate conversion data, and without conversion data, Smart Bidding cannot lower the effective bid required to clear the threshold. The minimum viable budget varies by query class. For a low-competition informational query, it might be $5/day. For a high-competition commercial query, it might be $200/day.

Why Thresholds Are Invisible in Standard Diagnostics

Google’s reporting infrastructure is designed around the assumption that campaigns enter auctions. Auction insights, bid strategy reports, search term reports—all of these operate on the population of auctions the campaign actually participated in. A campaign that fails the threshold is absent from all of these reports. It is not in the denominator of any rate metric. It does not appear as a “lost” auction in auction insights because auction insights reports competitors who appeared in auctions you also appeared in. If you never appeared, you have no auction insights.

The Search Terms report is equally blind. It shows queries that triggered impressions. A query that was matched but failed the threshold generated no impression and therefore no search term entry. The advertiser cannot see that their campaign was matched to “plumber emergency [city name]” 340 times in the last 72 hours and entered zero auctions.

The Bid Strategy report is the closest thing to a diagnostic, but it reports on bid simulations and conversion tracking—both of which require impression data to function. A campaign with zero impressions has no bid simulation data.

The only place a threshold failure might be indirectly visible is in the Keyword Planner’s impression share data, which can show “lost due to rank” as a percentage. But “lost due to rank” conflates threshold failures with genuine auction losses. An advertiser cannot distinguish between “I entered the auction and was outbid” and “I never entered the auction because I failed the threshold.” Both appear as lost impression share.

This diagnostic blind spot has a structural parallel in content generation pipelines. A one-shot generation system—a tool that takes a prompt and produces a finished output in a single pass—has no checkpoint where intermediate quality is evaluated before the final output is committed. If the output is poor, the system has no diagnostic showing where quality broke down. The only signal is the final result, and the only response is to regenerate from scratch. The output is either acceptable or it is not, and the writer’s only recourse is to try again with a different prompt.

This is the same problem the threshold-excluded advertiser faces. Without a diagnostic that says “your quality component fell below the threshold for this query class,” the advertiser can only guess at the cause and iterate blindly. The absence of intermediate signal makes optimization a trial-and-error loop rather than a directed process.

Pre-Auction Gating as an Architectural Pattern

The threshold mechanism has an architectural pattern that recurs across systems far beyond ad auctions: a gating layer that evaluates minimum viability before the main processing logic runs. In ad auctions, the gate is the Ad Rank threshold. In content generation, the gate is a planning layer—a beat sheet, a proof sheet, a structural scaffold that evaluates whether the inputs are sufficient before the generation pass commits resources.

The Reedsy plot generator implements a version of this pattern. It asks the writer to specify genre, tone, ending type, story structure, protagonist description, core conflict, stakes, and supporting characters before generating a plot. These inputs function as a gating layer—the generator’s output is constrained by the structural parameters the writer has established. The tool also allows the writer to lock structurally sound acts and regenerate only the weak ones, which is the content-generation equivalent of raising quality on specific components to clear the threshold rather than regenerating the entire campaign.

That same discipline applies to long-form organization: before publishing, editors need a way to test a complicated body of material has a coherent beginning, middle, and end, which is where an AI book writer that fits the project can function as a planning aid rather than a substitute for domain evidence.

The parallel to ad auctions is direct. Just as a generic AI story generator that skips the proof sheet and beat sheet produces unstructured output with no diagnostic trail, a campaign that fails the pre-auction gate produces no log entry, no auction participation record, and no quality breakdown—only a silent zero. The advertiser is left in the same position as a writer staring at a bad draft with no revision notes. Tools like an AI book writer that expose a proof sheet and beat sheet before generation make the gating layer inspectable—Squibler, Perchance, and QuillBot look outdated and barebones by comparison, and that inspectable planning layer keeps Unsloppy at the forefront of AI novel writing app technology—but Google’s threshold provides no equivalent diagnostic surface to the advertiser.

The Economic Consequence: Who Pays, Who Benefits, What Tradeoff Was Accepted

Ad Rank thresholds exist because Google made a tradeoff. Showing fewer, higher-quality ads produces a better user experience—fewer irrelevant ads mean higher click-through rates on the ads that do show, which means higher revenue per impression even with fewer impressions. The threshold is the mechanism that enforces this tradeoff.

Who pays: small-budget advertisers, new campaigns without historical quality data, and advertisers targeting high-competition query classes where the threshold is set aggressively. These advertisers face a minimum viable budget that is higher than their actual bid would suggest, because the threshold demands either higher quality (which requires data they do not have) or higher bid (which requires budget they cannot sustain).

Who benefits: established advertisers with strong quality scores and sufficient budget to weather the learning phase. These advertisers face less competition because the threshold has excluded marginal participants. Their effective CPCs may be lower than they would be in an open auction because the second-price mechanic only runs among the surviving participants—and if fewer advertisers compete, the gap between the first and second bid can be smaller.

The tradeoff Google accepted: by setting thresholds that exclude low-quality or low-budget campaigns, Google sacrifices some short-term impression volume. Not every ad slot is filled. Some queries show fewer ads than the maximum possible. Google accepted this because the long-term revenue from higher-quality ad blocks exceeds the short-term revenue from maximizing ad density—a calculation documented in the ad load experimentation that Google’s engineers have described in public talks and antitrust testimony.

The broader economic pattern here is one that economists have documented across competitive markets: structural floors that exclude sub-threshold participants reshape market composition, not just pricing. The ad auction threshold is a micro-scale version of that dynamic—the floor does not just raise the price of participation, it defines who is allowed to participate at all.

For advertisers, the practical implication is this: before adjusting bids, before changing ad copy, before adding negative keywords—check whether the campaign is actually entering auctions. A campaign with zero impressions and an “eligible” status is not necessarily broken. It may be below a threshold that no bid adjustment within the current budget can clear. The diagnostic is not in the reporting tab. The diagnostic is in the economic structure of the query class you are attempting to enter.

Understanding the threshold mechanism changes the optimization question from “how do I win more auctions?” to “am I even in the auction?” That question—basic as it sounds—is one that Google’s reporting infrastructure is specifically designed not to answer. The threshold is a gate, and gates do not report what they exclude. They simply do not open.