Safari ITP, three years on: what 7-day attribution actually does to your numbers .

roughly 30% of your traffic is Safari. for those visitors, anything you do with third-party cookies has a 7-day half-life. here's what that costs you, and what to do about it.

Apple’s Intelligent Tracking Prevention has been steadily ratcheting tighter since 2017. by 2020 it had killed third-party cookies entirely on Safari. in 2023 it added the now-infamous behaviour: any cookie set via JavaScript on a page where the URL contains tracking-link parameters expires after 7 days. that’s the rule that ate your attribution windows.

The honest version of what this means: if you’re running a 30-day attribution window and a meaningful chunk of your traffic is Safari, your reported numbers are wrong by more than you think. not catastrophically — your top-of-funnel measurement still works — but enough that scaled spend decisions made on those numbers will quietly underperform.

How big is the gap, actually?

Safari’s share of US ecommerce traffic varies wildly by category. some baselines from the merchants we work with:

Now overlay that on a typical conversion lag distribution. about 60–70% of conversions happen within 7 days of first click. the remaining 30–40% land between days 8 and 30. for Safari users, anything in that 30–40% bucket has a degraded chance of attributing back to the original click — because the cookie that was carrying the click identifier expired.

Combine the two: if you’re at 30% Safari and 35% of your conversions lag past 7 days, roughly 10–11% of all your conversions have impaired attribution by default. that’s not a rounding error.

What ITP actually does (the technical part)

Three rules, all on Safari (desktop and iOS):

1. No third-party cookies. period, since 2020. anything served from a domain other than the one in the URL bar can’t read or write cookies.
2. JS-set cookies expire in 7 days. if your script tag at yourstore.com calls document.cookie = ..., that cookie lives 7 days max. this is the big one.
3. Cookies set on pages with tracking parameters expire in 24 hours. if the URL contains parameters Apple has classified as tracking (gclid, fbclid, ttclid, msclkid, and a long, evolving list), JS-set cookies on that page get a 1-day TTL instead of 7.

Server-set cookies — meaning cookies set via the Set-Cookie header in an HTTP response — are not subject to the 7-day rule. they get the full TTL the server requests. this is the loophole every “first-party tracking” tool tries to use, with varying levels of integrity (we wrote about what counts as actually first-party separately).

What this looks like in your data

Specific symptoms, in rough order of how often we see them:

• Direct/none traffic on conversions is suspiciously high. the Safari user clicked your ad on Tuesday, came back via Google search 9 days later, and the original click attribution is gone. the conversion shows as “Direct” or “Organic Search.”
• Meta and Google report different conversion totals than your store. Meta uses its own attribution windows, Google uses theirs, and your Shopify analytics use UTMs that may have evaporated. all three numbers will diverge for your Safari traffic.
• Day-of-week patterns get noisy. a Friday ad click that converts the following Friday on Safari? attribution is gone. Monday click that converts Wednesday? fine. you’ll see suppression on longer-lag conversions that doesn’t appear on shorter ones.
• “New customer” rates are inflated. the same Safari user who bought from you 30 days ago shows up as new because their identifying cookie expired.

What to do about it

1. Use server-side conversion APIs everywhere

Meta CAPI, Google Enhanced Conversions, TikTok Events API, Pinterest CAPI. these don’t fix attribution windows, but they do let you send conversions directly from your server using whatever identifiers you have — hashed email, click IDs captured at landing time, IP+UA hashes — bypassing the cookie problem for the conversion event itself.

2. Capture click IDs at landing and persist them server-side

When a user lands with ?gclid=... or ?fbclid=..., capture the click ID server-side and store it in a server-set cookie. that cookie isn’t subject to ITP’s JS rules and will live the full TTL you request. when the conversion fires, send the stored click ID with the conversion event regardless of which cookies the browser has at that moment.

3. Capture user identity early

The most durable identifier is one the user gives you: their email. capture it as early as possible — popup, account creation, newsletter, checkout’s first field — hash it, and use it as the join key across ad platforms via enhanced/advanced matching. this works regardless of cookie state.

4. Stop relying on 30-day windows for Safari traffic

Pragmatically: use 7-day click attribution as your primary truth for Safari, and treat anything beyond 7 days as supplementary evidence rather than the headline number. it’s a less satisfying position than “30-day click is the standard,” but it matches the data Safari actually gives you.

How Maximo handles this

Server-side conversion APIs to every channel, by default — none of this is opt-in. click IDs captured at landing and persisted in HTTP-only, server-set cookies that ITP can’t truncate. enhanced matching with hashed email/phone wherever the user has identified themselves. and click-to-conversion stitching done server-side so we can attach the right click ID to the right purchase even when the cookie state has decayed.

None of this fully restores 30-day attribution on Safari — that’s not technically possible without circumventing user consent — but it closes the gap to within a few percent, instead of the 10–15% loss most stores live with by default.