The complete history of third-party cookies, and why they failed

A shopping cart, not a spy

In 1994 the web had no memory. You put a book in a cart, clicked to the next page, and the site had no idea who you were.

Lou Montulli, a young engineer at Netscape, fixed that with a tiny text file. The site writes it into your browser. The browser hands it back on the next request, and only to the site that wrote it. He borrowed the name from programmer slang, "magic cookie", for a small piece of data passed between programs. Cookie support shipped in Netscape's first browser that autumn, and within a year Netscape was the most used browser in the world.

The design had a rule built in: a cookie belongs to one domain. Nobody else reads it. It was meant to stop exactly the thing it became: a permanent ID that follows you everywhere.

The cookie was built to remember you on one site. The ad industry used it to follow you on all of them.

Tools after the cookie, by category

None of these categories is complete on its own.

Comparisons: Stape, TAGGRS vs Stape, Triple Whale, Google Tag Gateway.

When not to use DataCops

• You need full control of every tag. A server-side GTM container on Stape or similar, run by someone who owns it.
• You run a small operation on one platform. The free tools from Meta or Google, plus a basic dashboard, may be enough until spend grows.
• You need order-level Shopify reporting only. A Shopify-native app may suit; DataCops also has a Shopify app if you need other platforms and bot filtering.

The loophole nobody closed

Web pages do not load from one domain. They pull images, scripts and ads from many. And any domain that delivers something to the page can set its own cookie.

So if one ad network sits on a news site, a recipe site and a shoe store, it sets one cookie and reads it on all three. Same ID, three sites, one profile. The cookie never left its domain. The domain just showed up everywhere.

DoubleClick, founded in 1995, built a business on it. The public found out in February 1996, when the Financial Times reported on cookies. In February 1997, the IETF's cookie standard, RFC 2109, said browsers should block third-party cookies by default. Netscape and Internet Explorer did not. That decision, not made in 1997, shaped the next thirty years.

1996 to 2017: the industry builds on the hole

For two decades nothing changed structurally. Retargeting, frequency caps, view-through conversions, data management platforms, real-time bidding and cross-device graphs were all built on the same hole. Every big analytics product used cookies for identity across sessions.

The same script architecture had a second effect. If ad networks could load tracking scripts silently in a visitor's browser, so could people fabricating traffic. Bots and ad fraud grew in the same pipes. The cookie created the tracking architecture; the tracking architecture made room for the fraud.

The full timeline, 1994 to 2025

Read the 1997 row again. The fix was written down nearly thirty years ago. The ad industry grew up in the time it took browsers to act on it.

2017 to 2020: Safari and Firefox close it

Apple moved first. Intelligent Tracking Prevention arrived in Safari 11 in 2017 and limited cookies from domains Safari classified as trackers. ITP 2.0 in 2018 removed the 24-hour window those domains had. In 2019 ITP 2.1 capped cookies written by JavaScript, even first-party ones, at 7 days, and ITP 2.2 cut that to 24 hours when the visitor arrived through a link carrying a click ID. In March 2020 Safari blocked all third-party cookies by default. The details are in ITP explained.

Firefox followed: Enhanced Tracking Protection on by default in 2019, Total Cookie Protection for everyone in 2022, which gives each site its own cookie jar.

GDPR arrived in May 2018 and made consent a condition for tracking cookies in the EU. A generation of consent banners appeared to handle it, most of them loaded from the vendor's own domain. Blockers that stop those domains stop the banner, so for some privacy-minded visitors the question was never even asked, and nobody saw it fail.

For audiences heavy on Mac and iPhone, a large share of buyers has lived without third-party cookies since 2020. The gap mostly showed up as "direct" traffic, not as an error.

2021: the attribution crisis

iOS 14.5 in April 2021 made apps ask permission before tracking people across other apps. Many users said no. Meta introduced Aggregated Event Measurement, and advertisers watched reported conversions fall and campaign learning get worse.

