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 cap 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:

• Any cookie written by JavaScript via document.cookie is capped at a maximum 7-day lifetime. Safari also reserves the right to reduce this to 24 hours for domains classified as trackers.
• Cookies set in cross-site contexts (third-party cookies) are blocked outright in most scenarios.
• CNAMEs pointing to known tracker domains are penalised: a cookie set by a server that resolves to a vendor endpoint is treated the same as a cookie set directly by that vendor.

The 7-day cap is the one most teams run into first, because it silently shortens every attribution window longer than a week.

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 — the cookie is gone 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 cap only applies to cookies set by JavaScript. Cookies set via the HTTP Set-Cookie response header from a first-party server are exempt and persist for their full configured TTL.

JavaScript-set cookie:
  document.cookie = "_foo=abc; max-age=34560000"
  → Safari ITP caps at 7 days (sometimes 24 hours)

Server-set cookie: 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 on a genuine first-party domain, they persist for up to 400 days regardless of ITP. If they are client-set, they are 7 days, 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, still capped at 7 days by Safari.

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.
• The gateway writes the _dfid visitor-ID cookie via a Set-Cookie response header — server-set, 400-day lifetime, exempt from ITP.
• 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 cap.

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.