What Intelligent Tracking Prevention (ITP) means for web analytics & marketing [Updated]

This post was originally published in May 2019.

Apple released its first version of Intelligent Tracking Prevention (ITP 1.0) in 2017. The following iterations, especially ITP 2.2 and 2.3, complicate an already challenging set of rules for how to hamper online tracking on Mac and iOS Safari browsers. In general, it strives to restrict cross-site tracking and further limit cookies.

We’ll get to the details shortly, but it’s important to mention the context of the successive updates. Big tech and advertising players have for years been in a quiet arms race to impose their vision of data privacy on the internet.

ITP is Apple’s latest weapon of choice. In this race, Google announced that besides features granting more transparency and control to users, they would stop supporting third-party cookies. The last player, Mozilla, is trying not to fall behind. Their browser is equipped with Enhanced Tracking Protection to increase user privacy.

The technical aspects are important, and it’s no exaggeration to say that the fight over these tracking standards will affect businesses big and small around the world.

Today we’ll dive into the most recent modifications and two previous iterations. But first, let’s start with the basics.

What is Intelligent Tracking Prevention (ITP)?

The Safari browser, both desktop and mobile versions, blocked third-party cookies by default before the ITP mechanism was introduced. It turned out that this measure wasn’t enough to safeguard users’ privacy, so Apple went one step further.

To tighten up this protection, Apple introduced a mechanism that changes how Safari deals with first-party cookies to restrict how AdTech companies track people online. The aim of this solution is to reduce the intrusion of tracking users and minimize how long companies store data on people.

This is where Intelligent Tracking Prevention comes into the picture. It’s a feature developed for WebKit, an engine that powers Safari and other browsers, that “reduces cross-site tracking by further limiting cookies and other website data.” Developers designed it to recognize and then prevent domains with tracking capabilities from following users across the web using first-party cookies.

How ITP 2.1 affects web analytics and advertising

In a nutshell, the introduction of ITP 2.1 will disrupt the way you track, analyze, target and measure Safari users. It strikes at the core of the online advertising system since it impacts how you can identify a person browsing the Web. And there’s also GDPR to deal with, including its requirement to obtain user consent if you want to set a cookie on their browser. For clarity’s sake, we’ll break this down into smaller chunks.

Client-side cookies get 7 days to expire

Let’s start with some essential information on cookies. They can be set in two ways — either via server HTTP responses, i.e. server-side, or you can set them via JavaScript’s document.cookie API, the so-called client-side.

The biggest modification in ITP 2.1 applies to client-side cookies, which are restricted to seven days. So, all cookies (even first-party) created via the JS document.cookie API will be set to expire in a week, regardless of their existing expiry date. On the bright side, server-side cookies set in HTTP response stay intact.

Keep in mind that when you go for cookies created via HTTP response, the JavaScript code will have trouble accessing them if they have the HttpOnly flag set.

Cookies are inherently harmless and first-party cookies are an indispensable element of a good user experience, making browsing more convenient. They play a significant role in:

• session management: logins, shopping carts, game scores
• user privacy controls & settings

It’s hard to imagine the Web without them. However, since they can be used for cross-site tracking of users, they are a significant concern of ITP 2.1.

ITP will affect web analytics metrics and reports

Since ITP 2.1 modifies the way browsers handle cookies, this will influence your analytics metrics and overall reports. It will impact not only unique visitors and new vs. returning visitors but also sessions to conversion and days to conversions. Those are just a few examples.

What’s more, all metrics and reports based on visits from Safari may be distorted because of the 7-day limit. That said, things can get even trickier, because the cookie’s 7-day expiration date will be reset if the user visits the website again within that period.

Additionally, this 7-day cap will result in an increase in the number of visitors, more new ones, because your analytics software won’t be able to identify returning visitors if they come after seven days have passed.

Nonetheless, ITP will only affect part of your data as Safari traffic is probably not the only type you get, and not all browsers have implemented ITP 2.1.

A/B testing will be impacted

Firstly, you’ve got only a 7-day window to test the performance of your site and track the results. This is a significant drawback taking into account that visitors who come less than once a week will be treated as new ones. Ultimately your A/B testing results will be inaccurate.

