What is ITP?

ITP is a feature of WebKit, the engine behind Safari on Mac, iPhone and iPad. It appeared in 2017 with a different approach from blocklists. Instead of maintaining a catalogue of forbidden domains, the browser observes how each domain behaves and decides for itself which ones can follow a person across sites. The classification uses a statistical model that looks at, among other signals, under how many distinct domains a resource appears as a subresource, under how many it appears inside a frame, and towards how many distinct domains it redirects. The whole calculation runs on the user's device.

That is where the two most expensive confusions come from. First: ITP is not an ad blocker. Ads still serve and pages still load; what gets trimmed is the lifetime of the storage that would allow the same person to be recognised across separate visits. Second: ITP does not ask about consent. It is a browser decision, it applies just the same when permission has been granted, and it answers to WebKit's privacy policy rather than to the site's cookie notice. Someone who accepts everything in the banner has exactly the same expiry limits in Safari as someone who declines.

The first version worked with two time windows. If the user had interacted with a classified domain in the previous twenty-four hours, that domain's cookies stayed available when it appeared as a third party. After thirty days without interaction, its data and cookies were purged.

ITP 2.0 removed the twenty-four hour window and moved to immediate partitioning. It also introduced the Storage Access API for legitimate embedded sessions, detection of bouncing through intermediate domains, and downgrading of the referrer. ITP 2.1 limited the lifetime of any persistent cookie written through document.cookie to seven days and retired partitioned cookies. ITP 2.2 lowered that limit to one day when the user arrives from a classified domain and the destination address carries appended parameters. ITP 2.3 extended the trimming to the rest of script-writable storage and downgraded document.referrer to the top level domain plus one.

In 2020 came the two changes that close the picture. Safari blocks cookies from other sites' resources by default, now without exceptions, and deletes all of a site's script-writable storage after seven days of browser use without user interaction on that site. Shortly afterwards ITP began detecting requests that hide a third party behind a first-party subdomain through CNAME records, and capping cookies set in those responses at seven days. WebKit adds a security warning at that point: whoever sets up that kind of arrangement is exposed to a full site takeover and to theft of their customers' cookies.

The practical consequence is a single one, and it deserves to be said plainly. In Safari, recognition over longer periods breaks. A first-party cookie set to last a year can live seven days. Long purchase cycles, funnels with several visits and twelve-month customer value analyses see one stretch of the journey and assign the rest to a direct visit or to the last channel that shows up.

Then comes the question that always arrives: does server-side tracking fix it? It helps with what belongs to it. It gives control over which data leaves the building, reduces dependence on third-party scripts in the page and holds up better against network blockers. What it does not do is bring back long-horizon recognition, because the lifetime caps reach both the cookies written from the browser and those arriving through routes whose real recipient is a third party. Selling a server infrastructure as a remedy against ITP promises precisely what the feature is designed to prevent.

What does hold measurement up is something else: shorter analysis windows, voluntary identification through a sign-in with permission, aggregated or modelled reports where individual counts used to be, and attribution expectations adjusted per browser.

• Measure in short windows and compare equivalent periods, instead of dragging along twelve-month cohorts that will never be complete in Safari.
• Split the reports by browser before drawing conclusions. Mixing Safari with Chrome hides the effect and makes it look like a campaign problem.
• Give a real reason to sign in. Voluntary identification with permission is the only recognition that stays stable in the long run.
• Use the Storage Access API when embedded content genuinely needs the user's session, rather than hunting for storage substitutes.
• Review which decisions hang on last-click attribution and which can lean on aggregated measurement or on experiments.
• Document the expected loss per browser and share it with whoever reads the reports, so the drop is not read as an implementation error.

• Treating ITP as a consent matter and asking the CMP to solve it.
• Comparing Safari performance with Chrome performance without correcting for the measurement difference, then cutting budget in the wrong channel.
• Commissioning server-side tracking in the expectation that it restores long-horizon recognition.
• Assuming a first-party cookie lives as long as its expiry date says.
• Confusing ad blocking with tracking prevention when reading a drop in the reports.