Understanding Safari ITP: why your 7-day cookies are breaking attribution (and how to fix it)

If your site runs analytics, advertising, or attribution tracking, ITP is the single biggest reason your dashboards are lying to you. This post explains what ITP actually does, why the 7-day cookie rule is usually described wrong, and what a fix looks like in 2026.

What ITP actually does

Safari Intelligent Tracking Prevention (ITP) is not a single rule. It is a set of heuristics that evolve across Safari releases. In 2026, the three that matter most to data teams are:

• Cookies written by JavaScript via document.cookie are deleted after 7 days if the visitor doesn’t come back, whatever expiry date you set. If the visitor arrived from an ad click, that drops to 24 hours.
• Cookies set in cross-site contexts (third-party cookies) are blocked outright in most scenarios.
• Server-set cookies get the same 7-day limit when they come through a CNAME to a vendor or from a server outside your website’s own network. To Safari, a vendor endpoint dressed up as your subdomain is still the vendor.

The 7-day limit is the one most teams run into first, because it silently breaks attribution for every visitor who takes more than a week to come back.

Why your attribution window matters

Take a typical e-commerce funnel: a visitor sees an ad, clicks through, browses, and buys 10 days later. If you are tracking that conversion via a cookie set by JavaScript on the browser — which is what every client-side analytics or pixel library does by default — Safari has deleted the cookie by the time the visitor returns. The purchase is counted as a brand-new session, unattributable to the ad.

For low-consideration retail, a week is sometimes enough. For travel, SaaS, automotive, financial services, and B2B, a week is nowhere close. The longer your sales cycle, the more of your attribution Safari is invalidating without telling you.

Google Analytics 4 reports on this quietly: you will see direct-traffic conversions climb month over month. That is usually not customer behaviour changing — it is ITP silently severing attribution.

The difference between client-set and server-set cookies

Here is the single technical fact that most people miss: the 7-day limit only applies to cookies set by JavaScript. Cookies your own server sets with the HTTP Set-Cookie response header last their full lifetime, up to the 400-day maximum every browser allows. The one condition: they must come from your own domain and infrastructure, not a vendor CNAME.

JavaScript-set cookie:
  document.cookie = "_foo=abc; max-age=34560000"
  → Safari deletes it after 7 days without a visit

Server-set cookie from your own domain: Set-Cookie: _foo=abc; Max-Age=34560000; HttpOnly; Secure; SameSite=Lax → Full 400-day lifetime (browser cap) in all browsers ```

That is it. If your cookies are server-set from your own domain, they last up to 400 days. If they are set by JavaScript, Safari deletes them for any visitor who stays away for a week, full stop.

Why most sites still have client-set cookies

Because the vendor tags every marketing team installs all work by injecting JavaScript that writes cookies via document.cookie. Even server-side tag managers, which sound like they should fix this, still require those vendor scripts to be present in the browser to generate the events that flow to the server container. The cookies are still written by the browser, and Safari still deletes them after a week away.

The fix is not "install a server-side tag manager on top of your client-side stack." The fix is "replace the client-side vendor scripts with a single first-party collector that writes cookies server-side."

What a server-side first-party collector actually looks like

In Datafly Signal’s model:

• You host a single 5.2KB JavaScript collector on your own subdomain (e.g. data.example.com).
• That collector sends events to your own ingestion gateway, also on your subdomain and your own infrastructure.
• The gateway writes the _dfid visitor-ID cookie via a Set-Cookie response header — server-set, 400-day lifetime, no 7-day limit.
• The gateway generates and sets vendor ID cookies (_fbp, _fbc, _ga, _ttp, etc.) the same way — server-set, full TTL.
• Events flow server-to-server from the gateway to vendor APIs (GA4, Meta CAPI, TikTok Events API, etc.).

No vendor JavaScript in the browser. No client-set cookies. No 7-day cookies.

A pragmatic migration path

If you are running on a client-side tag manager or analytics SDK today, you do not have to rip it out overnight. Run Datafly Signal in parallel for 1-2 weeks, compare conversion counts with your existing stack, then cut over. Most of the teams we work with see the switched-on window close roughly 15-25% of previously-missing conversions purely from the ITP fix.

For a deeper technical walkthrough of the identity layer, see Identity. For the comparison against GTM server-side specifically, see vs GTM.