Make confident, data-driven decisions with actionable ad spend insights.
© 2026 DataCops. All rights reserved.
15 min read
What’s wild is how consistently data disappears from our dashboards, yet almost nobody questions the infrastructure causing the leakage. Every time a user converts after eight days, they become an anonymous ghost in your analytics.
Orla Gallagher
PPC & Paid Social Expert
Last Updated
November 28, 2025
Most people blame the ad platforms. They blame a bad creative or a faulty pixel. They run tests, check their tags, and pull their hair out, all while the real culprit works silently in the background, built directly into the browser of millions of your most valuable customers.
Maybe this isn't about a single browser feature alone.
Maybe it says something bigger about how the modern internet works, who it's really built for, and the crumbling foundation upon which digital marketing has been built for the last decade. But if you look closely at your own analytics, at the strange behavior of your iOS and Mac user segments, you will start to notice it too. The data just feels wrong, incomplete, and untrustworthy. This is the Safari problem, and its name is Intelligent Tracking Prevention.
For years, marketers and analysts have been navigating a landscape that is quietly being reshaped by forces outside their control. ITP is arguably the most significant of these forces. Understanding it is not just a technical exercise; it is a prerequisite for survival in the modern data ecosystem.
Intelligent Tracking Prevention, or ITP, is a privacy feature developed by Apple and built into its WebKit browser engine. This means it affects Safari on iPhones, iPads, and Macs. Its stated purpose is to protect users from cross-site tracking by limiting the ways websites and third parties can store and access data on a user's device, primarily through cookies and other scripting capabilities.
It is not an ad blocker, though it has a similar effect on many tracking technologies. It is not a bug; it is a core, intentionally designed feature of the browser. Apple's goal is to make it difficult for companies like Meta, Google, and countless ad-tech vendors to build a detailed profile of a user's browsing habits across different websites. While the intention is user privacy, the collateral damage to analytics, attribution, and personalization has been immense.
To understand ITP, you have to understand the world it was built to dismantle. For over a decade, the internet ran on third-party cookies. When you visited news-site.com, a piece of code from ad-network.com would drop a cookie on your browser. Later, when you visited shoe-store.com, which also used ad-network.com, the ad network could read that same cookie. It knew the same person visited both sites.
Repeat this across thousands of websites, and the ad network could build an incredibly detailed picture of your interests, purchase intent, and browsing history. This powered the hyper-specific retargeting ads that seemed to follow you everywhere. It was powerful, effective, and from a user privacy perspective, deeply unsettling. The public backlash against this "surveillance capitalism" grew, and browser makers responded. ITP was Apple's first and most aggressive move in what has become a long war against cross-site tracking.
Many articles oversimplify ITP as just "blocking third-party cookies." The reality is far more nuanced and has evolved significantly over time. Its mechanisms are specifically designed to break common tracking techniques, and understanding them reveals why your data looks the way it does.
Initially, yes, but it quickly became much more. ITP now completely blocks third-party cookies by default. This means a cookie set by a domain other than the one in the user's address bar cannot be stored or read. This single change effectively broke most traditional cross-domain retargeting and attribution models overnight.
But the real challenge for marketers came when ITP started targeting first-party cookies, the very data storage mechanism that websites rely on for their own analytics and user experience.
This is the rule that causes the most confusion and data decay. ITP places a strict expiration date on first-party cookies that are created using client-side JavaScript (i.e., via document.cookie). If a user visits your site and a cookie like Google Analytics' _ga is set by the script running in their browser, ITP will automatically cap its lifespan at 7 days of browser use.
If that user returns to your site on the 8th day, the cookie is gone. To your analytics platform, they look like a brand new user. Their previous session, their original traffic source, and their place in a long conversion journey are all erased. This systematically underreports return visitors and inflates new user counts for your Safari audience.
ITP goes a step further for traffic coming from what Apple deems "tracking domains." When a user clicks an ad on Google or Facebook, the URL they land on often contains tracking parameters, like gclid (Google Click ID) or fbclid (Facebook Click ID).
ITP detects these parameters and recognizes that the user has been navigated from a known tracking domain. In this scenario, it shortens the expiry of all script-writable, first-party cookies to just 24 hours. A user who clicks a Facebook ad on Monday and returns on Wednesday to make a purchase will not be attributed to that ad click. The link is broken after a single day, making it nearly impossible to measure the delayed impact of your ad campaigns on Safari users.
"The browser vendors are in a constant cat-and-mouse game with the advertising industry. Every time a workaround for tracking is developed, the browsers respond with a more sophisticated countermeasure. Relying on clever hacks is not a sustainable data strategy; it's a race to the bottom." – Simo Ahava, Co-founder of 8-bit-sheep
To grasp the escalating nature of this "cat-and-mouse game," it helps to see how ITP has systematically dismantled tracking methods over the years.
ITP Version Key Restriction Impact for Marketers & Analysts
ITP 1.0 (2017) Third-party cookies usable for 24 hours after interaction, then partitioned. Initial disruption to basic retargeting.
ITP 2.0 (2018) Removed the 24-hour window. Third-party cookies blocked immediately. End of most third-party cookie based tracking on Safari.
ITP 2.1 (2019) Introduced 7-day expiry cap on client-side first-party cookies. Massive data decay. Return user tracking breaks after one week. Analytics tools see users as "new" every 7 days.
ITP 2.2 (2019) Introduced 24-hour expiry for cookies when referred from a tracking domain (link decoration). Attribution for paid ads (Google, Meta) breaks after 24 hours. Impossible to measure multi-day conversion journeys from ads.
ITP 2.3 & Beyond (2020+) Full third-party cookie blocking. CNAME cloaking detection and mitigation. The industry's primary workaround (CNAME cloaking) is now also targeted, applying the same 7-day/24-hour caps.
The technical rules of ITP trigger a cascade of failures across the entire marketing and analytics stack. These are not minor discrepancies; they are fundamental breakdowns in how we measure, understand, and engage with users.
This is the most immediate and painful symptom. Marketing attribution models rely on connecting a conversion event (like a purchase) back to the marketing touchpoints that influenced it. This connection is made using cookies.
The 24-Hour Cliff: A user clicks a Facebook ad for your product on Tuesday. They think about it, do some research, and come back to your site directly on Thursday to buy. Because of ITP's 24-hour rule for link decoration, the cookie linking them to the Facebook ad expired on Wednesday. In your reports, this purchase is attributed to "Direct" traffic. Your Facebook campaign gets zero credit, your reported ROAS (Return on Ad Spend) plummets, and you might incorrectly decide to cut budget from a channel that is actually working.
The 7-Day Amnesia: A user discovers your blog through organic search. They visit a few times over a two-week period before finally signing up for your newsletter. Because of the 7-day cap, their original cookie expired. The conversion is attributed to their final visit, not the original organic search that brought them in. You lose visibility into the top of your funnel.
Effective marketing relies on understanding user behavior over time. You want to segment users into groups like "new visitors," "repeat customers," "cart abandoners," or "highly engaged readers."
ITP poisons this process. With cookies expiring every 7 days, your "new visitor" segment becomes massively inflated with Safari users who are actually loyal, returning visitors. Your ability to build a long-term behavioral profile of a user is destroyed. You cannot reliably distinguish a truly new user from a returning one whose tracking cookie just expired. Personalization engines fail because they cannot recognize the user to show them a tailored experience.
Running a reliable A/B test requires user consistency. When a user is placed in the "B" variant of a test, they need to remain in that variant for the duration of their visit and any subsequent visits until the test concludes.
With ITP, a user on Safari might see the "B" variant of your homepage on Monday. They return 8 days later, their cookie is gone, and they are now served the "A" (control) variant. This "crossover" contaminates your test results, making it impossible to trust the outcome. You might conclude that your new design had no impact when, in reality, your data was too polluted to measure it correctly.
In response to ITP, a number of workarounds have emerged. However, most of these are temporary fixes that Apple has already begun to counteract, leaving businesses that rely on them in a precarious position.
Server-side tagging, often implemented via Google Tag Manager's server container, is a step in the right direction. Instead of sending data directly from the user's browser to Google, Meta, etc., the data is first sent to a server that you control. This server then forwards the data to the various marketing platforms.
A key benefit is the ability to set cookies from the server (via HTTP response) instead of client-side JavaScript. Cookies set this way are not subject to the 7-day ITP cap and can have a much longer lifespan.
However, this is not a complete solution.
Complexity and Cost: Setting up and maintaining a server-side tagging environment requires significant technical expertise and ongoing server costs.
The Third-Party Endpoint Problem: By default, a GTM server container runs on a domain like gtm-server.appspot.com. This is a Google-owned domain. When your website sends data to this endpoint, the browser still sees it as a third-party request. This can be flagged by browsers and ad blockers. The core problem of third-party trust remains.
To solve the third-party endpoint problem, the industry adopted a technique called CNAME cloaking. This involves creating a subdomain on your own website (e.g., analytics.yourdomain.com) and using a CNAME DNS record to point it to the third-party server (like the GTM server or another vendor's endpoint).
To the browser, it looks like data is being sent to a first-party subdomain. For a while, this worked. It tricked ITP into treating the data stream as first-party.
However, Apple is not standing still. The latest versions of ITP now include CNAME cloaking detection. WebKit can perform a DNS lookup to see if a subdomain is just an alias for a known third-party tracking domain. If it detects a CNAME record pointing to a tracker, it applies the exact same 7-day and 24-hour cookie restrictions, neutralizing the workaround entirely.
The constant battle against ITP's restrictions reveals a fundamental truth: workarounds are not a strategy. The only sustainable solution is to move from faking a first-party context to establishing true first-party data ownership.
CNAME cloaking is an attempt to create a "first-party context." It is a disguise. The data is still being handled by a third-party server that is merely wearing your subdomain as a mask. The underlying infrastructure, scripts, and data processing are all third-party.
"First-party ownership," the approach taken by platforms like DataCops, is fundamentally different. It is not about masking a third-party endpoint. It is about making the data collection mechanism itself genuinely first-party.
The solution lies in changing not just where the data is sent, but where the tracking script itself comes from. In a true first-party setup, you use a CNAME record (analytics.yourdomain.com) to point to a dedicated data collection infrastructure.
Crucially, this infrastructure then serves the tracking JavaScript from that same subdomain. When the browser requests the script, it sees a request for https://analytics.yourdomain.com/script.js. This is an unambiguous, undeniable first-party request. The script is originating from your own domain space.
Because the script is served from a true first-party origin, and the cookies are set by that script for the same domain, they are treated as legitimate first-party data by the browser. They are not subject to ITP's 7-day or 24-hour caps. This restores the integrity of your data collection for all users, including those on Safari.
The differences in approach have a direct impact on data quality and resilience.
Method How It Works ITP Vulnerability Data Integrity
Client-Side GA4/Tags
Scripts from googletagmanager.com run in browser, set cookies via document.cookie.
High. All cookies subject to 7-day or 24-hour expiry. Data sent to third-party domains is easily blocked.
Poor. Broken attribution, inflated new user counts, unreliable long-term analysis.
Server-Side GTM (Standard)
Data sent to a appspot.com server endpoint. Can set HTTP cookies.
Medium. HTTP cookies avoid the 7-day cap, but the endpoint is third-party and can be blocked. Link decoration still triggers 24-hour cap if not properly managed.
Moderate. Better than client-side, but still vulnerable and complex. Data quality depends heavily on implementation.
DataCops (True First-Party) CNAME points to DataCops. Scripts are served from your subdomain. Cookies are set in a true first-party context. Low. Bypasses ITP's client-side cookie caps and CNAME cloaking detection. Establishes a trusted, first-party data stream. High. Complete and accurate session tracking, reliable attribution, and long-term user analysis are restored.
"The goal is to turn data into information, and information into insight. But what if the data is flawed from the start? Garbage in, garbage out isn't just a cliché; it's the reality for companies that don't prioritize data integrity. You can't make billion-dollar decisions on million-dollar data that's only ten cents accurate." – Avinash Kaushik, Digital Marketing Evangelist and Author
The "Safari problem" is the canary in the coal mine. ITP is just one part of a much larger industry shift toward privacy that includes Google's impending phase-out of third-party cookies in Chrome, increasing use of ad blockers, and stringent privacy regulations like GDPR and CCPA.
Solving for ITP is critical, but a truly resilient data strategy must look beyond it.
Even if you successfully capture every user session, your data can still be wrong. The internet is flooded with non-human traffic: bots, scrapers, click fraud, and users hiding behind VPNs or proxies. This traffic inflates your visitor counts, skews engagement metrics, and leads to wasted ad spend.
A complete data solution does not just capture data; it cleans it. Advanced systems like DataCops incorporate fraud detection to identify and filter out bot traffic, VPNs, and other sources of data pollution. This ensures that the data you send to your analytics tools and ad platforms represents real, human users, giving you a true picture of performance.
In the age of GDPR and CCPA, data collection and user consent are inseparable. You cannot have one without the other. Many companies bolt on a third-party Consent Management Platform (CMP) to their site, which creates yet another point of failure and another third-party script to manage.
A modern, integrated approach combines first-party data collection with a first-party consent model. A TCF-certified CMP that is part of the core data collection platform ensures that you are not only collecting data correctly but are doing so in full compliance with global privacy laws. This builds trust with both users and regulators. This forms the foundation of a modern data stack, a topic we explore further in our guide to first-party data strategies.
For too long, we have been treating the symptoms of a broken system. We have chased workarounds, patched together fragile solutions, and watched as our data became less and less reliable. The frustration you feel when looking at your Safari analytics is justified. It is the feeling of trying to build a house on shifting sand.
Intelligent Tracking Prevention is not the problem. It is a symptom of the internet's inevitable move away from a model based on third-party surveillance. The era of borrowing data from other platforms and renting space in users' browsers is over.
The solution is not a more clever hack to trick Safari for another six months. The solution is a fundamental shift in perspective. It is about moving from a world of third-party dependencies to one of first-party ownership. It is about building a data infrastructure that is resilient by design, that prioritizes integrity and compliance from the ground up, and that you truly control.
The question is no longer if you should take control of your data, but how. The future of digital analytics and marketing belongs to those who own their data pipeline, from the first click to the final conversion.
