---
title: "The state of cookies and tracking in 2026"
description: "What actually changed — and what did not For years the industry prepared for Chrome to switch off third-party cookies. That did not happen. In 2025…"
url: https://optimizeall.com/learn/privacy-first-measurement/state-of-tracking-2026
updated: 2026-10-05
---

Privacy-First Measurement: Server-Side Tagging, Consent Mode and Conversion APIs · The tracking landscape and privacy law · lesson 1 of 14 · 8 min

# The state of cookies and tracking in 2026

## What actually changed — and what did not

For years the industry prepared for Chrome to switch off third-party cookies. That did not happen. In 2025 Google announced it would keep its current approach to third-party cookie choice in Chrome (users can block them in settings; they are blocked by default in Incognito) rather than deprecating them or rolling out a new standalone prompt. In October 2025 Google then retired most Privacy Sandbox technologies — including the Attribution Reporting API, Topics, Protected Audience and IP Protection — citing low adoption, while continuing to support a few that had broad adoption such as CHIPS (partitioned cookies) and FedCM (federated login). Check Google's Privacy Sandbox site for the current list.

So why does privacy-first measurement still matter? Because **third-party cookies were only one piece**. Measurement is eroding from many directions at once:

| Force | Effect on measurement |
|---|---|
| **Consent requirements** (GDPR/ePrivacy in the EU, UK GDPR/PECR, KSA PDPL and others) | Tags must not set non-essential cookies or read device data without valid consent; refusals mean fewer observed conversions |
| **Safari Intelligent Tracking Prevention (ITP)** | Blocks third-party cookies; limits the lifetime of some script-set first-party cookies; strips known click identifiers in some contexts (Link Tracking Protection) |
| **Firefox Total Cookie Protection** | Partitions cookies per site by default |
| **Apple App Tracking Transparency (ATT)** | Apps need permission to track across other companies' apps and sites; many users decline |
| **Ad blockers and privacy extensions** | Block common tag domains and scripts |
| **Cross-device journeys** | Phone ad, laptop purchase — hard to connect without login |
| **Regulatory enforcement** | Fines and orders for unlawful tracking, pixels leaking sensitive data (health, finance) |

The result: **client-side, browser-only tags see a shrinking and biased slice of reality**, and in many markets you are not allowed to fire them at all before consent.

## Client-side vs server-side vs modeled

Think of measurement in three layers:

1. **Observed, client-side** — browser tags (Google tag, Meta Pixel, TikTok Pixel, LinkedIn Insight Tag). Easy, rich context, most vulnerable.
2. **Observed, server-side** — your server (or a server-side tag container) sends events to platforms: Meta Conversions API, Google enhanced conversions and offline imports, TikTok Events API, LinkedIn Conversions API. More durable, more control, still subject to consent.
3. **Modeled and aggregated** — Consent Mode modeling, platform conversion modeling, marketing mix models, lift tests. Fill gaps statistically without tracking individuals.

A privacy-first stack uses all three **lawfully**. Server-side is not a way around consent; it is a way to be accurate, efficient and in control of what data leaves your systems.

## First-party context is the new foundation

- **First-party cookies set by your server** (HTTP response headers from your own domain) are more durable than cookies written by JavaScript in Safari.
- **Logged-in users and CRM identifiers** allow matching with hashed email/phone — with consent where required.
- **Click identifiers** (gclid, gbraid/wbraid, fbclid, ttclid, li_fat_id) in landing URLs help attribute clicks; capture and store them with the lead or order.

## Worked example: a Dubai fashion e-commerce site

Audit findings (illustrative): the site fired Meta and TikTok pixels before the cookie banner was answered; Safari users showed very short return-visitor windows; ad platforms reported far fewer purchases than Shopify recorded.

Plan:

1. Fix consent gating so tags respect choices (and document the lawful basis per purpose).
2. Implement Google Consent Mode v2 (advanced) and a CMP with regional behavior.
3. Add a server-side tagging container on a first-party subdomain; send GA4, Google Ads, Meta CAPI and TikTok Events API from it with deduplication.
4. Capture click IDs and hashed email at checkout (with notice and consent where required) for enhanced matching.
5. Use modeled conversions and quarterly lift tests to cover what remains unobserved.

## Hands-on: a 15-minute tracking reality check

