Apple ITP and link tracking protection: what marketers need to know
Safari's Intelligent Tracking Prevention and iOS 17's Link Tracking Protection strip ad click identifiers from URLs. Here's what gets removed, what survives, and what it means for attribution.
2026-03-07
Safari has blocked third-party cookies since 2017. Most marketers adjusted - reluctantly - and moved on. What is less well understood is that Apple has since gone further, and the changes introduced in iOS 17 and Safari 17 in 2023 affect attribution in ways that third-party cookie blocking did not.
This guide covers Intelligent Tracking Prevention (ITP), the newer Link Tracking Protection feature, and what both mean for your measurement setup.
Intelligent Tracking Prevention: the background
ITP is Safari's anti-tracking system. It uses on-device machine learning to identify domains that act as trackers - serving resources across many unrelated sites - and restricts how those domains can use storage in the browser. The key practical effects for marketers:
- Third-party cookies are blocked entirely. Any cookie set by a domain other than the one the user is visiting is unavailable. This has been the case since ITP 2.0 in 2018.
- First-party cookies set via JavaScript are capped at seven days. If your site sets a cookie using
document.cookie(as many analytics scripts do), Safari will delete it after seven days. This affects GA4's_gacookie and similar identifiers. - First-party cookies set via HTTP headers are capped at seven days too in some configurations, though the exact rules depend on ITP's classification of the referring domain.
For GA4 specifically, the seven-day cap means returning visitors who come back after a week appear as new users. Session counts are inflated, conversion attribution can break, and cohort analysis becomes unreliable for any window longer than a week.
Link Tracking Protection: the newer issue
iOS 17 and Safari 17, released in September 2023, added Link Tracking Protection. This feature strips known tracking parameters from URLs when they are opened in Safari's Private Browsing mode, and in some contexts in regular browsing when the link comes from a Mail or Messages thread.
The parameters stripped include:
| Parameter | Used by |
|---|---|
gclid | Google Ads (click identifier for conversion tracking) |
fbclid | Meta Ads (click identifier for attribution) |
msclkid | Microsoft Ads |
twclid | X (formerly Twitter) |
mc_eid | Mailchimp |
igshid |
utm_ parameters - the utm_source, utm_medium, utm_campaign values that most marketers use for campaign tracking - are not stripped. Standard UTM attribution continues to work.
What does get stripped is the click-level identifier that platforms use for their own attribution. When gclid is absent from a landing page URL, Google Ads cannot match the click to a conversion. The platform does not know the click happened via that specific ad. The conversion either drops out of reporting entirely or is attributed via a less precise method.
How widespread is the impact?
Safari's market share varies by region and audience. In the UK, Safari accounts for roughly 35–40% of browser usage, skewed towards mobile. Among iPhone users - who use Safari by default - these restrictions apply to everyone running iOS 17 or later.
Private Browsing use is growing, though it remains a minority of sessions. The exact proportion of your traffic affected depends on your audience. Sites with a high proportion of Apple device users in European markets should expect meaningful attribution gaps.
What to do about it
There is no single fix, but several approaches reduce the impact:
Switch to server-side tagging for Google Ads conversion tracking. If conversion data is sent from your server to Google rather than from the browser, the gclid stripping does not apply - the click ID is stored server-side before the browser strips it from the URL. This requires a more involved technical setup but is increasingly the recommended approach for accurate Google Ads measurement. See our guide on server-side tagging and consent for more on how this works.
Use enhanced conversions. Google's enhanced conversions allow you to send hashed first-party data (email address, phone number) alongside conversion events. This gives Google a second route to match conversions to ad clicks even when gclid is unavailable.
Rely on UTM parameters for your own analytics. Since UTMs survive Link Tracking Protection, your GA4 campaign reports based on UTM data remain intact. The gap is in platform-side attribution (what Google Ads or Meta reports as conversions), not in your own source/medium reporting.
Set cookies via HTTP headers where possible. A cookie set in an HTTP response header is treated differently by ITP than one set via JavaScript. If your analytics or tagging setup allows server-set cookies, this extends the storage window beyond what client-side scripts get.
The consent angle
ITP and Link Tracking Protection are not consent mechanisms. They operate at the browser level regardless of what the user chose on a cookie banner. A user who accepted all cookies on your site still has their gclid stripped by Safari if they opened the link from a Mail app thread on iOS 17.
This is worth making clear internally, because the two are often conflated. GDPR consent controls what your site does. Apple's tracking restrictions control what the browser does. Both affect attribution, but separately.
What the consent mechanism does affect is what data your tags can collect once the user is on your site. If a user declines analytics, GA4 does not fire. If they accept, GA4 fires - but the _ga cookie Safari sets for it may still expire in seven days. Both constraints apply at once.
Where ConsentScout fits
ConsentScout scans sites from a headless Chromium browser, not Safari, so it does not simulate ITP or Link Tracking Protection behaviour directly. What it does show is whether your consent setup is working correctly on first load - which is a prerequisite for any measurement to work at all.
A site that sets analytics cookies before consent is given will have those cookies stripped by ITP faster than cookies set legitimately via a proper consent flow (because ITP is more aggressive with cookies from classified tracker domains). Getting consent right and getting ITP-resilient attribution right are separate problems, but solving the first is a reasonable place to start.