How Retargeting Actually Works and Why It Sometimes Fails: A Mechanism-Level Breakdown

Retargeting is a bet on somebody’s next impression. You bid on it because of something the person did earlier — opened a product page, filled a cart and walked, stopped launching the app. The trade term is retargeting. Google’s product term is remarketing. Same mechanism either way, and it has three parts: a tag that records an event and pins an identity to it, a server-side list that holds the membership, and an auction-time lookup that turns membership into a bid. The things you handle daily — Google Ads remarketing lists, GA4 audiences, Customer Match uploads, OpenRTB user.data segments, cookie syncs, Protected Audience interest groups — are all variations on those three parts. Retargeting fails more often than any other campaign type, for a boring reason: it has the longest dependency chain in paid media. Capture, match, activation, auction clearance, in sequence, and no error message when a link snaps. This piece walks the chain end to end. Then it catalogs the failure modes I keep finding in real ad stacks, from Consent Mode and Safari’s seven-day cookie cap to list minimums and the incrementality problem no dashboard will surface for you.

What the Term Actually Covers

Vendors blur this vocabulary on purpose, so pin it down first. Behavioral retargeting keys on observed actions: tag fires, rule matches, cookie joins a list. CRM retargeting keys on declared identity — you hash customer emails, upload them, and the platform matches the hashes against its signed-in users. Google’s version is Customer Match. Dynamic remarketing is behavioral retargeting plus a Merchant Center feed, so the creative renders the exact product IDs the person saw. Search retargeting — what Google Ads called RLSA, before the naming collapsed into generic “audiences” — adjusts search bids for people who already visited the site. On the sell side, the same construct shows up as audience segments attached to bid requests, sold by data providers or built first-party inside a publisher’s stack.

The mechanical distinction is where the identity lives: in a cookie or device ID that has to survive from capture to impression (behavioral), in a hash matched against a login graph (CRM), or in the browser itself (Protected Audience). Google’s similar audiences — the modeled variant — were phased out across 2023 and replaced with audience solutions that reach differently and report less. Every failure mode below traces back to one of those substrates.

The Write Path: How a User Gets onto a List

The tag and the first-party cookie

On a Google Ads stack the write path starts with the Google tag — gtag.js or a Google Tag Manager web container. When it loads on a product page, two things happen. It writes first-party cookies on your domain, _gcl_au among them — the conversion linker cookie, which Google documents with a 90-day lifetime — and it sends a measurement ping to Google’s ad endpoints. The legacy image-pixel tag did the same job with a request under googleadservices.com/pagead/conversion/. The ping carries the account ID and the page context. Google evaluates your list rules server-side: URL equals, starts with, contains, or the compound rule that defines a cart abandoner — visited the cart, never reached the confirmation.

GA4 audiences follow the same shape with different plumbing. The audience definition is evaluated against the event stream, and matched users ship to Google Ads across the property link. The rule language is richer — event parameters, sequences, membership conditions — but the output is identical: a membership record keyed to a browser.

One habit from audit work, worth keeping: a “member” is a cookie, not a person. A single shopper can be three members (work laptop, phone, home machine) or zero, after a cookie clear. Every list-size number in the interface is a cookie count. Plan against the cookie.

The server-side match

Google does its identity matching internally. The advertiser-domain cookie gets correlated with Google’s own cross-site identifier — the IDE cookie under doubleclick.net, which Google’s cookie disclosures describe as serving functions like frequency capping and attribution on its ad products — and, where there is one, with a signed-in Google account. No external sync needed. Both ends of the pipe are Google’s. That is the structural advantage third parties burn their sync budgets trying to copy.

Customer Match swaps the cookie for a hash: normalize the email, SHA-256 it, upload the list, and Google matches server-side against signed-in accounts. Coverage is bounded by sign-in behavior, which the help documentation does not quantify. Treat any coverage claim as unverified until you have seen your own match numbers.

Membership duration and list rules

Two list settings quietly decide most of what advertisers experience as “targeting.” Google’s help documentation sets the default membership duration at 30 days, with a documented maximum of 540. The clock resets on the last qualifying event: a weekly visitor stays on the list, while a one-time visitor falls off on day 31. If your buying cycle runs 60 to 90 days — B2B software, travel, considered purchases — the default expires before the purchase window opens. The campaign then “fails” while doing exactly what it was configured to do.

The Read Path: How a List Becomes a Bid

Inside Google’s stack