That was the moment server-side sending, Meta's Conversions API, went from a nice extra to a must. Move the event off the browser, send it server to server, get past blockers and ITP. The pitch was right as far as it went.

But a server sends what it receives. If a bot session triggered the event, the Conversions API delivers it to Meta with better match quality than the old pixel ever had. The pipe got better. The water did not.

Server-side tracking fixed delivery. It did nothing about what was being delivered.

Are third-party cookies dead in Chrome?

No. Google announced the phase-out in January 2020. The date slipped to 2023, then 2024. A 1% test ran in January 2024. In July 2024 Google dropped the phase-out in favour of a user choice. In April 2025 it dropped the prompt too. In October 2025 it retired most of the Privacy Sandbox APIs meant to replace cookies, after low adoption and pressure from the UK competition regulator.

So third-party cookies still work in Chrome, with no removal date, and Safari and Firefox still block them. The web is split. That is not a comeback. It means your tracking works for Chrome visitors and quietly fails for the others. On an iPhone-heavy audience, that is a lot of your buyers.

An example. A skincare store runs Meta ads. Most buyers use iPhones. The pixel sees the desktop Chrome sales and misses many Safari ones. Meta learns that its best customers are desktop Chrome users and shifts budget toward them. Nobody changed the ads. The cookie just stopped reporting half the story.

Why the cookie failed: five decay paths

Browser blocks are only the most visible part. Third-party tracking failed along five paths, and most conversion setups inherited all of them.

1. Geographic over-correction. Cookieless analytics started as an EU compliance answer, then got deployed worldwide because it was easier. In markets that never required it, every returning customer now looks like a stranger. See privacy-friendly analytics.
2. "Reject all" treated as "measure nothing". Many consent setups throw away anonymous measurement along with identifiable data when a visitor rejects, even where anonymous counts would be allowed.
3. The consent banner that never loads. Banners served from a vendor's domain get blocked for some visitors. No banner, no choice, no tracking, and a session with no banner looks the same as one that rejected.
4. Blocked scripts. Well-known analytics and pixel domains are on blocker lists. Server-side tracking helps, but if the browser call that feeds the server is blocked, the server sees nothing.
5. Bots in the same pipes. Of the traffic that gets through, some is bots, data centres, VPNs and scrapers. Their events go into the Conversions API, and the ads learn to find more of them.

The cookie did not fail only because browsers blocked it. It failed because it was carried by third-party scripts, and everything built that way inherited the same weaknesses: blockable, legally fragile, open to bots, and gated by a consent layer that blocks itself.

What the history actually teaches

The cookie was a symptom. The disease was third-party architecture: tracking scripts on a domain you do not own, loaded from places you do not control, in a browser with every reason to block them.

When the cookie weakened, most replacements kept the disease. Server-side containers still depend on a browser call. Analytics still loads as recognisable third-party scripts. Consent banners still load from blocked domains. Server-side sending still forwards events without asking whether the visitor was human.

What actually addresses the root cause is architectural: collection served from your own domain, a consent banner from your own domain, the click stored on your server instead of in a browser cookie, and bot filtering before any event is sent.

What replaced them

How DataCops works without the third-party cookie