Besides, the chances are high that you employ third-party tools for split testing, and these tests very often rely on third-party cookies to make sure a given visitor will regularly see the same variation.

Disruption of conversion tracking, attribution, visitor profiles

In short, ITP 2.1 makes conversion tracking, attribution and visitor profile data less accurate. All cookies created by document.cookie will be set to expire in 7 days, unless the cookie is updated beforehand.

Tracking, attribution and visitor profiles will be affected if the person is using Safari and if they don’t visit the website regularly — first-party cookies will cease to exist if not reset within 7 days.

For example, someone comes to your website from a Facebook ad, views the advertised product, leaves your site. When they come back 9 days later and purchase the product they viewed previously, that conversion won’t be attributed to the Facebook ad.

Yet, if the same person came back to your site within 3 days and made a purchase, the conversion could be properly linked to the Facebook ad, provided their cookie was recognized.

Another process that falls prey to ITP 2.1 is attribution, which is generally now harder to execute. By cutting down the tracking window, marketers can only attribute conversions that happen within 7 days of a visitor’s first visit.

That might skew reports, since the credit for a campaign’s success can be misattributed, relying too much on the last marketing touchpoint. There’s a risk that you will overspend on a channel that isn’t necessarily the top performer.

Retargeting won’t be possible

Since online advertising relies on cookies, the modifications introduced by ITP 2.1 will have profound implications on targeting and retargeting ad campaigns to Safari users. This is not only because of the 7-day tracking window, but also because both targeting and retargeting rely heavily on third-party cookies, which are blocked by default.

Removed support for Do Not Track (DNT)

One of the changes introduced by ITP 2.1 was to withdraw support for the Do Not Track setting. This was because many websites don’t respect visitors’ decisions and continue tracking people even when DNT was on. Apple explains that the feature has already “expired.” In fact, AdTech and MarTech vendors didn’t adopt the standard widely enough, so the decision is understandable.

Despite that, in regards to the advanced privacy mechanisms provided by Safari, this move won’t have a significant influence on protection of users’ personal information.

Intelligent Tracking Prevention 2.2 (ITP 2.2)

On April 24, 2019, Apple revealed that in two months it would launch another iteration of Intelligent Tracking Prevention, ITP 2.2 that would crush cross-domain tracking with link decorating.

However, version 2.2 also limits first-party cookies’ lifespan to 24 hours under specific circumstances when used for tracking. That’s a really big deal.

As noted by Amanda Martin from Goodway Group, “Many actions advertisers are interested in attributing back to digital marketing efforts that happen outside the newly implemented 24-hour window, creating a blind spot for advertisers and brands.”

This means that when a user clicks on your product’s ad on Friday and they spend the whole weekend thinking it over, when they come back to your site on Monday the cookie has disappeared. The browser will treat this person as a new visitor.

At the same side, Intelligent Tracking Prevention 2.2 acts on only some specific client-side cookies. It’s aimed at persistent cookies that websites drop on the visitor’s browser on behalf of another company that Apple defines as one that can perform cross-site tracking.

What’s link decoration?

Intelligent Tracking Prevention 2.2 targets a method called link decoration, which lets you attach information to a URL clicked by a visitor in order to send this data to the destination site.

Let’s have a look at one example: https://www.website.example.com?utm_source=googleads&utm_medium=cpc&utm_campaign=winter-sale

What you see after ? is a query string consisting of different parameters, e.g. medium, campaign. All the extra information, the whole string, in the URL is a link decoration. Employing one is a common and harmless tactic used for ad click attribution.

This attribution should provide you with information about which ad a visitor clicked on and at which website, but without capturing the user’s identity.

You can employ it, for instance, in newsletters to know that a person landed on your page from a link in your email. Furthertmore, ITP 2.2 cookie expiration rules don’t apply to such generic parameters that don’t identify the user.

Unfortunately, tech giants employ link decoration as an ITP workaround, pass data like user ID or click ID in the URL to other sites and then persistently track people. This practice is called cross-site tracking via link decoration.

How does ITP 2.2 work against link decoration?