The read path starts when the user lands on a page in the Display Network — a publisher running Ad Manager. The ad request carries whatever identifiers Google can see. The ad server evaluates audience and line-item targeting, and for Google Ads demand, remarketing membership is checked at serve time. A winning bid still has to clear the AdX auction — first-price since 2019 — against every other bidder on that impression. Frequency capping keys to the IDE cookie. Nothing in this chain guarantees delivery: an impression requires a bid above the publisher’s floor, above the competition, within your pacing, and under your frequency cap. You are not buying a person. You are buying a chance at an auction where the person happens to be present.

Outside Google’s stack: OpenRTB and cookie syncs

The generic version runs on the IAB’s OpenRTB protocol, and the spec is worth reading directly rather than through a vendor’s deck. The bid request carries a user object. Data providers attach segments through the user.data array, where each data object names the provider and carries segment IDs, and user.buyeruid holds the exchange-specific ID a bidder is expected to recognize. The OpenRTB standard and its object reference live on the IAB Tech Lab site.

For a bidder to recognize any of it, the two systems must have synced. The SSP calls the bidder’s usersync endpoint — image or iframe — each side records the other’s ID for that browser, and the bidder builds a cookie map. Prebid’s userSync module is the open reference implementation, and its defaults are telling: syncs capped per bidder, delayed on load. That is roughly how much the industry trusts them. A segment you paid to build is worthless on a bid request whose user ID your map has never seen. In stacks I have audited, third-party match rates land in the 30-to-60-percent band on a good day. Anyone promising near-universal matching is claiming something the sync logs do not support.

Where It Breaks: A Failure Catalog

A retargeting campaign rarely “fails” in any general sense. One of five specific links snaps, and each has a different fix.

Capture failures: the event never gets recorded

This break is the quietest. Under Consent Mode v2, a denied ad_storage signal means no cookie write and no behavioral ping on European traffic — and modeled conversions refill the report afterward, so the dashboard looks healthier than the log. Under Safari ITP, third-party cookies are blocked outright and script-written first-party cookies are capped at seven days, a cap WebKit documented in its ITP 2.1 explanation. A 30-day behavioral list is structurally impossible on Safari via script-set cookies; the membership exists for a week, then evaporates. Then the mundane breaks: an unpublished GTM container, a wrong account ID, a consent tool gating the tag before it loads. And the single-page-app problem — route changes that never fire a page event never satisfy URL-based rules, so an SPA can show full traffic in analytics and an empty remarketing list in Google Ads on the same day.

Matching failures: the event cannot be connected

A captured event is still useless if the identity at impression time does not match. Third-party syncs miss most cookies on a bad day and half on a good one, and entire browser populations — Safari, Firefox with ETP — are unsyncable at the third-party layer at all. On iOS, App Tracking Transparency gates IDFA access behind opt-in, which industry dashboards (Flurry’s among them) have placed at roughly a quarter of US users since the rule took effect. The list is also device-bound: membership written on the desktop cookie does not follow the user to the phone unless the platform has a logged-in graph to bridge devices. Google has one. Most of the open web does not.

Activation failures: the list exists but will not serve

Google’s help documentation puts the activation floor at 100 active cookies for Display remarketing lists and 1,000 for Search remarketing lists. Low-traffic sites can sit under the floor indefinitely, and the interface tells you only after the membership window has passed. A membership duration shorter than the purchase cycle produces the same silence, on a delay. Policy produces a third variant: personalized-ads restrictions on sensitive categories disapprove remarketing creatives or suspend collection outright. And the 2023 sunset of similar audiences shifted delivery for every campaign that leaned on lookalike expansion; the replacements reach differently and report less, so “it used to work” is often the only symptom you get.

Auction failures: the bid does not clear

A live list with healthy bids can still lose most impressions. Retargeting audiences concentrate competition — every retailer targets the same cart abandoners, so clearing prices on those users run high. Publisher floors rise underneath you, pacing pulls spend early in the day, and frequency caps keyed to the IDE cookie suppress exactly the impressions you expected to win. When an account team says retargeting stopped working, the list is often fine and the auction moved. The evidence is bid-landscape data and delivery share by hour, not audience reports.

Measurement failures: the campaign works on paper only

The last failure mode is the one no dashboard surfaces. Retargeting lists select on purchase intent, so the people on them convert at a higher rate whether or not you advertise. Last-click and view-through attribution assign that baseline to your campaign. The only clean test is a holdout: suppress the list for a random share of users, pre-register the metric, and compare. Ads Data Hub supports audience analysis but applies aggregation thresholds and blocks user-level export, so the platform cannot run this test for you — by design. Some retargeting revenue is purchased and some is merely collected, and the split varies by vertical, price point, and cycle length. If nobody in the room has run the holdout, nobody knows the split.

