Skip to main content
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 used in all Safari browsers, including desktop computers (Macintosh) and all iOS devices (iPhone and iPad). ITP brings 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. 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 article explains the technical limitations and consequences of ITP for experimentation and analytics.
  • Technical limitations imposed by ITP.
  • Consequences for Web Analytics and Conversion Optimization operations.
  • Kameleoon’s recommended solution to avoid ITP issues.

​
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. Consequently, 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. Cookie usage is a complex 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, the browser deletes it completely. However, as the entity that creates the cookie chooses the expiry date, it can be set far in the future (for example, 10 years or more). This duration ensures that it lives far beyond what is necessary for normal operation of the original website. This practice 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. 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 the 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 does not receive the original cookie data.
  • 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. The rest of this article focuses on the second restriction.

​
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 market share means almost half of your traffic can be affected! The majority of testing and conversion optimization platforms bundle their web analytics capabilities. These suffer from identical issues, 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 returns 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 more technical details, see this blog post on ITP and its implications for Web Analytics. The article also provides a list of workarounds to the ITP challenge, which is covered 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 advantage 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. Kameleoon’s recommended solution is to set the kameleoonVisitorCode cookie, which contains the 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, the system synchronizes this cookie between the front-end and back-end, and the cookie lifespan is no longer limited by ITP. On Safari, once Kameleoon obtains the visitorCode by reading the server-set kameleoonVisitorCode cookie, it checks to see if the current LocalStorage is empty. If it is empty, the visitor’s last visit was likely more than 7 days ago. Kameleoon performs a Server Synchronization Call (SSC) to fetch all the data that was present in the LocalStorage from backend servers. Once this call is complete, the data is restored to its previous state. Normal operations can then resume. Although the analytics core is unaffected by ITP and reported traffic data is reliable, Kameleoon cannot guarantee the same for third-party web analytics platforms. Integration bridges with partner tools continue to work in the same way. Discuss the situation with the vendor of the chosen analytics solution.

​
Conclusion​

Using the solution detailed in this article, you can continue to run reliable AB experiments with the Safari user base. Kameleoon provides a recommended workaround and encourages implementation rather than excluding Safari from the test base. Further changes to ITP are expected as Apple works to safeguard user privacy. Kameleoon continues to monitor the evolution of Apple’s ITP technology and similar 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 analyzed and solutions will be communicated.