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 applies to 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 most recent 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’s 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 belongs to a domain (such as www.example.com) and has an expiry date. Any time your browser makes a server call to a domain linked to one or more cookies stored on your computer, it sends the data in those cookies to that domain’s web server in an automatic and transparent way. Consequently, most web requests constantly carry cookies, 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 others to identify and track you.

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 websites use cookies for many different purposes on the web. Many of them, due to the stateless nature of the HTTP protocol, are necessary 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 reaches 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’s the domain that received the server call. For client-side JavaScript cookies, the domain is one of the pages from which the JavaScript code runs (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 viewing. For example, if you’re browsing www.randomshop.com, but that website makes a call to tracking.ad-system.com, the browser can send cookies associated with www.ad-system.com along with the HTTP query. The browser treats them as 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 have an expiry date far in the future (for example, 10 years or more). This duration ensures that it lives far beyond what’s 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. Safari blocks third-party cookies 24 hours after the browser sets them. Technically, they’re 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 doesn’t 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 doesn’t 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 frontend 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 software reuses the identifier from the cookie to identify the visitor. Reusing the identifier allows analytics software to differentiate between a new visitor (the software generates a new cookie) or a returning one (the software finds a previously set cookie). Since Safari reduces the lifetime of the cookie to 7 days, the analytics software treats a visitor who makes a first visit on Monday and returns on Tuesday of the following week as a totally new visitor. In other words, the data from the new visit won’t connect to the previous visit. As a result, your new visitor metrics in the analytics software is no longer reliable for your Safari traffic. The restriction also distorts many other metrics (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, the restriction is likely 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 ITP can affect almost half of your traffic. 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 the testing software buckets a visitor into an experiment, it selects a variation for the visitor. The software must remember that variation accurately, since if the visitor comes back, the visitor must see the same variation they saw previously. All frontend 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 doesn’t 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 the next section covers.

​

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 weren’t completely trustworthy even before ITP because users could manually wipe them out. Using LocalStorage instead worked initially. However, the most recent version of ITP treats LocalStorage like a cookie, and entries expire after 7 days. As a result, this method no longer ensures 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 doesn’t 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’s 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 completes, Kameleoon restores the data to its previous state. Normal operations can then resume. Although ITP doesn’t affect the analytics core and reported traffic data is reliable, Kameleoon can’t ensure 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. Apple will likely make further changes to ITP as it 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 isn’t yet as stringent. Kameleoon will analyze any breaking changes and communicate solutions.