Why Tracking Broke
ITP, consent, cookie loss.
Why Tracking Broke is a free Digital Marketing Academy lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Digital Marketing Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
The Old Tracking Model
For a decade, marketing measurement relied on a simple trick: drop a third-party cookie from an ad platform's domain, then read it across millions of sites. This let advertisers stitch a user's behavior into a single cross-site profile.
Client-side JavaScript fired pixels directly from the browser to Google, Meta, and others. It was easy to deploy and powerful, but it leaked everything to third parties with little user control.
Safari ITP Lands First
In 2017 Apple shipped Intelligent Tracking Prevention (ITP) in Safari. It used on-device machine learning to classify domains as trackers and then blocked or partitioned their cookies.
Later ITP versions capped client-side (document.cookie / JavaScript-set) cookies to a 7-day lifetime, and just 24 hours when the user arrived via a known tracker's link. Long-lived attribution windows quietly collapsed.
ITP cookie lifetime caps (Safari)
--------------------------------------
Server-set (HTTP) cookie ........ honored
JS-set cookie (document.cookie) . 7 days
JS cookie + tracker referrer .... 24 hours
Third-party cookie .............. blocked
Impact: 30-day attribution window
-> truncated to 7 days for many usersFirefox and Brave Follow
Firefox enabled Enhanced Tracking Protection (ETP) by default, blocking known third-party tracking cookies using the Disconnect list. Brave shipped aggressive blocking out of the box.
Across these browsers, third-party cookies were effectively dead years before Chrome announced any change. Measurement teams saw rising discrepancies between ad-platform reported conversions and backend reality.
Chrome and the Long Goodbye
Chrome holds the majority of global browser share, so its plans matter most. Google repeatedly delayed full third-party cookie deprecation, then in 2024 pivoted to a user-choice prompt instead of a forced removal.
Regardless of the exact timeline, the strategic signal is clear: do not architect measurement around third-party cookies. They are a deprecating asset.
Why Discrepancies Appeared
When cookies expire early or get blocked, returning users look like new users. Conversions can no longer be tied back to the original ad click, so platforms under-report.
At the same time, modeled and estimated conversions inflate other numbers. The result is two sources of truth that no longer agree, eroding trust in every dashboard.
Symptom checklist: tracking is broken
--------------------------------------
[ ] GA4 sessions spike, users flat (re-cookie)
[ ] Ad platform conv > backend orders
[ ] Attribution skews to last-click brand
[ ] Safari/iOS users show 'direct' traffic
[ ] Remarketing audiences shrinkingBrowser Storage Partitioning
Beyond cookies, browsers now partition storage by top-level site. A tracker's localStorage on site A is isolated from the same tracker on site B.
This kills the shared-identifier trick that survived cookie blocking. Even fingerprinting is being actively suppressed, with Safari and Firefox adding noise and Chrome's Privacy Sandbox proposing aggregated APIs instead.
App Tracking Transparency
On mobile, Apple's App Tracking Transparency (ATT) forced apps to ask permission before accessing the IDFA advertising identifier. Most users declined.
This devastated mobile app install attribution and audience targeting, pushing the industry toward aggregated, privacy-preserving frameworks like SKAdNetwork and toward server-side, consented data.
ATT prompt outcome (typical industry)
--------------------------------------
Opt-in rate ............ ~20-30%
IDFA available ......... only if opted in
Fallback ............... SKAdNetwork
- postbacks, no user-level data
- coarse conversion values
- delayed, aggregated reportingAd Blockers and Network Filters
A large share of users run ad blockers or privacy DNS that block requests to known analytics and ad domains. A client-side pixel firing to google-analytics.com or facebook.com is trivially filtered.
This means even consented, legitimate measurement is lost simply because the request never leaves the browser. Routing through your own domain becomes a reliability fix, not just a privacy one.
Regulation Adds Pressure
GDPR, ePrivacy, and similar laws require a lawful basis and, for most tracking, prior consent. Enforcement actions against Google Analytics in several EU countries questioned transferring data to US servers.
So the breakage is double: technical blocking by browsers, plus legal requirements that demand consent, data minimization, and control. You cannot solve one without the other.
First-Party Context Survives
One thing browsers still trust: cookies and storage set by the site the user is actually visiting (the first party). HTTP-only, server-set first-party cookies escape the harshest ITP caps.
This is the foundation of the modern stack. Move identity and event collection into your own domain and server, then forward consented data to platforms. That is server-side tracking.
First-party vs third-party trust
--------------------------------------
User visits: shop.example.com
FIRST PARTY (.example.com) -> trusted
set-cookie via server (HttpOnly)
longer lifetime, ITP-friendlier
THIRD PARTY (adnetwork.com) -> blocked
cookie partitioned/droppedThe Strategic Shift
The takeaway is not a single workaround but an architecture change. Stop relying on the browser to be your data pipeline to third parties.
Instead: collect first-party, gather explicit consent, send signals from your server, and accept that some measurement will be modeled rather than deterministic. The next lessons build exactly this stack.
Quick Check
Test your understanding of why tracking broke.
Recap
Tracking broke from two directions: browsers (ITP, ETP, storage partitioning, ATT) blocked and shortened third-party identifiers, and ad blockers stopped client-side pixels from firing at all. Regulation added a consent requirement on top.
The durable response is first-party, consented, server-side data collection. Third-party cookies are a deprecating asset, so the rest of this course builds the modern privacy-resilient stack.
Frequently asked questions
Is the “Why Tracking Broke” lesson free?
Yes — the full text of “Why Tracking Broke” is free to read here on the web, and the Digital Marketing Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Digital Marketing Academy course, upgrade to CoddyKit PRO.
What will I learn in “Why Tracking Broke”?
ITP, consent, cookie loss. You practise Digital Marketing Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Digital Marketing Academy?
No prior experience is required. Digital Marketing Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Why Tracking Broke” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Digital Marketing Academy lesson?
Yes. Every Digital Marketing Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Why Tracking Broke
- Server-Side Tagging
- Consent Mode and CMPs
- First-Party Data Strategy