Most importantly, to counteract the process, two requirements must be met. First, Safari’s engine must classify an original domain as having cross-site tracking capabilities, by using a machine learning model. Second, a destination URL must be decorated. For more details on this categorization method, check out this article by WebKit.

This is a tricky issue, so we’ll walk you through the process step-by-step.

Imagine a visitor browsing social-network.com who sees an ad for a product from shop.com. Let’s say that Safari acknowledges this domain as one that can track users across multiple websites.

When the visitor clicks the ad, the website they’re on redirects them to another one that has the URL shop.com/?clickID=123. Thanks to this unique identifier in the URL – clickID=123 – it’s now possible to track that user.

Even so, to capture that clickID by the ad platform, the destination website, shop.com, must first have implemented a JavaScript tag so that platform could save the ID and create a first-party cookie.

Next time, when the user returns to the same page, loading that tag means Safari will recognize the clickID in the first-party cookie. As a result, platforms such as Facebook or Google will be able to measure conversions.

Thanks to unique identifiers such as clickID, websites can identify and track users as they move across different sites. What’s more, when a visitor shares a decorated link, their unique identifier can end up on another person’s browser and then connect these two individuals.

Here the ITP mechanism comes into play, and any cookie set by the website shop.com via the document.cookie method will expire after 24 hours, regardless of the specified expiry date or maximum age.

On the other hand, this technique works on top of ITP 2.1. It means that if a website is not marked for a one-day cookie cap, cookies created by document.cookie will expire in seven days (as mentioned in the ITP 2.1 section).

Intelligent Tracking Prevention 2.3 (ITP 2.3)

On September 23, 2019, Apple introduced the newest edition of ITP 2.3 that takes blocking cross-site tracking another step forward.

Although the previous release seemed to get in the way of persistent tracking, companies were sidestepping the ITP 2.2 workings. Apple addressed this problem in two ways.

Limiting the lifespan of non-cookie website data

Organizations have been employing link decoration to pass identifiers from one website to another, but instead of using cookies for storing these IDs they were employing non-cookie methods, such as localStorage. Contrary to cookies, these have an unlimited lifespan.

With ITP 2.3, WebKit’s experts aimed at reducing the lifetime of such data. The mechanism is similar to the previous iteration of ITP.

First, if Safari classifies a domain as one with cross-site tracking capacity and has a decorated link that a visitor clicks to go to another website, the browser labels non-cookie website data for deletion. If the visitor doesn’t interact with the destination site within 7 days, the ITP mechanism will delete the data, for instance, from localStorage.

Consider this example: a user enters social-network.com and notices a TV ad from shop.com. As the person clicks the ad, the browser redirects them to another site with the URL shop.com/?clickID=123.

Then, when the domain is classified according to the above requirements, ITP will mark shop.com for non-cookie data deletion. If the user doesn’t come back within seven days, Safari will erase the non-cookie data.

However, if the visitor returns within that time, Safari will reset that period. In other words, data will stay in the browser’s localStorage for another week.

Downgrading document.referrer

Another technique ITP 2.3 introduces to thwart user tracking applies to document.referrer. Some domains with cross-site tracking capabilities started decorating their own URLs instead of that of the destination page, and then read unique identifiers through document.referrer on the destination page.

That’s why ITP 2.3 aims to downgrade the document.referrer. But first, the same requirement we’ve mentioned in the previous section must be met.

Let’s take a closer look at the example of the social-network.com visitor. They see the TV ad from shop.com, then click the ad so the browser redirects them to another site under the shop.com domain.

In this case, ITP interferes and cuts the information the document.referrer contains, that is social-network.com/?clickId=123. As a result, when the website wants to retrieve this clickID from the URL through document.referrer, ITP will ensure that only the top-level domain will be returned, that is, social-network.com.

The impact of ITP versions 2.1 – 2.3 on Piwik PRO

Piwik PRO of course uses cookies, just as all analytics platforms do. But at the same time, we have ways of collecting data without cookies or with their limited lifespan. We are working on finding the best measures to protect individual personal information, just like Apple is, while still meeting the needs of our analytics clients.

