ITP History & Impact

Safari’s Intelligent Tracking Prevention is the single biggest reason server-side tagging exists. What started in 2017 as third-party cookie blocking evolved into restrictions that fundamentally changed how analytics data works for Safari users — which, depending on your audience, might be 20-50% of your traffic.

If your Safari users look like 70% new visitors when the actual retention rate is much higher, ITP is probably the cause. This article explains what ITP does, how it evolved, and what impact each version has on your data.

What ITP is trying to accomplish

ITP is Apple’s mechanism for preventing cross-site tracking — the practice of identifying the same user across multiple websites to build behavioral profiles, serve targeted ads, and track activity outside a single site’s context.

Apple’s concern is not with analytics in isolation. It is with the use of shared identifiers (third-party cookies, fingerprinting, redirect bouncing) to link user activity across unrelated sites without explicit consent. ITP targets the infrastructure that makes this possible.

The collateral damage — and this is important — is that legitimate first-party analytics also gets caught in the net. Your _ga cookie and _ga_XXXX cookie are used to identify returning users on your own site. ITP caps or restricts them because they are set by JavaScript, which is the same mechanism third-party trackers use.

ITP version history

ITP 1.0 (June 2017)

The first release targeted third-party cookies — cookies set by domains other than the one the user is currently visiting.

What changed: Domains identified as cross-site trackers had their third-party cookies partitioned or blocked entirely. Safari’s ML classifier identified tracker domains based on cross-site resource loading patterns.

Impact on GA4: Limited at the time. GA4 (and Universal Analytics) primarily used first-party cookies, which were unaffected.

ITP 1.1 (October 2017)

What changed: Tracker-classified domains had their cookies deleted if not actively used as a first party. The “storage access API” was introduced to give users a way to grant permission to specific cross-site scenarios.

ITP 2.0 (September 2018)

This was the major escalation. ITP 2.0 extended restrictions to include domains that receive bounced navigations — a technique used by some trackers to gain first-party status by briefly sending users through a tracker domain.

What changed:

Third-party cookies blocked entirely for classified domains (no grace period)
Bounce tracking protection: domains that users navigate to briefly but then bounce away from lose cookie access
document.referrer stripping to prevent referrer-based cross-site tracking

Impact on GA4: Still primarily limited to third-party contexts. First-party _ga cookies were not yet affected.

ITP 2.1 (February 2019)

ITP 2.1 was the turning point for analytics. For the first time, ITP imposed restrictions on first-party cookies set by JavaScript (document.cookie).

What changed: All first-party cookies set via JavaScript (document.cookie) are capped at a 7-day expiration. Regardless of the max-age or expires attribute you set in JavaScript, Safari will delete the cookie 7 days after it was last set.

Impact on GA4:

The _ga cookie is set by the GA4 JavaScript library via document.cookie
Before ITP 2.1: _ga had a 2-year lifetime
After ITP 2.1: _ga is deleted 7 days after the user’s last visit
A user who visited 8 days ago and visits again is treated as a new user
Returning user rates drop significantly; new user rates inflate

ITP 2.2 (April 2019)

ITP 2.2 went further, targeting sites that receive first-party navigations from classified tracker domains. The scenario: a user clicks an ad on a social media site (classified as a tracker), lands on your site, and your JavaScript-set cookies get the reduced expiry.

What changed: For sites that receive navigations from classified tracker domains, JavaScript-set cookies are capped at 24 hours (not 7 days) if the URL contains UTM parameters, click IDs, or other referral data that could be used for cross-site tracking.

Impact on GA4: Any user who arrives from an ad click (which contains fbclid, gclid, ttclid, etc.) gets a 24-hour _ga cookie instead of 7 days. Their second visit the next day is attributed to direct traffic rather than the original ad. Marketing attribution accuracy for Safari users drops substantially.

ITP 2.3 (September 2019)

ITP 2.3 closed the CNAME cloaking workaround. CNAME cloaking is a technique where a first-party subdomain (like analytics.yourdomain.com) is configured to point via DNS CNAME to a third-party analytics server. The theory: since the subdomain appears to be first-party, it bypasses third-party cookie restrictions.

