Safari ITP and ad tracking: what still works

Safari's Intelligent Tracking Prevention (ITP) limits how long a website can recognize a returning visitor. It blocks all third-party cookies and caps cookies set by JavaScript at 7 days, or at 24 hours after some ad clicks. Purchases sent server-side from your order data, click ids saved when the shopper lands, and hashed customer data still work.

This guide explains each ITP rule as WebKit documents it, what the rules do to attribution windows and remarketing, and which tracking methods still work for a webshop. It ends with a way to check how much Safari affects your own store.

What is Safari ITP?

Intelligent Tracking Prevention is a set of privacy protections in WebKit, the browser engine behind Safari on Mac, iPhone and iPad. WebKit has extended it many times, and it documents the current rules on its Tracking Prevention page.

Some ITP rules apply to every website. Others apply only to domains that ITP has classified as having cross-site tracking capabilities, based on how those domains behave across the sites a person visits. ITP is on by default, so it affects every Safari visitor to your store, not only privacy-minded ones.

What are the cookie limits in Safari ITP?

The 7-day cap on script cookies

Most pixels and analytics tools write their own first-party cookies with JavaScript. The Meta pixel, for example, keeps a browser id in a cookie called _fbp. In Safari, ITP deletes cookies and other storage created by JavaScript after 7 days without user interaction on your site. WebKit defines user interaction as a click, a tap or a key press. Scrolling does not count.

In practice, a shopper who comes back and uses your site within 7 days usually keeps the cookie. A shopper who stays away for more than 7 days comes back without it, and looks like a new visitor.

The 24-hour cap after a decorated link

Ad platforms add click ids to the links in their ads. WebKit calls this link decoration. When a domain that ITP has classified as a tracker sends the visitor to your page, and the final URL has a query string or a fragment, cookies that JavaScript writes on that landing page are capped at 24 hours. The cap applies to the page reached through that navigation, not to the site as a whole.

Third-party cookies

Safari blocks all third-party cookies by default, and WebKit says there are no exceptions to this blocking. A third party can only ask for access through mechanisms such as the Storage Access API. An ad platform therefore cannot read its own cookie from inside your pages. It depends on the first-party cookies its pixel writes, which fall under the 7-day and 24-hour rules.

CNAME and IP address cloaking

A common workaround is a tracking subdomain, such as t.yourstore.com, that points to a tracking server. Cookies from that subdomain are set in the HTTP response, so they are not script cookies. WebKit treats the subdomain as cloaked when it points through a CNAME to a different domain. Since Safari 17, it also treats the subdomain as cloaked when its IP address looks like a different party from your site, for example when the two addresses are in clearly different network ranges. In both cases ITP caps the cookies set in the response at 7 days. Who owns the server does not matter for these rules.

How does Safari handle click ids in links?

A click id such as fbclid or gclid is part of the landing URL. In normal browsing, Safari loads the URL with its parameters, so a script on the landing page can read the click id. The 24-hour cap above limits how long a cookie written on that page lasts. It does not remove the click id from the URL.

Private Browsing goes further. Since Safari 17, Link Tracking Protection applies when the visitor navigates from one website to another, such as from an ad to your store. Safari removes a set of query parameters that WebKit has identified as used for cross-site tracking of users or clicks. WebKit's announcement does not list the parameters. Its example removes a tracking parameter and keeps a campaign parameter. On the landing page, third-party scripts that read the URL also get it without the query string. The same protections are available in normal browsing for people who turn on advanced tracking and fingerprinting protection for all browsing.

What about Private Relay and IP addresses?

According to WebKit, Safari has hidden IP addresses from known trackers by default since Safari 15. People who pay for iCloud+ can also turn on iCloud Private Relay. It sends Safari traffic through two separate relays, run by different operators, so websites see a relay IP address instead of the visitor's own. Apple says the relay address keeps the visitor's coarse, city-level location, and that several users in the same area may share one address.

This weakens tracking that relies on the IP address, such as matching a visitor by IP address and browser. It does not affect click ids, hashed email addresses or order data. ROASaurus uses an IP match only as a last resort, and only when exactly one recent visitor with that IP address and browser fits. A shared relay address then usually leads to no match.

