Skip to main content

ITP management

Apple's Intelligent Tracking Prevention (ITP) is a technology aimed at increasing user privacy by preventing unwanted tracking by websites and the various scripts installed on them. It is implemented in all Safari browsers, including desktop computers (Macintosh) and all iOS devices (iPhone and iPad). ITP brings some major restrictions to the operations that JavaScript-based software can perform. While ITP primarily targets online advertising systems, the latest versions are much more aggressive and significantly impact web analytics software, such as Google Analytics. ITP also significantly impacts A/B testing tools, as we'll discuss in this article.

Kameleoon can be fully functional even with ITP-enabled Apple devices. However, you must insert a small section of synchronization code on your back-end servers.

This documentation article aims to raise awareness among web marketers on the following topics:

  • The technical limitations imposed by ITP.
  • The consequences on the operation of Web Analytics and Conversion Optimization software/
  • The details of Kameleoon's recommended solution to avoid being affected by ITP.

ITP Technical Restrictions​

Intelligent Tracking Prevention implements considerable restrictions around the use of cookies and other client-side storage (such as local storage). It is important to understand a few important characteristics of cookies.

Cookies are (very) small pieces of data that a website stores in a visitor's browser. Very often, they represent unique, randomly generated identifiers. Every cookie is tied to a domain (such as www.example.com) and has an expiry date. Any time a server call is made to any domain linked to one or more cookies stored on your computer, the data contained in these cookies is sent to that domain's web server, automatically and transparently. This means cookies are constantly being added to most web requests, with two immediate consequences:

  • The size of web requests increases, slowing your browsing speed.
  • Your browser transfers data to remote servers without your explicit consent, allowing you to be identified and tracked.

As cookies are usually quite small, the first issue is generally not that significant. However, the second is much more far-reaching and is of major concern to user-privacy advocates. Of course, this is a complicated topic, since cookies are used for many different purposes on the web. Many of them, due to the stateless nature of the HTTP protocol, are needed for basic website operations. For example, e-commerce transactions typically rely on them. With ITP, Apple aims to separate the "useful" cookies (those mandatory for the normal operation of a given web site) from the "bad" ones (those associated with advertisements, tracking, and privacy breaches).

Websites can set cookies using two different mechanisms:

  • When a call is made to a web server, the server sets the cookie by adding an HTTP header in the HTTP reply.
  • Using JavaScript code on the client.