What changed: Safari detects CNAME-cloaked domains and applies the same restrictions as regular third-party tracker domains. Specifically, cookies set by CNAME-cloaked origins are also capped at 7 days.

Impact: The CNAME workaround that some analytics vendors promoted as an ITP solution stopped working in Safari. Stape and other sGTM providers that route through a first-party domain via true server-side proxying (not CNAME) were not affected.

ITP 2.4 through iOS 16 (2020-2022)

ITP updates in this window closed specific workarounds without major new restrictions. The core cookie behavior set in ITP 2.1-2.3 stayed stable — 7-day cap for JavaScript-set first-party cookies, 24-hour cap for navigations from classified tracker domains with tracking parameters, CNAME cloaking detected, localStorage subject to the same caps as cookies.

iOS 17 / Safari 17 (September 2023) — Link Tracking Protection

iOS 17 introduced Link Tracking Protection (LTP), a new mechanism distinct from cookie caps. LTP strips known tracking parameters from URLs in specific contexts:

Safari Private Browsing mode (always-on)
Mail app links
Messages links

Parameters stripped include fbclid, mc_eid (Mailchimp), hsCtaTracking (HubSpot), and dozens of other vendor-specific click IDs. Apple maintains the list internally; it is not publicly documented.

Impact on GA4 in iOS 17: Limited initially. gclid, gbraid, wbraid, and utm_* parameters were NOT on the strip list. Meta’s fbclid being stripped affected Facebook/Instagram ad attribution in Private Browsing, but default Safari browsing was unaffected.

iOS 17.4 (March 2024) — Advanced Tracking & Fingerprinting Protection

iOS 17.4 extended Advanced Tracking and Fingerprinting Protection (previously limited to Private Browsing) to be toggleable for all Safari browsing. Users who enable it get fingerprinting protection across all tabs, not just private ones.

Impact on GA4: Limited directly, but compounds the fingerprinting gap for fallback identity stitching strategies that don’t rely on cookies.

iOS 18 / Safari 18 (September 2024) — LTP expansion

iOS 18 made Link Tracking Protection on by default for Safari in Private Browsing (previously it required the advanced protection toggle) and continued expanding the strip list. Distraction Control and other UI-level privacy features landed alongside, but the key measurement change was the LTP scope expansion.

Impact on GA4: Still limited for default (non-private) Safari. Private-browsing Safari sessions now routinely arrive with stripped click IDs.

iOS 26 / Safari 26 era (2025-2026) — GCLID and click-ID stripping expands

Stape and other sGTM vendors reported in 2026 that Safari’s parameter-strip list now includes Google Ads click identifiers (gclid, gbraid, wbraid) in expanded contexts — not just Private Browsing, but also Mail, Messages, and default Safari under Advanced Tracking and Fingerprinting Protection. Meta’s fbclid and TikTok’s ttclid are also stripped in broader contexts.

What this breaks:

Google Ads click-through attribution — when a Safari user clicks a Google Ads link, the landing URL reaches your site without gclid. Google Ads’ standard auto-tagging can’t tie the resulting session back to the ad click without additional signals.
Facebook/Meta Ads attribution — same problem with fbclid for Conversions API matching.
UTM parameters are still intact — Apple has (so far) not stripped utm_source, utm_medium, etc., so campaign-level channel reporting survives. Click-ID-dependent attribution is what breaks.

Impact on GA4 specifically:

Scenario	Safari (iOS 26 era)
`gclid` in landing URL	Stripped in Private Browsing, Mail, Messages, and default Safari with Advanced Protection
`fbclid` in landing URL	Stripped in more contexts than iOS 17
`utm_*` parameters	Still preserved
`_ga` cookie JS cap	Still 7 days (unchanged since ITP 2.1)
Server-set cookies	Still honored with full lifetime

Mitigations:

Server-side enhanced conversions: Pass hashed email / phone to Google Ads via the Conversions API, letting Google match the conversion to the original click without relying on gclid in the landing URL.
First-party data capture before redirects: Capture user identity (email, CRM ID) as early as possible in the journey, then pass it server-side so attribution can be rebuilt outside the browser.
sGTM first-party cookies: Continue to mitigate the 7-day _ga cap — the cookie story is unchanged.
Offline conversion import: Upload matched conversions to Google Ads from your backend when you have deterministic identity linkage.