```text
1. Open your site in a fresh Chrome profile. DevTools > Application > Cookies.
   Before touching the banner: which cookies exist? Any _ga, _fbp, _ttp, _gcl_au? (They should not, if consent is required.)
2. DevTools > Network, filter "collect|tr|events|analytics". Which requests fire before consent?
3. Accept all. Re-check cookies and requests. Reject all in a new profile. Compare.
4. Repeat in Safari (Develop menu > Web Inspector). Note cookie expiry dates set by JavaScript vs by your server.
5. Compare last month: backend orders vs GA4 purchases vs each platform's purchases. Write down the gaps.
```

## Pitfalls

- Believing "cookies are back so nothing changed".
- Treating server-side tagging as a consent workaround — regulators disagree.
- Ignoring sensitive-data leakage (URLs containing health conditions, emails in query strings).

## How to measure success

A documented gap analysis (backend vs analytics vs platforms), zero non-essential tags before consent where consent is required, and a roadmap to close the gap lawfully.

## Video lecture: The state of cookies and tracking in 2026

Lecture coming soon · 14 chapters · about 9 minutes. Read the full transcript below.

1. The state of tracking in 2026
2. Why it matters
3. Chrome and Privacy Sandbox
4. Seven forces
5. Shrinking and biased
6. Simple example: Karachi electronics (illustrative)
7. Three layers
8. Not a consent workaround
9. First-party foundation
10. Example: Dubai fashion site (illustrative)
11. Your 15-minute check
12. Mistakes + try this now
13. Watch me do it: reality check (illustrative)
14. Recap and next step

## Lecture transcript

### The state of tracking in 2026

For five years, marketers were told that third-party cookies were about to die in Chrome. Then, in twenty twenty-five, Google changed course and kept them, with user choice. So can we all relax? Not at all. In this lecture you'll learn what actually changed, the seven forces still eroding your measurement, the three layers of a privacy-first measurement stack, and a fifteen-minute check that shows you how much your own tracking is missing.

### Why it matters

Why does this matter? Because every automated ad system, every attribution report and every budget decision rests on the data your tags collect. Here's an analogy. Imagine a shop with a door counter that only counts people wearing red. For years most people wore red, so the counter was roughly right. Now more and more people wear blue: they declined consent, they use Safari, they block scripts, they switch devices. The counter still ticks, but it's counting a smaller and different crowd. If you plan staffing from that counter, you'll get it wrong. Privacy-first measurement is about counting the whole crowd lawfully, or estimating it honestly.

### Chrome and Privacy Sandbox

First, the facts. In twenty twenty-five Google announced it would keep its current approach to third-party cookies in Chrome. Users can block them in settings, and they're blocked in Incognito, but there's no forced deprecation. Then in October twenty twenty-five, Google retired most Privacy Sandbox technologies, including the Attribution Reporting API, Topics and Protected Audience, while continuing a few with broad adoption, like CHIPS and FedCM. Always check Google's Privacy Sandbox site for the current list.

### Seven forces

So why does this course exist? Because cookies were only one piece. Consent laws in Europe, the UK, Saudi Arabia and elsewhere mean many tags can't fire before a user agrees. Safari's Intelligent Tracking Prevention blocks third-party cookies and limits some first-party cookies set by JavaScript. Firefox partitions cookies by site. Apple's App Tracking Transparency means many app users decline tracking. Ad blockers stop common tag scripts. People switch devices. And regulators fine companies whose pixels leak sensitive data.

### Shrinking and biased

The result is that browser-only tags see a shrinking and biased slice of reality. Biased is the important word. The people you can't observe aren't random. They're more likely to use Safari, to decline consent, or to buy on a different device. So a platform optimizing only on observed conversions is learning from a skewed sample. That's why accuracy is a performance issue, not just a reporting issue.

### Simple example: Karachi electronics (illustrative)

Here's a simple worked example. A small Karachi electronics store checks last month's numbers. The store backend shows one thousand orders. GA4 shows seven hundred and twenty purchases. Meta shows five hundred and eighty. Before doing anything else, they break down the gap. Safari and in-app browsers make up a large share of their traffic. Their cookie banner blocks tags until consent, and many visitors decline. And some buyers see an ad on their phone and buy on a laptop. None of this means the ads don't work. It means the observed data is partial and biased, and the fixes are different for each cause. These numbers are illustrative.

### Three layers

Think of a privacy-first stack as three layers. Layer one, observed client-side: browser tags like the Google tag and the Meta Pixel. Easy and rich in context, but the most vulnerable. Layer two, observed server-side: your server sends events to platforms, through the Meta Conversions API, Google enhanced conversions, the TikTok Events API and the LinkedIn Conversions API. More durable, more control. Layer three, modeled and aggregated: consent mode modeling, conversion modeling, mix models and lift tests.