The associated domain of the cookie depends on the method used. For server cookies, it is the domain where the server call was sent. For client-side JavaScript cookies, the domain is one of the pages where the JavaScript code is run from (not necessarily the JavaScript file's host domain). Third-party cookies refer to cookies sent to a domain other than the web page you're currently viewing. For example, if you're browsing www.randomshop.com, but that website makes a call to tracking.ad-system.com, cookies associated with www.ad-system.com can be sent along the HTTP query. They will be considered third-party cookies within the context of your current browsing session on www.randomshop.com.

When a cookie expires, your browser deletes it completely. However, as the expiry date is normally chosen by the entity that creates the cookie, it can be set very far in the future (for example, 10 years or more). This ensures that it lives far beyond what is necessary for normal operation of the original website. This is changing with ITP.

These are the two main restrictions imposed by ITP 2.3:

  • In all ITP versions, third-party cookies are highly restricted. The exact details are complex and out of the scope of this article, but in short, third-party cookies are blocked by Safari 24 hours after they are set in the browser. Technically, they are not deleted, but are no longer automatically sent to the third-party server via HTTP requests. In our previous example, a visitor coming to www.randomshop.com gets a cookie from www.ad-system.com via an HTTP call to that server during their first visit. If the visitor returns more than 24 hours later, the next HTTP request to www.ad-system.com won't get the original cookie data as Safari will not send it.
  • Starting with version 2.3, all client-side storage (JavaScript-based cookies and LocalStorage) expire after 7 days!

Since web analytics and A/B testing software does not generally rely on third-party cookies, the first restriction mainly concerns advertising systems. We will thus focus on the second restriction in the rest of this article.

Consequences of client-side storages limitations​

Limiting JavaScript-based cookies to a 7 day expiry is very aggressive. Almost all web analytics platforms (including Google Analytics) are JavaScript or front-end based, and they all use a cookie to store the visitor's unique identifier. This identifier is randomly generated on the first pageview of the visitor's first visit to your website. On subsequent page views and visits, the identifier is reused from the cookie to identify the visitor. This allows analytics software to differentiate between a new visitor (a new cookie is generated) or a returning one (a previously set cookie was found). Since Safari reduces the lifetime of the cookie to 7 days, a visitor making a first visit on Monday, then returning on Tuesday of the following week is considered as a totally new visitor. In other words, the data from the new visit won't be linked to the previous visit. As a result, your new visitor metrics in the analytics software is no longer reliable for your Safari traffic. Many, many other metrics can be distorted as well (number of unique visitors, time to buy, and so on). It's difficult to trust any number produced by cookie-based analytics solutions anymore.

For desktop websites, this could be considered a minor nuisance, since Apple's Safari desktop market share is relatively low (between 5% and 10% generally). However, for mobile heavy websites, the market share of iOS devices is often closer to the 40%-50% range. This means almost half of your traffic can be affected!

The majority of testing and conversion optimization platforms bundle their web analytics capabilities. Of course, these suffer from the exact same issues we just described, which is problematic in itself. However for A/B experiments, an even more serious obstacle appears. Each time a visitor is bucketed into an experiment, the testing software selects a variation for the visitor. This variation must be remembered accurately, since if the visitor comes back, the visitor must see the same variation they saw previously. All front-end testing solutions store this information (association between experiment and variation) in a cookie. With ITP, a visitor that comes back more than 7 days after initially triggering an experiment runs the risk of seeing a different variation. Under these conditions, A/B testing does not produce reliable results.

For even more technical details, see this excellent blog post on ITP and its implications for Web Analytics. The article also provides a list of workarounds to the ITP challenge, which is what we'll cover in the next section.

Solutions for Kameleoon​

The first workaround that Kameleoon implemented was to save important information, such as variation allocations, in LocalStorage rather than in cookies. In fact, using LocalStorage instead of cookies in Kameleoon predates ITP, because LocalStorage has several advantages over cookies. One of which is that cookies set by JavaScript were not completely trustworthy even before ITP because users could manually wipe them out. Using LocalStorage instead worked initially, however the latest version of ITP treats LocalStorage like a cookie and entries expire after 7 days. As a result, this method no longer guarantees reliable A/B tests and personalizations on Safari.

Our current recommended solution is to set the kameleoonVisitorCode cookie, which contains the very important visitorCode identifier, on the server using an HTTP header instead of only on the browser with JavaScript. ITP does not impose restrictions on cookies set by servers, so this cookie can have a sufficiently long expiration date. Using this method, we synchronize this cookie between the front-end and back-end, and as a side-effect, the cookie lifespan is no longer limited by ITP.

On Safari, once Kameleoon obtains its visitorCode by reading the (server set) kameleoonVisitorCode cookie, it checks to see if its current LocalStorage is empty. If it empty, it probably means the visitor's last visit was more than 7 days ago, so Kameleoon performs a Server Synchronization Call (SSC) to fetch all the data that was present in the LocalStorage from our own backend servers. Once this call is complete, the data is restored to its previous state. Normal operations can then resume.

Although we can guarantee that our analytics core is unaffected by ITP, and that all our reported traffic data is reliable, we cannot guarantee the same for third-party web analytics platforms. Our integration bridges with partner tools continue to work in the same way. We recommend you discuss the situation with the vendor of your chosen analytics solution.

Conclusion​

Using the solution detailed in this article, youcontinue to run reliable AB experiments with the Safari user base. We provide a recommended workaround and encourage our customers to implement it rather than just excluding Safari from the test base (or worse, doing nothing and having incorrect data in your AB tests).

Of course, we expect further changes to ITP as Apple works to safeguard user privacy on the web. We will continue to monitor the evolution of Apple's ITP technology, as well as other initiatives from other browser vendors. For example, Firefox has a similar solution to ITP, but it is not yet as stringent. Any breaking changes will be swiftly analyzed and solutions will be communicated as soon as possible.