Current state summary

As of 2026, Safari restrictions you need to plan around are:

Third-party cookies: Blocked entirely for classified domains
JavaScript-set first-party cookies: 7-day cap (24-hour cap if navigating from a classified tracker domain with tracking parameters)
localStorage / IndexedDB: Subject to the same caps as cookies for classified origins
CNAME cloaking: Identified and restricted
Link Tracking Protection: gclid, fbclid, ttclid, mc_eid, and similar click IDs stripped from URLs in Private Browsing, Mail, Messages, and default Safari under Advanced Tracking and Fingerprinting Protection
Fingerprinting protection: Canvas, WebGL, audio, screen APIs return simplified/noised values

The one exception that has not changed: Cookies set via HTTP Set-Cookie response headers from the actual first-party server are NOT subject to ITP caps. A cookie set by your server in a response header can have a 2-year lifetime and Safari will honor it. This is still the foundation of the server-side cookie solution — and it is now joined by server-side enhanced conversions as the foundation of the server-side attribution solution.

Specific impact on GA4 cookies

GA4 uses two main cookies set via JavaScript:

Cookie	Purpose	ITP impact
`_ga`	Identifies the client_id (user identifier)	7-day cap in Safari
`_ga_XXXXXXXX`	Stores session information	7-day cap in Safari
`_gac_XXXXXXXX`	Google Ads click attribution	7-day cap in Safari

The _ga cookie is the most critical. It is the persistent identifier that allows GA4 to recognize a returning user. With a 7-day cap, any Safari user who visits less frequently than weekly appears as a new user to GA4.

The measurement consequence: If your e-commerce site’s typical repurchase cycle is 30 days, nearly every returning customer appears as a new customer in GA4 for Safari users. Your “new vs. returning” breakdown is useless. Cohort analysis is broken for Safari. Lifetime value calculations are understated.

Diagnosing ITP impact in your data

You can directly measure the impact of ITP by comparing browser segments in GA4:

Create a custom segment for Safari users
Create a custom segment for Chrome users (least affected by ITP)
Compare new user rates, session-per-user averages, and returning user percentages between the two segments

If Safari shows a significantly higher new user rate than Chrome (and your site is not asymmetrically popular on Safari), ITP is inflating your new user count.

A useful diagnostic: compare the average sessions per user for Safari vs. Chrome users over a 90-day window. If the Safari average is dramatically lower, ITP is preventing Safari users’ return visits from being recognized.

The server-side solution

The fix for ITP’s JavaScript cookie cap is straightforward: set the _ga cookie via an HTTP Set-Cookie response header from your server instead of via JavaScript. Server-set cookies are not subject to ITP’s 7-day cap.

This is what server-side GTM’s GA4 client does. When a GA4 request passes through your sGTM server, the server can read the incoming _ga value and re-set it in the response headers with a full 2-year expiry. Even if ITP would otherwise cap the cookie, the server-set version survives.

The implementation is covered in detail in Extending Cookie Lifetimes and FPID Cookie Management.

Common mistakes

Assuming ITP only affects advertising, not analytics

Many teams focus on ITP’s impact on ad attribution and ignore its impact on analytics accuracy. The inflated new user counts and broken returning user analysis have significant consequences for product analytics, lifecycle marketing, and any analysis that depends on recognized returning users.

Using a 30-day look-back window for Safari attribution

If _ga is capped at 7 days, your GA4 attribution model has a de facto 7-day lookback window for Safari users regardless of your configured settings. Analyses that assume a 30-day lookback are overstating attribution accuracy for Safari.

Thinking CNAME cloaking is a valid workaround

ITP 2.3 specifically addressed CNAME cloaking. Any vendor or agency that is still recommending CNAME cloaking as an ITP solution is either uninformed or misleading you. True server-side proxying (where requests hit your actual server infrastructure) is the legitimate approach.

Extending Cookie Lifetimes Server-side cookie refresh patterns to work around ITP's JavaScript cookie caps.

FPID Cookie Management How sGTM's FPID cookie provides a server-set identifier that bypasses ITP restrictions.

Cross-Browser Tracking Differences How ITP compares to Firefox ETP, Brave, and Chrome's Privacy Sandbox in a single reference table.