Apple shipped the first version of Intelligent Tracking Prevention in September 2017. It was framed as a privacy feature, which is accurate. It was also a systematic dismantling of every workaround the ad tech industry had assembled since the third-party cookie ecosystem started cracking around 2013. Each new ITP version closed the escape hatch that marketers had found in the previous one. By the time ITP 2.3 shipped in 2019, the sequence of closures had been thorough enough that the only attribution paths still functioning reliably on Safari were ones that had never depended on cross-site tracking at all.
This post walks through that sequence in date order: what each version broke, what workaround it was specifically designed to close, and where that leaves attribution in 2026. The companion post Cookieless attribution explained covers the broader landscape across browsers; this one is specifically about Safari and specifically about the redirect-chain pattern that survives all of it.
TL;DR#
- ITP 2.0 (2018) blocked all third-party storage access on cross-site domains, killing the standard ad pixel attribution path on Safari.
- ITP 2.1 (2019) capped JavaScript-set first-party cookies at 7 days, ending year-long attribution windows set via tag managers.
- ITP 2.2 and 2.3 stripped link-decoration parameters and downgraded referrer headers, closing the last query-string workarounds.
- A short link on your own domain sets a first-party cookie server-side at redirect time — this is the one pattern that survives ITP in all its versions and gives you a reliable 7-day attribution window on Safari.
The ITP timeline: a version-by-version breakdown#
ITP did not arrive fully formed. It was released incrementally, with each version targeting a specific class of workaround that the industry had developed in response to the previous version. Understanding the sequence matters because the technical shape of what survives is defined by what was closed and how.
ITP 1.0 — September 2017. The first release classified domains as "cross-site trackers" based on bounce frequency and user interaction signals. Domains classified as trackers had their cookies partitioned — they could be set, but only read in a cross-site context if the user had directly interacted with the tracker's domain in the past 24 hours. For a domain like a standard analytics pixel that users never navigate to directly, the 24-hour window was a de facto block.
ITP 1.1 — March 2018. Advertisers responded to 1.0 by routing attribution through redirect chains that touched the tracker domain as a first-party landing before bouncing to the destination. This gave users a "direct visit" to the tracker domain, which reset the interaction clock. ITP 1.1 identified this pattern — known as the bounce tracker — and removed the interaction credit that bounce-redirect chains generated. Domains that appeared to exist solely for the bounce-and-redirect pattern lost their interaction status.
What ITP 2.0 broke#
ITP 2.0 shipped in September 2018. It was the structural break. Where 1.x had partitioned third-party cookies, 2.0 went further: it removed third-party storage access entirely for classified domains. Cookies, localStorage, IndexedDB, cached data — all of it was blocked for any domain that ITP classified as a cross-site tracker.
The practical effect on ad tech was significant. The Facebook Pixel, Google Ads conversion tag, and most retargeting pixels depend on reading a cross-site cookie to tie a click to a conversion. On Safari after ITP 2.0, that read failed. Meta's own reporting at the time indicated a 15-25% gap in event coverage on Safari traffic — clicks and conversions that the pixel saw on Chrome or Firefox simply did not appear from Safari users.
The storage block was not limited to cookies. Scripts that attempted to persist identifiers in localStorage under a tracker-classified domain, or use Service Workers for persistence, were equally blocked. The intent of 2.0 was to make the third-party storage layer structurally unavailable for tracking purposes, not just to break one specific technique.
What ITP 2.1 broke#
If 2.0 killed third-party attribution, ITP 2.1 (March 2019) targeted the workaround that had grown up in response to it: first-party cookie attribution via tag manager injection.
The logic was sound. If the third-party pixel was blocked, you could still persist attribution by writing a first-party cookie on the advertiser's own domain via JavaScript — typically injected by a tag manager like GTM. The cookie was first-party and therefore not subject to ITP's third-party storage restrictions. Many teams had moved to year-long attribution windows set this way, reasoning that a first-party document.cookie write was safe.
ITP 2.1 capped all cookies set via document.cookie — regardless of first-party or third-party status — at a 7-day maximum. The cap applied specifically to script-set cookies; cookies set via the Set-Cookie HTTP response header were not affected by 2.1. The distinction is precise and consequential: document.cookie = "..." in JavaScript is capped at 7 days. Set-Cookie: ...; Max-Age=31536000 from a server response is not.
The immediate casualty was the GTM-based attribution setup. GTM writes cookies through JavaScript on the page. Those cookies, regardless of their stated expiry, now expired in 7 days on Safari. A user who clicked a campaign link on a Tuesday and converted the following Wednesday was outside the attribution window. The year-long first-party cookie attribution window that teams had migrated to after ITP 2.0 was gone.
What ITP 2.2 broke#
ITP 2.2 tightened two areas. First, it reduced the JavaScript cookie cap to 24 hours in the specific case where the destination page was linked to from a domain that ITP had classified as a cross-site tracker. If a user clicked a link from a classified domain's page, the first-party cookies on the destination site set via JavaScript were capped at 24 hours — not 7 days. The 7-day cap remained for non-tracked referrer paths, but the 24-hour cap applied when the click chain included a classified domain.
Second, and more broadly noticed, ITP 2.2 introduced limits on link decoration. Ad platforms and analytics tools had developed a pattern of appending attribution identifiers as query parameters to destination URLs — gclid for Google Ads, fbclid for Meta, msclkid for Microsoft Advertising. Under certain conditions, if the linking domain was classified as a tracker, ITP began stripping those parameters before the page loaded or limiting the cookies that could be set in response to their presence.
This was a direct attack on the gclid-based attribution path that teams had pivoted to after 2.0 and 2.1. The reasoning was explicit: Apple considered query-parameter-based user tracking to be equivalent in privacy impact to cookie-based tracking, and the same restrictions should apply.
What ITP 2.3 broke#
ITP 2.3 (September 2019) closed two remaining gaps.
The first was referrer downgrading on cross-site navigation. Where previous versions had focused on storage and link parameters, 2.3 addressed the referrer header — the Referer value that a page receives when a user navigates to it from another site. For cross-site navigations from classified domains, ITP 2.3 downgraded the referrer to origin-only: https://classified-domain.com/ instead of the full https://classified-domain.com/path?campaign=spring&source=email. The path and query string, which often contained attribution context, were stripped.
The second change extended the storage-capping logic. In addition to the 7-day cap on JavaScript cookies, ITP 2.3 applied a storage cap after a single cross-site click from a classified domain: all client-side storage on the destination site — cookies, localStorage, IndexedDB — was subject to capping. The intent was to close a class of stateful attribution patterns where the mere act of being linked to from a classified domain would start a countdown on the destination's ability to persist data.
Together, 2.2 and 2.3 closed the three main routes that teams had used after 2.0 and 2.1: link-decoration parameters, referrer-based attribution, and storage accumulation across cross-site click chains.
What survives#
The ITP sequence was methodical, but it was targeted at cross-site tracking. The patterns that survive are ones that are genuinely first-party — where the attribution data is captured on your own domain, set via your own server, and never passes through a third-party domain's storage.
Server-set first-party cookies. ITP 2.1's cookie cap applies to document.cookie writes via JavaScript. Cookies set by a server via the Set-Cookie HTTP response header retain their stated expiry. The key constraint is that the cookie must be set on the domain that the server controls.
Server-side event forwarding. If the click identifier is captured at redirect time and stored server-side, the attribution lookup at conversion time is a server-to-server operation. No browser cookie needs to survive 7 days; the click ID is in your database. This is the architecture behind server-side conversion tracking and the approach Meta CAPI, GA4 Measurement Protocol, and TikTok Events API are all designed to support.
Deterministic matching via hashed email or phone. When a user is authenticated or has submitted an email address, the conversion can be matched to the original click by email hash rather than by cookie identity. This path is independent of ITP entirely — it never relied on browser storage. The limitation is coverage: it only works for users who have identified themselves within the attribution window.
The full technical context for these patterns is in Cookieless attribution explained.
The short-link redirect pattern#
Short links on your own domain — not on a shared shortener domain — give you the server-set cookie path in a form that works naturally with campaign traffic.
The mechanic is straightforward. When a user clicks a campaign link pointing at go.acme.example/spring26, the request hits an edge handler on go.acme.example. The edge handler captures the click event, generates a click ID, and sets a Set-Cookie header on the redirect response — a server-set first-party cookie on acme.example. It then issues the 302 to the destination URL with the click ID appended as a query parameter.
Because the cookie is set via Set-Cookie by the server at redirect time, ITP 2.1's 7-day JavaScript cap does not apply. The cookie retains whatever expiry the server set. On Safari, with ITP 2.3 fully active, a server-set cookie on go.acme.example survives for the full configured window. We set a 7-day expiry by default at Elido because that matches ITP's most restrictive constraint for JS-set cookies anyway, and the server-set cookie holds for all 7 days.
The destination page then reads the click ID from the cookie or from the query parameter (whichever is available), writes it to the cart or order attributes, and the conversion event carries it server-side at purchase time. No cross-site domain is involved. The cookie is on your domain. The attribution lookup is a server-side operation. ITP has nothing to block.
This is why custom domain support on a short link matters for attribution: not only for branding but for the cookie first-party classification. A shared shortener domain like bit.ly or short.io is a different origin from your website. A cookie set on bit.ly is a third-party cookie on acme.example; ITP 2.0 blocks it. A cookie set on go.acme.example is first-party; nothing in ITP touches it. The solutions/marketers page covers the campaign attribution flow end to end.
For deeper GDPR context on what click data a shortener may lawfully process and how to configure data minimisation on the click event schema, see GDPR for URL shorteners.
What still does not work#
Honesty is cheaper than overselling a partial solution.
Cross-domain view-through attribution. If a user sees an ad on publisher.example without clicking and later converts on advertiser.example, there is no ITP-safe path for that attribution. View-through inherently requires a cross-site signal from the impression to the conversion. Safari blocks it, and the server-side forwarding approaches above are click-initiated — they require the click to set the first-party cookie or write the click ID.
Real-time stitching for unauthenticated users. If a user converts without ever logging in or submitting an email address, the only identifier available is the click ID from the cookie or query parameter. If the cookie has expired (beyond 7 days after the first click, or 24 hours if 2.2's tighter cap applies), the stitch is lost. Server-side click ID storage solves this for conversions within the window. It does not solve it for conversions that arrive after the window has closed.
Attribution windows longer than 7 days on Safari for first-touch. If your business has a buying cycle measured in weeks or months — common in B2B SaaS, high-value e-commerce, financial services — the 7-day window on Safari first-party cookies means a substantial fraction of conversions will not be attributable to their originating click. For these business models, the deterministic email-hash path is the only option; probabilistic attribution on Safari is not reliable enough to act on.
Fingerprinting as a substitute. Canvas fingerprinting, audio fingerprinting, and font enumeration are workarounds that attempt to re-identify users across sessions without cookies. Apple has explicitly moved to reduce fingerprinting surface in Safari. The ITP 2.3 release notes reference "additional protection against other forms of cross-site tracking," and the direction has continued in every subsequent Safari release. Fingerprinting also carries material legal risk under GDPR Article 6, as explored in GDPR for URL shorteners. It is not a viable replacement for the patterns described above.
Practical starting point#
The redirect pattern works. Set up a custom domain on your short link workspace (go.yourdomain.example), route campaign traffic through it, and configure your destination page to read the elido_click query parameter or the first-party cookie and write it to your order or cart attributes before the user converts. Then route conversions server-side to the ad platforms via the conversions API. The 7-day window covers the majority of click-to-conversion paths for most campaign types.
For the conversion forwarding setup — Meta CAPI, GA4 Measurement Protocol, the retry semantics, and the deduplication shape — server-side conversion tracking is the technical companion to this post. For the product surface, conversion tracking features is the starting point.
ITP did not kill attribution. It killed a specific architecture of attribution — the one built on cross-site persistent storage and undifferentiated data accumulation across domains you don't control. The architecture that replaced it is more defensible, not less.