### Not a consent workaround

Let me be very clear on one point. Server-side tracking is not a way around consent. If a user says no to advertising cookies, sending their data server-side for advertising purposes is still a problem, and regulators have said so. Server-side is about accuracy, efficiency and control over what data leaves your systems. The legal basis follows the purpose and the data, not the technical route.

### First-party foundation

The foundation of the new stack is first-party context. Cookies set by your own server in HTTP responses are more durable than cookies written by JavaScript in Safari. Logged-in users and CRM identifiers let you match with hashed email or phone, with consent where required. And click identifiers in your landing URLs, like gclid, fbclid and ttclid, should be captured and stored with the lead or order, so you can attribute and upload conversions later.

### Example: Dubai fashion site (illustrative)

Here's an illustrative audit. A Dubai fashion site fired Meta and TikTok pixels before the cookie banner was answered. Safari visitors appeared as new users every few days. And the ad platforms reported far fewer purchases than Shopify. The plan: fix consent gating, implement Consent Mode version two with a proper consent platform, add a server-side container on a first-party subdomain, capture click IDs and hashed email at checkout with notice, and use modeling and lift tests for the rest.

### Your 15-minute check

Now your fifteen-minute reality check. Open your site in a fresh browser profile and look at cookies before touching the banner. Watch the network panel for tag requests firing before consent. Accept all, then reject all in another profile, and compare. Repeat in Safari and note cookie expiry dates. Then compare last month's backend orders with GA4 and each ad platform. Write down the gaps. That gap is your roadmap.

### Mistakes + try this now

Let's name the common mistakes. Believing that because Chrome kept third-party cookies, nothing changed. Treating server-side tracking as a way around consent. Leaving pixels firing before the banner is answered. Ignoring what's hidden in URLs, like email addresses in query strings or health terms in paths. And trying to close the gap with fingerprinting, which regulators treat as needing consent anyway. Try this now: open your site in a private window, don't touch the banner, and check the network panel for requests to ad or analytics domains. If anything fires, write it down. That's your first compliance fix.

### Watch me do it: reality check (illustrative)

Watch me do it. I'll run the fifteen-minute reality check on an illustrative Abu Dhabi furniture site, narrating what I see. I open a fresh browser profile and load the home page without touching the banner. In the application tab, I see an underscore g a cookie and an underscore f b p cookie already set. That's a problem: analytics and the Meta pixel fired before consent. In the network tab, filtered for collect and tr, I see requests to Google Analytics and to Meta, both before any choice. I click reject all, visit a product page, and the Meta requests continue. Now I know the banner is decorative. Next I open Safari, accept all, and inspect cookies: underscore g a is set by JavaScript with a long expiry, but I know Safari may cap script-set cookies, so returning visitors will look new sooner. Finally, the numbers: last month the store recorded eight hundred orders, GA4 six hundred and ten, Meta four hundred and ninety. I write my gap analysis in three sentences: pre-consent firing to fix immediately, no server-side events, and Safari durability. That's a roadmap, built in fifteen minutes.

### Recap and next step

Recap. Chrome kept third-party cookies, but consent, browsers, Apple, blockers and cross-device journeys still erode measurement, and the missing data is biased. Build three layers: client-side, server-side and modeled, all lawful. Anchor on first-party context. Your next step: run the fifteen-minute check on your own site and write a one-paragraph gap analysis. The rest of this course shows you how to close it.

## Key takeaways

- Chrome kept third-party cookies with user choice, and most Privacy Sandbox APIs were retired in Oct 2025 — but measurement still erodes from consent, Safari/Firefox, ATT, blockers and cross-device journeys.
- Use three layers: client-side observed, server-side observed, and modeled/aggregated measurement.
- Server-side tracking improves accuracy and control but is never a consent workaround.
- Server-set first-party cookies, login identifiers and stored click IDs are the new foundation.
- Start with a gap analysis: backend vs analytics vs platforms.

## Try it

Run the 15-minute tracking reality check on your site and write a one-paragraph gap analysis comparing backend orders, analytics and each ad platform.

- [Next: Privacy laws for marketers: EU, UK, US, KSA and UAE](https://optimizeall.com/learn/privacy-first-measurement/privacy-laws-for-marketers)
- [All lessons of Privacy-First Measurement: Server-Side Tagging, Consent Mode and Conversion APIs](https://optimizeall.com/learn/privacy-first-measurement)