Safari ITP - everything you need to know

Safari ITP, developed by the WebKit team at Apple, has been at the forefront of combating invasive data collection when it comes to web surfing. In a revolutionary move against third-party cookie tracking tactics, they imposed limitations that drastically reduced third-party cookies' lifetime duration to 7 days or even 24 hours. However, companies soon found an effective workaround to this limitation with the help of server-side tagging set on a custom domain.

In autumn 2022, Safari announced a new change in how they treat cookies. They capped cookie lifetimes to 7 days for responses from third-party IP addresses. So, we at Stape created a Cookie Keeper power-up and Own CDN feature.

In this blog post, we will describe how the limitation of cookie lifetime based on the IP address works and what it means for web advertising and analytics. And, of course, how Stape can help with the new restriction.

Safari Intelligent Tracking Prevention (ITP) is a privacy feature introduced by Apple in the Safari browser to limit cross-site tracking by restricting how cookies and other tracking technologies function. ITP uses on-device machine learning to identify tracking behavior and enforces rules that reduce advertisers' and data brokers' ability to track users across different websites, affecting how analytics, ad attribution, and user targeting work on Safari.

Apple's ITP, which first made its debut in 2017, has seen multiple transformations to become increasingly restrictive with each iteration. Safari's main goal regarding ITP tracking limitations is restricting advertising and analytic networks from profiling users across different websites. This cap helps to raise user privacy and prevent unwanted tracking of users' online activities. But on the other hand, this can make it more difficult for advertisers to target users with personalized ads and track the effectiveness of their advertising campaigns.

Let's dive into more details on the existing restrictions and disadvantages of using third-party cookies for browsers based on WebKit.

First-party cookies are small data files stored on a user's device by the website they visit. If the website is example.com, first-party cookies will be considered those set from the main domain example.com and all subdomains blog.example.com, app.example.com, etc.

They are used to store information about the user's preferences, such as login credentials, language preferences, and shopping cart items. Since first-party cookies are set by the website being visited, they are considered "first-party" and are generally not subject to the same privacy restrictions as third-party cookies.

Third-party cookies are those set outside of your domain. For example, when facebook.com or google.com set cookies on the domain example.com, these are considered third-party. Third-party cookies are often set by advertisers or tracking companies to collect information about a user's behavior across multiple websites.

Safari has been regularly updating its ITP feature to restrict the use of third-party cookies' further and improve user privacy. Here is a short timeline of the critical updates to Safari cookie lifetime:

Advertisers who rely on third-party cookies to track user behavior and serve targeted ads may see a decline in the effectiveness of their campaigns when users are browsing Safari. This is because the browser's restriction on third-party cookies prevents advertisers from collecting user data across multiple websites. As a result, they may see a decrease in conversions and a lower return on investment for their advertising spend.

Ad networks use third-party cookies to collect data about users who visit different websites by assigning the same user a unique third-party cookie. This way, they can see what websites users browse online and understand their interests. Ultimately, they use this data to show ads based on the user's behavior and interests. 

Since Apple ITP limits the use of third-party cookies in Safari, this results in less accurate user profiling and, thus, less compelling interest or behavioral targeting. As a result, advertisers spend less money on paid campaigns because of low results. 

The second critical use case of third-party cookies in cases of advertising platforms is utilizing a click ID. When a user clicks on the ad, most advertising networks add a unique click ID to the URL and store the click ID as a third-party cookie or first-party cookie set by JavaScript in both cases, they will be subject to ITP. When a user converts, this click ID is used to understand which conversion should be attributed to which campaigns. 

ITP Apple makes it difficult for affiliate networks to attribute sales and commissions to the correct affiliates, as the cookie data used for tracking may be deleted after just seven days, and for the known cookies (e.g., facebook click id and google click id) the cookie's lifetime can be reduced to 24 hours when set via JavaScript code.

This is the reason why many popular affiliate networks have started making server-side tracking implementation mandatory for publishers. With the help of server-side tracking, it's possible to set first-party cookies and rely on a longer cookie lifetime. 

Remarketing is a technique where advertisers show targeted ads to users who have previously interacted with their website. This is typically accomplished by using third-party cookies. Since a user who visited your website in Safari can stay in the remarketing pool for only 7 days, the size of the remarketing audience will decrease.  

