If your Google Ads are reporting fewer conversions than your CRM shows, or your Meta remarketing audiences feel smaller than they should, third-party cookie restrictions are almost certainly part of the explanation. This has been building for years — and despite a high-profile reversal from Google in 2025, the practical reality for advertisers has not improved much.
This article explains what third-party cookies are, the full timeline of their erosion across browsers, what that means for your campaigns right now, and why server-side tracking is the fix that works regardless of what Chrome does next.
What Are Third-Party Cookies?
A cookie is a small text file stored in your browser by a website. It holds information like your session token, cart contents, or a unique visitor ID.
A first-party cookie is set by the website you are actually visiting — yourshop.com setting a cookie on yourshop.com. The site recognises you on your next visit.
A third-party cookie is set by a domain different from the one you are visiting. When yourshop.com loads the Meta Pixel, that pixel attempts to set a cookie from Meta's domain (facebook.com) inside your browser while you are browsing yourshop.com. Meta uses that cookie to identify you when you later visit other sites, allowing them to serve you retargeted ads and attribute conversions back to the ad you clicked.
For over two decades, third-party cookies powered:
- Retargeting — following users across the web after they visited your site
- Cross-site attribution — connecting an ad click on one site to a purchase on another
- Audience building — assembling behavioural profiles from browsing patterns across multiple sites
- Frequency capping — limiting how often the same user sees the same ad across different publishers
The entire behavioural advertising infrastructure was built on the assumption that third-party cookies would always be available in the browser. That assumption is no longer safe.
The Deprecation Timeline: Browser by Browser
Safari (2017–present)
Apple was first. In 2017, Safari introduced Intelligent Tracking Prevention (ITP), which used machine learning to identify and restrict cookies from domains that it classified as cross-site trackers.
ITP has been updated repeatedly since then. The current state for advertisers:
- Third-party cookies are blocked entirely in Safari
- First-party cookies set by third-party scripts (like a pixel's JavaScript setting a cookie on your domain) are limited to 7 days — sometimes 24 hours depending on how the cookie was created
- Safari has around 19–25% global browser market share, and significantly higher share on Apple devices and in privacy-conscious markets
If a customer clicks your Meta ad on their iPhone and takes more than a week to purchase, Safari's ITP breaks the attribution chain. The sale happens. Your ad platform never knows it drove the result.
Firefox (2019–present)
Mozilla introduced Enhanced Tracking Protection (ETP) in Firefox 2019, blocking third-party cookies from known trackers by default. Firefox's global market share is smaller (around 3–4%), but its users disproportionately use privacy features — the overlap with ad-blocker users is high.
iOS App Tracking Transparency (2021–present)
With iOS 14.5, Apple required every app to ask explicit permission before tracking users across other apps and websites. The prompt is blunt: "Allow [App] to track your activity across other companies' apps and websites?" Most users say no. Opt-in rates consistently run at 20–30%.
This restriction covers Meta's Mobile SDK, which powers conversion tracking for app installs and mobile web events on iPhones. Every non-opt-in iOS user is effectively invisible to Meta's browser-based pixel.
Chrome: The Reversal
Chrome holds around 65% of the global browser market. For years, Google said it would fully deprecate third-party cookies by a specific date — and the deadline kept moving: 2022, then 2023, then 2024.
In July 2025, Google reversed course. Instead of removing third-party cookies from Chrome, Google announced it would not proceed with the standalone deprecation. Instead, Chrome will introduce a user-facing prompt allowing users to set their own tracking preferences, similar to Apple's ATT.
This sounded like good news for advertisers. In practice, it changes less than it appears to.
First, Safari and Firefox have already blocked third-party cookies for their combined user base — roughly 25–30% of global browser traffic, and more in markets with high iPhone penetration.
Second, the iOS ATT restriction has been in place for four years and has permanently restructured how Meta tracks mobile conversions.
Third, Chrome's user prompt will likely result in many users declining cross-site tracking, particularly in privacy-conscious segments and in markets where GDPR consent banners have trained users to click "Decline".
Fourth, the underlying problem — that browser-based tracking is increasingly unreliable — has not gone away. Ad blockers, ITP on Safari, and consent requirements under GDPR and similar privacy regulations all continue to erode the signal that reaches your ad platforms.
What Third-Party Cookie Restrictions Mean for Your Campaigns
Retargeting audiences are smaller than they should be
Your retargeting pool is built by placing a third-party cookie (or pixel event) on every visitor to your site. Safari users, iOS users who declined ATT, and anyone using an ad blocker are not being added to that pool. If 30–40% of your visitors are not being cookied, your remarketing audiences are missing 30–40% of your actual potential retarget pool.
Attribution is breaking on longer journeys
Most significant purchases involve multiple touchpoints spread across days or weeks. A user clicks a Meta ad, visits your site, leaves, comes back a week later from organic search, and purchases. The Meta Pixel needs the click ID cookie from that first visit to still be present at the time of purchase to attribute the conversion. Under Safari ITP, that cookie is gone in 7 days. The conversion goes unattributed.
Ad algorithms are training on incomplete signals
Meta's Advantage+ and Google's Smart Bidding are only as good as the conversion data they receive. When 30–40% of purchases are invisible to the algorithm because the browser blocked the pixel event or the cookie expired, the algorithm builds targeting models from a skewed sample. It finds more users who look like the customers whose conversions got tracked — which often means Chrome desktop users who do not use ad blockers, not your actual full customer base.
Your reported ROAS is flattering you
The conversions you are seeing in your ad platform are a subset of the conversions that actually happened. If your Meta ads report a $4 cost per purchase, your real cost per purchase is likely higher — because a meaningful fraction of actual purchases were never attributed. Decisions made on inflated ROAS numbers lead to misinformed budget allocation.
Why Server-Side Tracking Fixes This
Server-side tracking addresses these problems at the root by moving conversion tracking off the browser entirely.
It bypasses ad blockers. When your server sends a purchase event to Meta via the Conversions API, the request goes from your server to Meta's API. It never passes through the visitor's browser. Ad blockers, which only intercept browser-level requests to known tracking domains, cannot see it.
It uses first-party cookies that persist. When your sGTM server runs on a subdomain of your own website (like data.yoursite.com), it sets cookies as first-party cookies from your domain. Safari's ITP applies to third-party cookies set by external scripts — not to first-party cookies. A first-party cookie from your own subdomain can persist for up to 400 days in Safari. The attribution chain that ITP breaks with client-side pixels stays intact with a server-side custom domain.
It captures the full user journey. Server-side tracking, combined with proper click ID capture (preserving fbclid and gclid from the initial ad click), maintains the link between the ad click and downstream conversions even when those conversions happen weeks later. The server has access to the stored click ID that the browser pixel would have lost.
It works regardless of what Chrome does next. Whether Chrome eventually proceeds with deprecation, introduces a user prompt, or stays the same, the server-side tracking setup is unaffected. You are not relying on browser-stored cookies for your critical conversion signals — you are relying on a server-to-server connection that no browser policy can interfere with.
The Current State: What Is Actually Blocked Right Now
To cut through the noise about Chrome reversals and future plans, here is what is actually happening to your tracking data today:
| Browser / Platform | Status | Estimated % of traffic affected |
|---|---|---|
| Safari (desktop + mobile) | Third-party cookies fully blocked. First-party cookies capped at 7 days via ITP. | ~20–25% globally, higher on Apple devices |
| iOS (all browsers) | ATT opt-in required. ~70–80% of users opt out. | ~15–20% of total web traffic |
| Firefox | Third-party cookies blocked by default | ~3–4% globally |
| Chrome (ad blockers) | Users with ad blockers — pixel events blocked | ~25–30% of desktop Chrome users |
| Chrome (no ad blocker) | Third-party cookies still work (for now) | Majority of remaining traffic |
Even in the most optimistic scenario for Chrome, roughly 30–40% of your total traffic is already in an environment where browser-based pixel tracking is broken or significantly degraded.
Getting Started
The practical path is a server-side Google Tag Manager (sGTM) setup with a custom subdomain. Once running, you move your key conversion tags — Meta CAPI, Google Ads Enhanced Conversions, GA4 — from the browser container to the server container. Events that were previously invisible start arriving at your ad platforms.
The server infrastructure is the part most marketers get stuck on. Firstag handles it — you get a running sGTM server on your custom domain in under 15 minutes, with no GCP setup required. You configure the tags inside the container yourself, but the server and scaling are managed.
For a deeper look at the mechanics, see How Server-Side Tracking Works. For the business case, see 7 Benefits of Server-Side Tracking.
FAQ
Did Google reverse the deprecation of third-party cookies in Chrome? Yes. In mid-2025, Google announced it would not proceed with a standalone full deprecation of third-party cookies in Chrome. Instead, it plans to introduce a user-facing prompt allowing users to set their preferences. Third-party cookies will remain functional in Chrome for users who do not opt out. However, Safari and Firefox already block them, iOS ATT has capped mobile tracking, and ad blockers affect a significant portion of Chrome desktop users — so the practical tracking gap remains large.
Are first-party cookies affected by these changes? It depends how they are set. First-party cookies set by your own server from your own domain are treated generously by Safari and other browsers. First-party cookies set by third-party scripts (like a tracking pixel setting a cookie on your domain via JavaScript) are subject to Safari's ITP restrictions and can expire in 7 days or less. Server-side tracking with a custom subdomain ensures your cookies are genuinely first-party.
Is server-side tracking legal? Server-side tracking is a technically neutral approach to data collection — whether it is legal depends on what data you collect, whether you have user consent, and your applicable privacy regulations. You still need a consent management platform and must respect user opt-outs. Server-side tracking does not make you compliant on its own, but it makes compliance easier to enforce at the server level.
If Chrome is not removing third-party cookies, why do I still need server-side tracking? Because the problem is not only Chrome. Safari's ITP, iOS ATT, and ad blockers already affect 30–40% of your traffic. A Chrome user with an ad blocker is just as invisible to your pixel as a Safari user. Server-side tracking addresses the full set of browser-level tracking limitations, not just the Chrome third-party cookie question.
What is the difference between third-party cookie deprecation and ad blockers? Third-party cookie deprecation is a browser-level policy that removes the ability to store cross-site identifiers in cookies. Ad blockers are browser extensions that intercept and drop outbound requests to known tracking domains. They are separate problems with the same solution: server-side tracking, which operates from your own subdomain and makes API calls from your server rather than the browser.
Conclusion
Third-party cookies built two decades of digital advertising. Safari blocked them in 2017. iOS ATT arrived in 2021. Firefox followed. Chrome reversed its full deprecation plan — but between Safari, iOS, and ad blockers, 30–40% of your traffic is already in a cookieless state.
The answer is not to wait and see what Chrome does next. The answer is to build your tracking infrastructure around something more durable: server-side tracking with a custom domain, first-party cookies that persist, and conversion events that reach your ad platforms regardless of what happens in the browser.
Start your Firstag container free for 14 days at firstag.io.