Safari's Intelligent Tracking Prevention has been quietly reshaping web analytics for years, and most people's mental model of it is a few versions out of date. Here is what it currently does, and what survives it.
What ITP does
Third-party cookies are dead. Blocked entirely, no exceptions, since 2020. Anything depending on a cookie set by a domain other than the one in the address bar does not work in Safari.
First-party cookies set by JavaScript expire in seven days. This is the one that catches people. A cookie your own site sets with document.cookie is capped at seven days regardless of the expiry you asked for. Set a one-year cookie and Safari silently rewrites it to seven.
And in some cases, twenty-four hours. If the visitor arrived via a link with tracking parameters from a domain classified as a tracker, the cap drops to a day.
Cookies set by an HTTP response header are not capped the same way. This is the loophole that CNAME cloaking exploits — and Safari has been progressively closing it, treating CNAME-disguised third parties as third parties.
Referrers are downgraded in some cross-site navigations, to the origin only.
What this does to analytics
Anything counting returning visitors with a JavaScript cookie is broken in Safari. Not degraded — broken. A visitor returning after eight days is a new visitor. Your returning-visitor rate is understated by however much of your audience uses Safari, which on a consumer site with heavy iPhone traffic can be most of it.
Attribution windows longer than seven days do not work. If someone clicks an ad, comes back a fortnight later and converts, the connection is gone. Any funnel spanning more than a week is measuring something narrower than it claims.
Cross-domain journeys break. Marketing site to app on a different domain is two unrelated visitors.
Why cookieless measurement is mostly unaffected
If a tool never sets a cookie, there is nothing for ITP to expire.
Approaches that derive a daily identifier by hashing request attributes with a rotating salt — the mechanism is worth understanding — are unaffected by every cookie rule above, because they store nothing on the device at all.
What such a tool gives up, it gave up deliberately and on every browser: identity does not persist beyond a day. There is no cross-day returning-visitor metric to break, because there was never one to begin with.
That is a real limitation, stated honestly. The relevant comparison is not "cookieless versus perfect" — it is "cookieless, which loses cross-day identity everywhere and says so" against "cookie-based, which loses it in Safari, silently, and reports the remainder as if it were the whole".
The second is worse, because the error is invisible and correlates with device type. Your iPhone audience looks less loyal than your Android audience for reasons that have nothing to do with loyalty.
What ITP still affects
Being complete rather than reassuring:
Referrer downgrading affects every tool equally. Some cross-site navigations arrive with only the origin, or nothing. There is no workaround; it is a browser policy about what is transmitted.
Private Relay puts iCloud+ users behind a relay address in roughly the right region. Any measurement using IP as an input — including a rotating hash — sees the relay rather than the visitor. Effects: slightly coarser geography, and a small chance two users behind the same relay with the same user agent collapse into one visitor on the same day. Small, real, worth knowing.
Storage partitioning affects embedded content generally, though not first-party analytics.
What to do
Stop relying on cross-day identity if a meaningful share of your audience uses Safari. Not as a workaround — as an accuracy correction. That metric is already wrong; the only question is whether you know it.
Use daily uniques and be explicit that they are daily. A number defined clearly and computed correctly beats a number defined loosely and computed inconsistently across browsers.
Do not reach for CNAME cloaking. It exists to make a third party look first-party, Safari is actively closing it, Firefox blocks known cases, and it undermines the honesty argument that made cookieless measurement worth adopting.
Count in the request path where you can. Edge measurement is unaffected by any of this, because the count happens before the browser has done anything at all.
Common questions
Does Safari block first-party analytics cookies?
It does not block them, it caps them. A first-party cookie set by JavaScript expires after seven days regardless of the expiry you requested, and after twenty-four hours if the visitor arrived from a domain Safari classifies as a tracker. The cookie works, it just does not last, which means returning-visitor counts and attribution windows longer than a week silently fail in Safari.
Is cookieless analytics affected by ITP?
Barely. If nothing is stored on the device there is nothing for ITP to expire, so every cookie rule is irrelevant. Two things still apply to everyone: referrer downgrading on some cross-site navigations, and iCloud Private Relay, which replaces the visitor's address with a relay one and slightly coarsens IP-derived geography.
Should I use CNAME cloaking to get around tracking prevention?
No. It works by making a third-party service look first-party, Safari has been progressively detecting and closing it, and Firefox blocks known cases. Beyond the technical fragility, it contradicts the honesty that makes privacy-respecting measurement defensible in the first place. Serving your own analytics from your own domain achieves the durable part of the benefit without the disguise.