Everything about intelligent tracking prevention_Magic Pixel

Intelligent Tracking Prevention (ITP) with tag management

In more ways than not users felt powerless on how they browse and how browsers enabled marketers to track their moves. ITP wanted to put onus back on user treatment. So, it’s no longer just about websites, it’s the way you track the users and how you honor their preference. 

Cookiestatus.com already has rich information about tracking prevention and protection. Then, why do you need this resource that also talks about tracking prevention and protection. MagicPixel wants to provide this resource giving context and guidelines on how tagging and tracking should be implemented in accordance with ITP changes using a Tag Management solution built to support it.  

A marketer’s job is to look for acquisition channels which give maximum bang for the buck. In common parlance it is referred to as ROAS (Return on Advertising Spend). With ITP enforced by browsers, it has become difficult for attributing conversions to the acquisition channel.  

Magic Pixel provides additional tools that can help extend the duration of cookies for a longer period after obtaining consent from the user. This helps companies to accurately attribute conversions to the campaign and/or acquisition channel and adhere to users’ privacy requirements”

In this coverage, what we intend to do is provide as much information as possible about ITP. But, we have some break-out sections which highlights the tools that Magic Pixel has figured out for you. 

If you are already aware of ITP, skip to the sections relevant to you.

Introducing Intelligent Tracking Prevention or ITP (latest version)

This brings us to evaluate and understand Safari’s Intelligent Tracking Prevention (ITP) that was launched during the launch of Safari 11 in 2017. The third-party context still exists even after the 2017 launch. 

Safari’s ITP has gone through its own curve of evolution. Third party cookies cannot be tracked, but ITP over time has made it difficult to track first-party cookies too.

1.0First-party cookies trackability allowed for returning users (within 24 hours only). 
1.1Storage Access API included for allowing websites with embedded content to access third-party cookies
2.024 hour window for first-party cookie trackability scrapped.
2.1First-party cookies created through JavaScript’s Document.cookie API got expired in 7 days
2.2Prevention against link-decoration. 7 day window in ITP 2.1 shortened to 24 hours
2.3More prevention against link decoration. All non-cookie storage data, which includes localStorage expires after 7 days
Courtesy: webkit.org

Version 1.0 

A first-party cookie is created when a user visits your website after clicking an ad. Most often, this is created by the adtech platform. If the user visits this website (the destination website) in the next 24 hours, the first-party cookie would be used for retargeting.

But, if the user does not visit the website in 24 hours, but let’s say after 2 or 4 days, ITP prevents them from using the tracker for retargeting. In this version, single sign on sessions still could be used.

Version 1.1

This version’s focus was mainly to address video-subscription services or third-party payment providers. They were most affected by version 1.0 since embedded content could not be used for user authentication. Version 1.1 of ITP released a Storage Access API. This allowed for embedded content across websites to authenticate users that are already logged in to first-party services, such as Facebook.

Courtesy: webkit.org

Version 2.0

ITP 2.0 has turned around many things. It gave more power to users. It prevented companies from tracking users by default. The browser prompted the user on the screen, providing a choice to accept or refuse cookie storage. 

Another critical update brought by this version was to remove the 24-hour cookie access window. This impacted affiliate marketing.

Courtesy: webkit.org

The Machine Learning Classifier detected domains were present for the sole purpose of tracking users via navigational directs. Safari ITP 2.0 protected users against first-party bounce trackers. In this version the user’s browsing history was being stored as first-party cookies.  

ITP 2.0 included use of machine learning algorithms to detect situations where trackers are communicating with each for sharing information regarding the user through a collusion graph. Tracker collusion is another important update.

It also ensured that the referrer information is not passed on to third-party trackers. However, in case the user clicked on their ads, user information was shared with these third-party trackers.

Version 2.1

Storage Access API became the major access point for all types of cookies, including partitioned cookies with ITP 2.1. The earlier versions allowed third-parties to utilize partitioned cookies for getting access to first-party trackers. With this update, they are required to use the Storage Access API for getting cookies. 