A Verification Checklist, Link by Link

Work the chain in order. The failing link is almost always upstream of where the account team is looking.

1. Tag. Open DevTools on a qualifying page and watch the network tab for the measurement ping and its parameters. Confirm _gcl_au is present, and check its expiry against your membership duration. A ping that never leaves the browser explains everything downstream.
2. List. In Google Ads, watch the active-users trendline, not the total member count. A flat total with a decaying active count is the signature of duration or ITP decay. Re-check the rules against current site URLs — redesigns break “starts with” patterns silently.
3. Match. If you buy through a DSP, pull sync coverage for the exchanges you actually win on, and compare delivery share by browser. Under-delivery concentrated in Safari and Firefox is an identity problem, not a creative problem.
4. Auction. Check frequency caps, pacing curves, and bid strategy against floor data where you have it. High win rate with low volume points at a cap; low win rate with stable bids points at floors or competition.
5. Measurement. Run the holdout before optimizing anything else. A campaign that loses a third of its reported conversions in the test was buying credit, not behavior — and no amount of bid tuning fixes that.

The Identity Layer Is Being Rebuilt Underneath You

Chrome’s third-party cookie saga has changed direction more than once, and each turn rewrote somebody’s retargeting forecast. Google announced deprecation in January 2020, delayed it repeatedly, proposed restrict-by-default in February 2024, reversed to a user-choice prompt in July 2024, and in April 2025 dropped the standalone prompt altogether. As of this writing, third-party cookies still function in Chrome. In Safari and Firefox they have been functionally dead for years. Plan for the browser mix you actually serve, not the press release.

The replacement mechanism is already shipping. The Protected Audience API (formerly FLEDGE) moves the audience list into the browser: the advertiser’s tag calls navigator.joinAdInterestGroup() with an expiry the advertiser sets, capped at 30 days, and when the user lands on a participating publisher, the seller runs an in-browser auction through runAdAuction() inside a worklet. Membership never leaves the device. Ad and reporting payloads must clear a k-anonymity threshold — initially 50. Debugging is deliberately constrained, with no user-level logs for the operator to inspect. Google’s developer documentation covers the full flow. The mechanism survives; the observability does not. Failure modes shift from “cookie missing” to “interest group expired” and “k-anonymity unmet,” and both are harder to see from your seat.

Frequently Asked Questions

Why did my remarketing list stop collecting new members?

Work the chain in order: consent gating (a denied ad_storage signal), browser caps (Safari’s seven-day limit on script-written cookies), or a tag change — an unpublished container, a redesign that broke URL rules, a single-page app that stopped firing page events. The active-users trendline in Google Ads plus a network-tab check on a qualifying page will localize the break faster than any bid change.

What is a realistic cookie match rate for programmatic retargeting?

For third-party syncs, 30 to 60 percent is the honest band — on a clean, Chrome-heavy audience. On Safari and Firefox inventory, near zero. Google’s own stack runs higher because matching happens inside one company’s first-party graph. Judge every vendor number against your own sync logs before paying for reach claims.

Does retargeting drive incremental conversions, or does it just collect them?

Both, in proportions nobody can quote without a test. Lists select on purchase intent, so last-click and view-through reports overstate causality. A randomized holdout with a pre-registered metric is the only clean measurement. Expect the campaign to lose some reported conversions — that loss is the measurement working.

Is retargeting dead without third-party cookies?

It has been mostly dead in Safari and Firefox for years, and it remains alive in Chrome as of Google’s April 2025 decision to keep third-party cookies. Protected Audience preserves the mechanism on-device — interest groups joined in the browser, auctions run in a worklet — with less operator visibility, not more.

What is the difference between retargeting and remarketing?

Nothing structural. Remarketing is Google’s product term for the same mechanism. The meaningful split is by identity substrate: behavioral (cookie-keyed), CRM (hash-keyed, Customer Match), or on-device (Protected Audience interest groups).

Where This Goes Next

This piece opens a working series on identity and auction mechanics for the people who operate inside them. The next installment walks the Protected Audience auction end to end — the join call, the worklet, seller scoring, the k-anonymity server — with the same documentation-versus-behavior treatment. If you run this stack and have anonymized logs where the documentation and the observed behavior disagree, that gap is exactly what this column runs on.