What Is Intelligent Tracking Prevention and How Does It Work?

AdTech Industry, Data & Privacy

What Is Intelligent Tracking Prevention and How Does It Work?

Apple has built a strong reputation as a leader in tech innovation, and has stayed at the forefront of user privacy protection as well. With its update of iOS 11 and Safari, the company is taking the privacy of its customers one step further with a feature known as Intelligent Tracking Prevention.

What is Intelligent Tracking Prevention?

Intelligent Tracking Prevention is a new feature of Webkit, an open-source web-browser engine that powers Apple’s Safari web browser, among others, shipped out in the new release of Safari 11 and iOS 11.

The feature aims to further protect users’ online privacy by changing the way Safari handles first-party cookies.

How Does Intelligent Tracking Prevention Work?

Before the notion of Intelligent Tracking Prevention, Safari desktop and mobile browsers blocked third-party cookies by default and allowed iOS users to block ads by installing Safari extensions, aka content blockers (available from iOS 9 onwards).

First-party cookies have traditionally been safe from any sort of automatic blocking or removal, as they are responsible for providing a seamless user experience.

For example, first-party cookies can keep the session information open, which can remember things like:

  • our login status, which can be used to keep you logged into to websites and applications.
  • Which products you added to shopping carts.
  • Website settings, such as which language version you have chosen.
  • Values you’ve entered into forms (e.g. name, email, and company on a white paper download form).

However, some first-party cookies can be used to track users in the same way as third-party cookies, and the release of Safari 11 took aim at this kind of data.

When First-Party Cookies Become Trackers

Most people don’t associate first-party cookies with trackers, but there are certain situations where this is possible, and this is where things start to get a bit tricky.

To help explain this point, let’s look at an example of how a first-party cookie could be used to track users across the Internet while using either a desktop or mobile Safari browser (or any other web browser).

Example — A User Clicks on an Ad

For this example, we’ll look at it how this process works with Safari browsers, but it would work in a similar way on other browsers — depending on how they handle first- and third-party cookies.

How a first-party cookie is created by an ad retargeting service

Here is what’s happening in the image above:

  1. The user visits a website and a first-party cookie (xzy890) is created by the website in its domain (example.com) and assigned to the user.
  2. The user then clicks on the ad and is directed to the AdTech platform’s domain (ad.ads-r-us.com).
  3. The AdTech platform creates a first-party cookie (klm456) under its domain (i.e. ads.ads-r-us.com) and assigns it to the user.
  4. The AdTech platform then redirects the browser to the advertiser’s landing page (www.usedcarsite.com).

It’s important to note that the reason the AdTech platform is able to create a first-party cookie is because the user clicked on the ad, which was then directed to the AdTech platform’s domain. If the user had not clicked on the ad, then the AdTech platform wouldn’t have been able to create a third-party cookie, as Safari blocks them by default.

As the AdTech platform has created a first-party cookie under its domain (ads-r-us.com) and assigned it to the user, it can now track the user as they move around the web and serve them with personalized ads.

However, this ability for first-party cookies to act as trackers changed slightly with the release of Safari 11.

Here’s a brief breakdown of how Intelligent Tracking Prevention works:

1. Intelligent Tracking Prevention incorporates a machine-learning model (known as the Machine Learning Classifier) to assess which privately controlled domains have the ability to track users across different websites. This model is based on statistics collected by the browser.

2. If the Machine Learning Classifier identifies that a particular first-party cookie (e.g. ad.ads-r-us.com) can be used for tracking, then the cookie will be blocked unless you use the Storage Access API to ask users to allow the use of your cookie (more on that below).

So far there have been three releases of ITP — 1.0, 1.1, and 2.0.

Before diving into the most recent release (2.0), let’s take a look at how the first two releases worked.

Intelligent Tracking Prevention (ITP) Versions 1.0 and 1.1

To explain how the first versions (1.0 and 1.1) of ITP worked, we’ll take a look at some scenarios:

Scenario #1

In versions 1.0 and 1.1 of ITP, there was a featured that allowed first-party trackers to behave like third-party trackers as long as the user visited the website within 24 hours.

Here’s how it worked:

Intelligent Tracking Prevention after 24 hours of clicking on an ad

A user visits a website (example.com) and clicks on an ad. The AdTech platform (ads-r-us) displaying the ad would create a first-party cookie for that user. If the user then visits ads-r-us.com within 24 hours after clicking on the ad, then the first-party cookie from ads-r-us.com would be able to function as third-party trackers from then on.