Since users’ identities are of fundamental importance, maybe it’s time for AdTech companies to take their privacy-friendly marketing to the next level. For instance, in Piwik PRO we offer two solutions to respect people’s choice to remain anonymous online while simultaneously letting you implement multiple marketing initiatives.

The first relies on anonymous data. This method delivers numerous benefits. Above all, it offers you a reasonable middle ground between doing useful analytics, digital marketing and ITP.

In Piwik PRO, when you enable anonymous data tracking, you won’t store a visitor ID or IP address and we will disable device fingerprinting. Finally, we use session cookies for anonymous data collection, which are deleted automatically after 30 minutes, and we don’t apply them for persistent tracking.

Furthermore, anonymous data allows you to stay compliant with GDPR, since you don’t gather personal information.

This is particularly important considering the recent consent and cookies guidelines released by various European data protection authorities. They all say that when you can’t identify an individual, you don’t treat the data as personal. Yet, under the GDPR this kind of data doesn’t require any additional safety measures.

Another solution where cookies don’t cut it is device fingerprinting. This technique creates some confusion mostly related to privacy issues. Still, there’s a safe and lawful way to employ it without intruding on people’s personal space online – this is consent. You need to obtain it before you gather a fingerprint.

Having site visitors’ permission lets your organization track users unobtrusively. That helps you match ads with user profiles and run targeted advertising while remaining compliant.

Show visitors that you respect their rights and inform them about your intentions – ultimately, leave the decision to them.

For instance, in Piwik PRO we store a browser fingerprint, but by default we use it only to have accurate information on user sessions. Moreover, we use it when the visitor agrees to that or when anonymous tracking is disabled.

How does Intelligent Tracking Prevention relate to GDPR consent?

When considering the implications of ITP concerning cookies, it’s worth giving attention to users’ consents.

Some questions arise, like: how do you save consents? Can you store consents for Safari users for longer than a week?

When it comes to Piwik PRO Consent Manager, a user’s consent is stored in a first-party cookie and localStorage, as we don’t want to irritate visitors and display them consent pop-ups every seven days.

The mechanism is very similar to the one we use to store analytics visitor ID. What’s essential here is that the data saved in the first-party cookie does not identify the visitor’s settings – it holds only information about categories of data processing the person agreed to. That’s the same as keeping information on the language version selected for the site, it doesn’t allow for any user identification.

Finally, with ITP 2.1, opt-out cookies will be deleted after this period.

How to work with ITP and still get good data

As we’ve seen, ITP poses some serious challenges to marketers and web analysts. Nonetheless, with the right approach you can adjust your methods to it, obtaining useful data without invading users’ privacy. Here are some practical solutions.

You can start with using the browser’s localStorage as a fallback mechanism to make sure that the visitor ID cookie won’t be purged (deleted) after 7 days. In this case, you can use localStorage to recreate cookies after the visitor returns to the website. Of note, this solution will work as long as the website won’t fall under the ITP 2.3 classification of cross-site tracking.

Another option would be to set cookies on the server side. For this, you would create a subdomain to act as an endpoint (e.g. cookies.example.com) for setting cookies on the server side on both the root domain (e.g. example.com) and all subdomains (e.g. blog.example.com). ITP won’t impact cookies created in this way. To get more technical explanations about these two solutions, check out this exhaustive post by Simo Ahava.

Ultimately, your choice of one of the many accessible solutions will depend on a number of factors, such as the number of domains you want to track. Most of these solutions will require both the web analytics platform and the person operating the website, e.g. web analyst or web developer, to make some additional configurations.

Tech giants competing for the crown of most “privacy-conscious”

ITP might feel like a dark cloud hanging over the digital ecosystem. Some even call it a “war on cookies”. In fact, it’s a response to privacy concerns about cross-site tracking of users. Apple has made this a big part of their selling point to users, but it’s far from the only one. Take, for instance, Firefox, which blocks third-party cookies by default. And Google’s latest news on killing off third-party cookies to provide more safeguards over visitor’s private information.

We’re happy to see these issues taking a more prominent place in public discussions. However, it still remains to be seen what all this talk about privacy protection will mean in practice.

Worry not, we’re here to help and keep you updated. If you have questions about how all these changes might affect your analytics, drop us a line.