• Collection on your own domain. One script and one DNS record serve everything from your subdomain, so it is your site, not a third party. With DNS on Cloudflare, the free, optional DataCops Cloudflare Worker reads click IDs and UTMs off the first request at the edge, before any browser script runs. It captures; it does not block.
• The click on the server. gclid, wbraid, gbraid, fbclid, ttclid and li_fat_id are kept on the server for up to 90 days, so a deleted browser cookie does not delete the click.
• A cookie the browser respects. A signed first-party cookie set by the server on your domain lasts up to 400 days where enabled, set only after consent and a clean bot check, signed per site so it cannot follow anyone across sites. The opposite of a third-party cookie.
• Real people only. Every visit gets a bot verdict checked against an IP database covering 360+ billion IPs and 350+ monitoring points, with a Real people only switch per platform.
• Consent from your domain. The first-party consent manager, TCF 2.2 certified, asks EU, EEA, UK and Swiss visitors and feeds Google Consent Mode.
• Server-side sends, counted once. Meta, Google Ads, TikTok and LinkedIn, deduplicated against the pixel by event ID.
• The real sale. HighLevel stages natively, any CRM through a webhook, Shopify through the DataCops Shopify app; see offline conversions.
• Ads Warmup. Upload your customer list, see a 0 to 10 match score per person, and send up to 20,000 to Meta, Google Ads and TikTok, dated when you send (on Google Ads, only people who clicked a Google ad are credited). The cookieless way to tell the ads who your buyers are. See Ads Warmup.
• Analytics and a log. First-party analytics, a GA4 alternative, and a delivery log row for every conversion: sent, held, skipped or failed.

Pricing. More on the setup in server-side tracking.

Tracking that works now, step by step

1. Check the gap. Put sales in Ads Manager next to sales in your store or CRM for the same week. Split by device if you can.
2. Collect on your own domain. Move scripts and the consent banner to your subdomain.
3. Keep the click ID on the server, not only in a browser cookie.
4. Filter bots before anything is sent to an ad platform.
5. Send conversions server-side with hashed email and phone, and deduplicate against the pixel with the same event ID.
6. Send the sale, not the form. Match CRM deals back to the click.
7. Warm up new campaigns with your existing customers instead of cookie-based lists.
8. Read the delivery log weekly. Failed and held events are where the money leaks.

The cookie was always a borrowed messenger. Send the sale yourself.

FAQ

Who invented the cookie?

Lou Montulli at Netscape, in 1994. He built it so a website could remember a shopping cart between pages. Cross-site tracking was a side effect of how other domains on a page could set cookies, not the goal.

What is the difference between a first-party and a third-party cookie?

A first-party cookie is set by the site in your address bar and read only by that site. A third-party cookie is set by another domain loaded on the page, like an ad server, and can recognise you on every site that loads it.

When did browsers start blocking third-party cookies?

Safari limited them from 2017 with Intelligent Tracking Prevention and blocked them all by default in March 2020. Firefox turned on Enhanced Tracking Protection by default in 2019 and Total Cookie Protection for everyone in 2022. Chrome never removed them.

Are third-party cookies still used in Chrome in 2026?

Yes. Google dropped its plan to remove them in July 2024, dropped the user choice prompt in April 2025, and retired most Privacy Sandbox APIs in October 2025. Safari and Firefox still block them by default, so any setup built on them works for only part of your traffic.

Does the end of third-party cookies affect Meta and Google Ads?

Yes. The pixel loses conversions it used to see, especially on Safari and iPhone, so the ads learn from fewer and worse signals. Capturing the click on your own domain and sending conversions server-side fixes most of the gap.

Is server-side tracking the replacement for cookies?

It replaces the pixel as the only messenger. Your server sends the conversion straight to the ad platform with the click ID and hashed contact details. But it does not filter: if a bot triggered the event, a server forwards it just as faithfully, so bot filtering has to come first.

Do I still need a cookie banner?

In the EU, EEA, UK and Switzerland, yes, for tracking. Serve it from your own domain so blockers do not stop it loading, and send only what the visitor agreed to. Elsewhere, consent rules differ and anonymous measurement is usually allowed.

Did Privacy Sandbox replace third-party cookies?

No. Google retired most Privacy Sandbox APIs in October 2025 after low adoption and regulator pressure. There is no single industry replacement; first-party data sent server-side is what works.

Sources

• IETF RFC 2109: HTTP State Management Mechanism (1997)
• WebKit: full third-party cookie blocking and more (2020)
• WebKit: tracking prevention in WebKit
• Privacy Sandbox: update on plans for Privacy Sandbox technologies