In this case, the cookie could have been used in a third-party context, e.g. for retargeting.

It’s important to note that in order for this situation to work, the user would have had to actually visit the AdTech platform’s website, which is unlikely to happen as most users don’t regularly visit these types of websites. It’s a different story for walled-garden advertising companies, such as Google, Facebook, and Amazon (more on this below).

However, Intelligent Tracking Prevention 2.0 completely scrapped this 24 hour window, meaning that if a domain is deemed to have tracking capabilities, then it can’t be used in a third-party context unless the user agrees via the Storage Access API (see below).

Scenario #2

The user doesn’t visit ads-r-us.com within 24 hours of clicking on the ad. However, they do visit the site 3 days after clicking on the ad.

Intelligent Tracking Prevention 30 days after clicking on an ad

In this case, as the user didn’t visit ads-r-us.com within 24 hours, the cookie created by ads-r-us.com cannot be used in a third-party context – e.g. it can’t be used for ad retargeting and would have to display a non-retargeted ad to the user.

Again, this scenario doesn’t apply anymore due to the Storage Access API.

Scenario #3

The user doesn’t access ads-r-us.com at all within 30 days of clicking on the ad.

Intelligent Tracking Prevention 30 days after clicking on an ad

In this case, the first-party cookie created by ads-r-us.com will be purged.

This is still the case with ITP 2.0, but is now controlled by the Storage Access API.

New Additions In ITP 2.0

The June 2018 release of ITP introduced a couple other major inclusions, which seriously impacted reporting, affiliate marketing and attribution techniques — more so than before.

Scrapping of the 24-hour cookie access window

As mentioned above, ITP 1.0 and 1.1 allowed cookies to be read and used in a “third-party context”, provided the user accessed the domain directly in the first 24 hours.

With ITP 2.0, this is no longer possible.

On Safari, websites can no longer leave cookies in the user browser for later retargeting and attribution purposes. This will impact companies which access their first-party cookies in a third-party context, and as a result compromise reporting capability and accuracy. The lack of a cookie access window is somewhat connected with user prompts for Storage Access API detailed below.

Prompt For the Storage Access API

The next major change to ITP is the introduction of the Storage Access API.

Sites like Facebook typically allow users to log in to their account on multiple websites to facilitate commenting or “liking” content on third-party sites. ITP 2.0 will now detect such cross-site tracking and partition its cookies, limiting its ability to be utilized in a third-party context.

Third-party embedded widgets like Facebook now have to request access to their first-party cookies when the user interacts with them on different websites by displaying a consent box.

consent box

Here’s an example of what this would look like:

It’s important to note that the user would be shown this prompt on every website they visit containing a Facebook embedded widget, except on subdomains — e.g. they wouldn’t be shown the prompt on video.example.com if they previously selected “Allow” on example.com.

If the user doesn’t interact with Facebook again, either via facebook.com or via their embedded widgets, after 30 days, then their cookies will be purged.

Protection Against First Party Bounce Trackers

ITP 2.0 has the ability to detect when a domain is used exclusively as a “first-party bounce tracker,” meaning that it is never used as a content provider and only tracks the user through a series of fast, navigational redirects.

First-Party Bounce Trackers work when the user clicks on a link on a social media website and then, instead taking the user straight to their destination, rapidly opens a series of bounce trackers.

Such tracker domains can store information about the user’s browsing history in their first-party storage and cookies. ITP 2.0 detects such behavior and treats those domains just like any other tracker, i.e. purges them.

Protection Against Tracker Collusion

Protection Against Tracker Collusion identifies redirects utilized for tracking purposes only — i.e. for piggybacking and cookie syncing. ITP 2.0 detects this behavior via something known as a collusion graph and classifies all domains involved in the redirects as trackers.

This feature will stop cookies from being dropped or read on a user’s browser during such redirects, which negatively impacts affiliate marketing and data sharing between AdTech platforms. We outline some possible solutions to this below.

Origin-Only Referrer for Domains Without User Interaction

This new feature in ITP 2.0 strips down the referring URLs domain, which is the URL the user is currently on, when passed to third-party trackers — e.g. when a user visits a website site containing third-party trackers (e.g. ads), the referrer information is passed to these third parties.

Here’s an example of what this looks like:

Before ITP 2.0 = https://ecommercestore.com/clothes/mens/business/shoes

After ITP 2.0 = https://ecommercestore.com/

Third-party trackers now have less information about the user than they did before, but this change does not limit data that can be passed in the URL to an advertiser’s site if the user were to click on their ad.

Which Companies or Services Are Affected By Intelligent Tracking Prevention?

The Intelligent Tracking Prevention feature is just another example of a privacy update that threatens the very thing upon which online advertising depends — cookies.

Therefore, the companies affected by ITP are ones that rely on cookies, especially third-party cookies, for running advertising and marketing services. This can range from retargeting ad vendors through to affiliate networks.

Which Companies or Services Are Not Affected By Intelligent Tracking Prevention?

While Intelligent Tracking Prevention affects most advertising and marketing vendors, there are some companies that may not be affected too much by the Safari 11 and iOS 11 release.

Web analytics and other marketing software relying on the first-party cookies: As long as the first-party cookie is used only in a first-party context, as is the case with Google Analytics or Piwik PRO Marketing Suite, then Intelligent Tracking Prevention will not block the software from setting cookies and won’t display the Storage Access prompt..

The reason for this is because these platforms set a cookie (via JavaScript) under the domain of the website the user is currently visiting and typically don’t track users across the Internet.

For example, if the Piwik PRO tag were installed on the www.example.com website, then it would set the cookie under the www.example.com domain. This cookie isn’t used in a third-party context because the software is used only within the www.example.com domain.

Now if Piwik PRO were used to analyze a different site, e.g. www.usedcarsite.com, then it would have a separate cookie set in the www.usedcarsite.com domain along with a separate site ID in the database.

Self-hosted or white-labeled software: Most companies that use self-hosted software won’t be affected by this change as in most cases the software is hosted under a subdomain (e.g. software.example.com), meaning first-party cookies will still be created when a user visits their site.

Also, some cloud-based software can be configured so that the software points to the client’s subdomain. This practice is known as custom domain support or domain white labeling.

However, there are very few AdTech companies that provide on-premises versions of their software or domain white labelling, mainly because:

  1. The user will be bound to a specific client, meaning they can’t track them across a whole customer base.
  2. The cookie-syncing process would have to be carried out separately for each custom domain, making it an unscalable model as it would have to support hundreds or thousands of customers.

It’s important to note that this point applies to all popular platforms in the ecosystem, such as data-management platforms (DMPs) and other marketing software. Companies will have to make changes to how their marketing and advertising tools handle third-party cookies and record conversions. Alternatively, they can use tools that can be self-hosted and white-labeled.

Walled-garden advertising ecosystems: While companies like Facebook and Amazon weren’t affected too much by ITP 1.0 and 1.1, the introduction of ITP 2.0 has changed this.

As mentioned above with the Facebook widget example, Google, Facebook, and Amazon will now have to get approval from users to drop cookies and access website data via the Storage Access prompt.

Possible Solutions and Workarounds for ITP 2.0

While ITP 2.0 spells bad news for a majority of independent AdTech and MarTech companies, there are a couple of things vendors can do to limit its negative effects, with the main one being using server-to-server conversion and event tracking.

In order to navigate ITP, Facebook and Google have come up with some solutions — Google have released a site-wide tag to help advertisers continue to measure conversions, and Facebook have released a first-party cookie option.

Final Thoughts

Major advertising groups have criticized Apple for releasing Intelligent Tracking Prevention as they feel it will threaten the economic model of the Internet, even though Safari browsers only account for about 14% of total browser usage across all devices, but the feature’s introduction is just one of many changes the online advertising industry will have to adjust to.

With the enforcement of the GDPR in May 2018 and with ePrivacy on the horizon, all companies operating in the digital advertising ecosystem will need to put more of a focus on protecting user privacy and complying with new privacy laws.

For the most part, this will involve making major policy changes and a lot of innovation.

Need help dealing with Intelligent Tracking Prevention and complying with the GDPR?

Schedule a call with one our AdTech and MarTech development teams and find out how our privacy-focused approach to software development can help your company.

Schedule a call

FREE AdTech & MarTech Resources

Thousands of C-level executives, software engineers, marketers, and advertisers all learn about the inner workings of AdTech and MarTech with our bimonthly newsletter — and so can you! Subscribe today and get access to the latest and best articles, videos, and guides!