How Cookie-Based Retargeting Actually Works (and What's Changing)
"They're following me around the internet" describes the effect. The mechanism underneath it is a lot more specific, and it's changing faster than most retargeting setups have adapted to.
Classic cookie-based retargeting works by dropping a third-party cookie from an ad platform's own domain when a visitor lands on your site (via a pixel embedded in your pages), adding that visitor to an audience list, and then having the same ad platform recognize that cookie on other sites where its ad inventory runs, serving that visitor an ad tied to your site. Browsers restricting or blocking third-party cookies breaks exactly this recognition step, which is why retargeting has been shifting toward server-side, hashed-identifier matching instead.
The classic mechanism, step by step
- Your site loads a pixel (a small script or 1x1 image request) from an ad platform's domain - Meta, Google Ads, or a dedicated retargeting vendor.
- That request lets the ad platform set a cookie under its own domain, associated with whatever behavior you've told it to track (a product view, an add-to-cart, a checkout start).
- The visitor leaves your site. Later, they visit a different site that also happens to show ads from the same ad platform's network.
- Because the cookie was set under the ad platform's own domain (not yours), and that same domain serves the ad on the third-party site, the platform reads its own cookie, recognizes the visitor, and serves them an ad tied to the earlier behavior on your site.
This is a genuinely different mechanism from the first-party analytics cookie your own site sets to measure its own visitors - see our note on how first-party cookies actually work. Retargeting specifically depends on that cookie being readable by the ad platform on a domain other than yours, which is the exact behavior third-party-cookie restrictions target.
Why browsers restricting third-party cookies breaks this specifically
Safari's Intelligent Tracking Prevention, Firefox's Enhanced Tracking Protection, and Chrome's own phased restrictions on third-party cookies all target exactly the step where an ad platform's cookie, set on your site, gets read back on a different site. The cookie can still be set; it just can no longer be reliably read across the two contexts that made cross-site retargeting work.
What's replacing it: server-side, hashed-identifier matching
Instead of relying on a cookie the browser might block, a server-side approach (Meta's Conversions API and equivalents from other platforms work this way) sends a hashed version of an identifier you already have - typically an email address, hashed before transmission so the raw value never leaves your systems - directly from your server to the ad platform's servers. The platform matches that hash against its own logged-in user base, bypassing the browser and its cookie restrictions entirely. The tradeoff: this only works for visitors you can already identify (a logged-in customer, an email-capture form), not anonymous first-time visitors, which is a fundamentally narrower audience than cookie-based retargeting could reach.
What this means for a retargeting setup today
A retargeting program still running purely on the classic pixel-cookie mechanism is already under-counting its real reach on Safari and Firefox, and will lose more ground on Chrome as restrictions phase in there too. The durable fix is layering in server-side matching for identified visitors alongside (not instead of) the pixel, so the identified portion of your audience isn't dependent on a browser policy that's actively moving against it.
Cookie-based retargeting - common questions
▸Is retargeting dead now that third-party cookies are being phased out?
No, but the mechanism is shifting. Retargeting on your own properties (email, logged-in app experiences) never depended on third-party cookies at all. Cross-site retargeting is moving toward hashed first-party identifiers matched server-side (Conversions API-style integrations) and browser-native alternatives, rather than disappearing outright.
▸What is the difference between retargeting and remarketing?
The terms are used interchangeably by most platforms today. Where a distinction is drawn, 'remarketing' sometimes refers specifically to email-based re-engagement and 'retargeting' to ad-based re-engagement, but this isn't a consistent industry standard.
▸Can retargeting work without any cookies at all?
Yes, in a more limited form: server-side matching using a hashed customer identifier (an email address hashed before it's sent) can re-identify a known customer across platforms without relying on a browser cookie, though it only works for visitors you already have some identifying information for, not anonymous first-time visitors.
Want to know how much of your retargeting audience is already invisible on Safari?
A data audit checks your actual pixel-versus-server-side coverage, not a platform's aggregate reach estimate.