Safari Decided For Your Visitors Years Ago

Roughly one in five page views worldwide happens in Safari, and on US mobile the share is far higher because every iPhone ships with it. On all of those visits, Intelligent Tracking Prevention (ITP) is already running. There's no setting for your visitors to turn on and no prompt for them to accept. Apple made the call, it applies to everyone, and it changes what your analytics and ad tags can actually do.

ITP isn't a bug or an edge case you can engineer around. It's WebKit policy, and understanding it precisely is the difference between reading your Safari numbers correctly and quietly misattributing half of them. This is the marketer's version: what ITP blocks, what it caps, and where it leaves your measurement.

Every Third-Party Cookie Is Gone

Start with the biggest change. WebKit's tracking prevention policy states that ITP "by default blocks all third-party cookies. There are no exceptions to this blocking." A cross-site pixel or ad cookie set from a domain that isn't the one in the address bar simply doesn't get read or written in Safari.

The only sanctioned way back in is the Storage Access API, where an embedded frame explicitly asks the user for permission to use its cookies in that first-party context. For most advertising and analytics tags, that path isn't available, so third-party cookies in Safari are effectively finished. This is the same direction other browsers took, so treat it as the baseline, not a Safari quirk. See First-Party vs Third-Party Cookies for the underlying distinction.

The Seven-Day Cap On Script-Written Storage

First-party cookies survive in Safari, but not all of them, and not for as long as you set. The rule that trips up most measurement setups is this: ITP "deletes all cookies created in JavaScript and all other script-writeable storage after 7 days of no user interaction with the website."

That covers more than cookies. It applies to IndexedDB, LocalStorage, SessionStorage, Service Worker registrations, and cached data. So the key question for any identifier is where it was written:

Written by JavaScript (via document.cookie, which is how nearly every analytics and ad tag stores its ID): capped at seven days.
Written by your server in an HTTP Set-Cookie response header on your genuine first-party domain: not subject to the seven-day cap, and can persist for Safari's normal maximum.

This single distinction is why a returning Safari visitor often looks brand new after a week. The GA4 or ad cookie that identified them was written by a browser tag, so ITP wiped it. Extending those cookies is the whole point of server-side tagging against ITP.

The 24-Hour Cap On Link Decoration

ITP watches for link decoration, the practice of appending click identifiers to outbound URLs (the gclid, fbclid, and similar parameters that carry attribution across a click). When Safari sees a landing page reached through a decorated link from a known tracker, it "caps the expiry of cookies created in JavaScript on the landing webpage to 24 hours."

The practical effect: an attribution cookie set from a paid click can vanish within a day. If your conversion happens two days later, the identifier that would have connected click to purchase is already gone. This is a large, under-discussed source of the gap between what your ad platform reports and what your own analytics sees for Safari traffic.

A Tracking Subdomain Doesn't Escape ITP

Some vendors route tracking through a subdomain of your site to make cookies look first-party. Safari anticipated this. ITP "detects third-party CNAME cloaking and third-party IP address cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days." If track.yoursite.com is really a CNAME pointing at a third party's infrastructure, or resolves to an IP range that isn't yours, Safari treats those server-set cookies as cloaked and reapplies the seven-day cap. To earn the long lifetime, the endpoint has to be genuinely first-party, hosted on infrastructure you control, not a rebranded third-party alias.

What This Does To Your Numbers

Once you know the mechanics, the reporting symptoms make sense:

Inflated new-user counts. Returning Safari visitors whose client-side cookie expired get counted as new, so your "new vs returning" split skews toward new.
Short attribution windows. Conversions that land more than a day or a week after the click lose their identifier, so paid channels look weaker in your own analytics than in the ad platform.
Understated retention and LTV. Cohorts built on client-side cookies decay fast on Safari, making loyal users look like one-time visitors.

None of this means your marketing got worse. It means a chunk of your Safari measurement is being erased by design. For how to size and recover that gap, see Measuring the Impact of Consent on Analytics and First-Party Data Strategy for a Cookieless Future.

ITP Is Not Consent, And It Doesn't Replace Your Banner

Here's the trap. Because Safari already restricts so much tracking, it's tempting to think the browser is handling privacy for you. It isn't, not in the legal sense. ITP is Apple protecting Apple's users from cross-site tracking. It doesn't ask for or record consent, it doesn't apply in Chrome or Firefox, and it does nothing about the first-party cookies you set on your own domain.

Your obligation under the GDPR and ePrivacy is separate: get prior consent before you drop non-essential cookies, for every visitor, in every browser, and keep proof. A Safari user who blocks third-party cookies still needs a valid consent choice for the analytics and marketing you run first-party. Browser defense and consent management are different jobs, covered in Browser-Level Blocking vs Consent Management.

Where CookieBeam Fits

CookieBeam gates your tags on the visitor's consent before anything loads, in Safari and everywhere else, and logs the decision in a first-party cookie so it survives across sessions. Our scanner inventories the cookies, scripts, and outbound connections your site actually loads, so you know what needs a consent category. One honest caveat: the scanner runs in a controlled Chromium environment, so it shows the full tracker surface you're responsible for, not the reduced set that any one Safari visitor will experience after ITP does its filtering. Use it to find what to gate, then let consent, not the browser, decide what fires.

Related Guides and Sources

Keep reading: First-Party Cookies and Server-Side Tagging: Beating ITP, Third-Party Cookies in Chrome, and Browser Fingerprinting and Why Browsers Block It. Primary source: WebKit's Tracking Prevention policy, which documents the third-party cookie block, the seven-day and 24-hour caps, and the CNAME and IP cloaking defenses.