Analytics platforms use cookies to identify whether a user is new or has already visited your website. If a Safari user does not revisit your website every 7 days, they will be considered a new visitor. And it will have a substantial negative impact on user journey, conversion analytics, etc.

WebKit's restriction on third-party cookies may have initially seemed like a roadblock, but an effective solution was soon discovered. By employing server-side tagging, web developers could bypass this issue.

In the case of server Google Tag Manager (sGTM), if you set up a tagging server URL located under your main site domain, like ss.example.com for the website example.com, the tagging server can set first-party cookies, which will increase the cookie lifetime to the default settings. 

After advertisers found this solution, WebKit tried to restrict it even more. Their main concern was CNAME cloaking, which was later curbed. CNAME cloaking is designed to outwit ITP so that it would treat third-party cookies as first-party cookies. If ITP Safari detects CNAME cloaking, it  limits JavaScript first-party cookies to the same 7 days as it would limit third-party cookies.

Whenever a new ITP detects that the IP address of the URL that tries to set cookies is different from your website's domain, it cuts cookies' lifetime to 7 days, whether it's first-party or third-party. For example, your website example.com points to IP 1.1.1.1, and you previously used server-side tagging to increase cookies' lifetime. Let's say you use the tagging server ss.example.com, which points to 2.2.2.2 to set first-party cookies. Apple ITP will detect that example.com and ss.example.com have completely different IPs. In this case, it will treat cookies set by the tagging server ss.example.com as standard third-party cookies, limiting cookies' lifetime to 7 days. 

Safari won't decrease cookies' lifetime if the IP address of the domain that sets first-party cookies is half matching (i.e., 16 for IPv4, and 64 for IPv6). So if your main site IP address is 1.1.1.1, then cookies are set from the subdomain that points to the IP, which starts with 1.1. will be considered the first party, and its lifetime won't be cut. But WebKit says they might change the first 50% match rate rule. 

This new release brought everyone back to where they were using third-party cookies. When a user browses your website in Safari, first-party cookies will live for up to 7 days, unless they are set from the domain whose IP matches at least 50% of your website IP address. 

Yes! And it's easy to prolong cookies in Safari with the help of Stape using solutions such as:

• Same origin domain.
• Cookie Keeper power-up.
• Own CDN.

A same origin custom domain for sGTM involves configuring your sGTM container to run on a specific path of your main website domain (e.g., example.com/sgtm) instead of a subdomain (e.g., sgtm.example.com).

This approach, encouraged by Google, provides significant benefits for data collection, primarily by enabling the use of first-party cookies with extended lifetimes, even in browsers like Safari that impose shorter cookie expiration periods for subdomains. While more complex to set up, requiring a CDN or load balancer, it ultimately leads to more accurate and consistent user tracking and data collection.

An advantage of this approach is that it can be configured using different methods, while Own CDN can be set up via Cloudflare only.

We have a detailed guide on how to configure same origin custom domain.

This is an ITP solution developed by Stape. It is easy to configure if you use the Stape app, which we list below, although it is also possible without the Stape app. It is ideal if the same origin or own CDN cannot be configured in your case.

This power-up helps to make sure that your marketing cookies are active all the time, even if they get deleted. Cookie Keeper comes with a "master cookie" - a special tracker that identifies each visitor's unique ID on your website. This cookie is stored as a first-party cookie and it lets you comply with all Safari ITP cookie rules. So when the marketing cookies are deleted, the "master cookie" provides information to restore them. This means you can still see how people are using your website and how well your advertisements are working, even if the original cookies were deleted.

Download our apps for:

• Wordpress
• Shopify
• Magento 2
• BigCommerce
• Wix
• PrestaShop
• Salla

Stape develops new solutions and updates a list of CMS apps. For an up-to-date list, please check the CMS page.

To configure the Cookie Keeper power-up using the CMS app, please follow the configuration instructions. 

If the platform you use isn't on the list above, you can also configure the Cookie Keeper power-up; instead of the standard GTM loader, you will be given JS code that must be added to your website.

Please refer to our helpdesk article on Cookie Keeper for a detailed step-by-step guide.

Own CDN is an option that was used before the same origin domain emerged. In terms of bypassing ITP, it is just as good as the same origin domain. So, if you find it more convenient, feel free to use it, just follow the instructions on Own CDN from the helpdesk guide.