This version also focused on the cookie expiration. The client-side cookies, which are the cookies created through JavaScript’s Document.cookie API, got expired in 7 days. However, these cookies still had access to server-side cookies, created via server HTTP responses. This was possible only if they didn’t have an HttpOnly setting.

Here is what comes from Webkit:

“Authentication cookies should be Secure and Http-only to protect them against man-in-the-middle attacks, cross-site scripting attacks, and speculative execution attacks […] Only cookies created through document.cookie are affected by this change.”

– John Wilander, WebKit

In this case, the cookie is treated like a login cookie set by your own servers, this solution would be future-proof as long as the cookie is coming from the server. 

Version 2.2

ITP 2.2 prevented cross-site identification and tracking of users using link decoration. 

“Link decoration” is a method used to pass information through code added to a URL. Due to third-party cookie restrictions in earlier versions of ITP, AdTech companies used link decoration as a workaround. 

Courtesy: webkit.org

The cookie duration was reduced from 7 days to 24 hours. The machine learning algorithm could also identify first-party cookies dropped by a website for tracking users on behalf of other companies.

Version 2.3

The loophole of link decoration has been fixed by Apple in the latest ITP 2.3 release by enforcing a seven-day limit on all non-cookie storage data, like local storage — a type of web storage that allows sites to store data directly in the browser typically with no expiration date.

ITP 2.3 now ensures that all non-cookie storage data, which includes localStorage, expires after 7 days. The expiry date, however, will be reset if the user visits a destination website within 7 days.

Intelligent Tracking Prevention is a great step from a user’s privacy perspective. But, if you are the guru of cross-site tracking, ITP would be an apocalypse. ITP has led to full third-party cookie blocking for Safari users. 

After successive updates to Safari, it has become increasingly difficult to track users using first-party as well as third-party cookies. Future releases would effectively render third-party tracking ineffective.

What’s the big deal about ITP blocking cookies?

Safari is the default browser on all Apple devices. It is the second most popular browser worldwide (after Chrome) — with an approximate 18% global market share. In North America, Safari is being used by more than 52% of mobile users.  

Marketing attribution models you have employed so far need to be changed to adjust to the new norm. Attribution window has been significantly altered due to ITP changes. 

Here’s what Apple’s Safari ITP implies to marketers and their cookies:

First party cookies: 

ITP limits on how long data can be stored using these cookies. First-party cookies are created and set by the domain owner. This is for the user visiting your website. They are used for purposes like remembering your login name, what’s in your shopping cart, cookie consents, and site personalization.

Third party cookies:

ITP completely blocks third-party cookie tracking in its Safari browser. They are placed by third-party vendors and advertisers on sites that are used to track the user for many reasons. Some of them are site analytics and social widgets, ad personalization and retargeting.

How can Magic Pixel help with the cookie-limitations enforced by ITP? 


ITP doesn’t limit all first-party cookies — just ones set via JavaScript. 

Reality Check:

Cookies set on the server-side, those using the Set-Cookie header in the HTTP response can live indefinitely in the browser. It is not completely anti-publisher. It prevents third-party JavaScript tags from dropping first-party cookies whenever they want to. It allows publishers to freely set their own cookies.

Magic Pixel enables you to test your tags in a staging environment while you make incremental transfers from client-side to server-side tags. You can test the performance before you launch and stay prepared for any anomalies to occur with your tags.

Earlier, AdTech companies used workarounds such as leveraging browser’s localStorage for storing data about users allowing them to track users without having to create first-party cookies. This now effectively stands blocked. ITP 2.3 now ensures that all non-cookie storage data, including localStorage, expires after 7 days. If the user revisits the website within 7 days, the expiry date will be reset. 

Behavioural targeting will make way for contextual targeting. Native ads will see an uptick.  

This is a way to make everything first-party data.  

If your website has a decent traffic from Safari users, you will be impacted heavily by these changes. Magic Pixel will continue to track future ITP releases and keep you updated. MarTech and AdTech are going through a major upheaval. Future-proof your business by investing in first-party data collection. 

In the subsequent episodes of this series, we will be addressing cookie duration extension and impact of ITP on publishers and advertisers.