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_signalsto 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.