What does ITP mean for attribution windows?

An attribution window is the number of days after a click in which a purchase can still be credited to that click. In ROASaurus you choose a lookback window from 1 to 90 days, with 7 days as the default. Ad platforms have their own settings. In Safari, a setup that relies only on browser cookies can connect a purchase to a click only while the cookie lives.

The effect grows with the window. A 1-day or 7-day window is no longer than the 7-day life of a script cookie, unless the 24-hour cap applies. With a 28-day window, purchases on day 8 or later from shoppers who did not return in between depend on other data.

Here is how to size this for a store. The numbers are an example; use your own.

What does ITP mean for remarketing?

Remarketing audiences are built from browser events, such as people who viewed a product or added it to the cart. In Safari, the platform cannot use its third-party cookies, and the pixel's first-party cookie is deleted after 7 days without a visit. A Safari visitor who returns after 8 days looks new to the pixel. Their earlier product views are no longer linked to them in the browser.

Two effects follow. Audiences with long durations, such as 30 or 180 days, keep fewer Safari visitors than the duration suggests. Your analytics also shows more new visitors and fewer returning ones than you really have. Customer list audiences built from hashed email addresses in your shop or email tool do not depend on cookies, so they are not affected in the same way.

What still works in Safari?

Server-side events from orders

A purchase sent from your shop's order data does not depend on any cookie in Safari. The shop records the order, a server sends it to the platform's API, and the platform receives it. The event includes the hashed email and phone number from the order. The platform can match those to one of its users and check its own records of ad clicks and views, within its own attribution window. Read what server-side tracking is for the full data path.

Click ids captured on landing

The click id is in the URL of the first page. A script can read it there and send it to your server, where it is stored with the visitor id. The server copy does not expire after 7 days. What expires is the browser cookie that connects a returning visit to that stored visitor. Other data can still connect an order to a stored click, such as an email address the shopper gave earlier in a signup form, or the click id in the landing URL of the session that placed the order.

First-party collection, with the 7-day limit

Serving the tracking script and its requests from your own domain keeps collection first-party, which also helps against ad blockers. It does not make cookies last longer by itself. A tracking subdomain that points through a CNAME to another domain, or that WebKit sees as a third-party IP address, falls under the 7-day cap. A ROASaurus tracking subdomain re-issues the visitor id as an HTTP cookie, but Safari may still cap that cookie at 7 days. Shopify's app proxy keeps requests on your store domain, but Shopify removes cookies from app proxy requests and responses, so the visitor id there is written by JavaScript and the 7-day rule applies.

What the shopper tells you

Shoppers can tell you how they found you, and that answer does not depend on cookies. A post-purchase survey asks after checkout. In ROASaurus, the Total Impact model combines the answer with the click data, and gives the survey 50% of the credit when there are also clicks.

How to check how much Safari affects your store

1. Find the Safari share of your orders

   In your analytics tool, group purchases by browser. Count Safari on Mac, iPhone and iPad.

2. Measure the time from click to purchase

   Find how many orders come more than 7 days after the ad click. In the ROASaurus attribution report, compare the 7, 14 and 28-day windows and see how much credit moves.

3. Compare pixel purchases with orders

   Count the Purchase events your pixel sent, split by browser if your platform allows it, and compare them with your orders for the same period.

4. Check your server events

   Make sure every paid order is sent server-side with hashed email and phone, and that the browser and server copies share one event id.

If a large share of your orders come from Safari, and many of them come more than 7 days after the click, browser cookies alone will under-report your ads. Purchases sent from order data, with hashed customer data, give the ad platforms another way to match those orders. You can see how ROASaurus does this on the server-side tracking page, and how it credits clicks in attribution.

Sources

1. WebKit: Tracking Prevention in WebKit
2. WebKit: Intelligent Tracking Prevention 2.2
3. WebKit: CNAME Cloaking and Bounce Tracking Defense
4. WebKit: Private Browsing 2.0
5. Apple Developer: Prepare your network or web server for iCloud Private Relay

In ROASaurus

• Server-side tracking in ROASaurus
• Attribution in ROASaurus
• Funnels and linked domains

Keep reading