NAV
  • Intelligent Tracking Prevention

    • Intelligent Tracking Prevention

    Introduction

    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: in desktop computers (Macintosh) but more importantly, in all iOS devices (iPhone and iPad). ITP's current version, 2.3 (with March 2020 updates), brings some major restrictions to what operations JavaScript-based software can perform. While ITP originally targeted online advertising systems, latest versions are much more agressive and impacts standard Web Analytics software such as Google Analytics in a very serious way. A/B testing tools are also impacted, maybe even more than analytics systems, as we'll discuss in this article.

    At the time of writing this article (May 2020), Kameleoon can correctly handle Apple's ITP. However, this unfortunately can no longer be done only on our side, as it requires a small synchronization code to be inserted on the customer's back-end servers.

    This documentation article aims to raise awareness among web marketers on this important topic. We will focus on the following points:

    What Intelligent Tracking Prevention is and why it really matters for your website

    Client-side storage (Cookies, LocalStorage) and ITP Technical Restrictions

    Intelligent Tracking Prevention implements a lot of restrictions concerning the usage of cookies and other client-side storage such as Local Storage. It is thus important to evoke a few important characteristics of cookies here.

    Cookies are (very) small pieces of data that are stored in the 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 web server, automatically and transparently. This means cookies are constantly being added to most web requests, with two immediate consequences: the weight of web requests increases, slowing your browsing speed; and your browser can transfer 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 important. However, the second is much more far-reaching and this is what advocates of user privacy are trying to fight.

    This is of course a delicate topic, since cookies are being used for very different purposes on the web. Many of them, due to the stateless nature of the HTTP protocol, are needed for basic website operations - such as e-commerce transactions - the web would not work without. With ITP, Apple's developers are trying to separate the "useful" cookies (those mandatory for the normal operation of a given web site) from the "bad" ones (those associated with advertisement, tracking and unwanted privacy breaches).

    Cookies can be set via two different mechanisms: either when a call is made to a web server (the cookie is then set via the addition of an HTTP header in the HTTP reply), or via JavaScript code. The associated cookie domain depends on the method used: for server cookies, it is the domain where the server call was made. For JavaScript cookies, the domain is the one of the page where the JavaScript code is run (NOT the JS file host domain!). Third-party cookies refer to cookies sent to a domain different than the web page you're currently viewing. For instance, if you're browsing www.randomshop.com, but for whatever reason a call is made to tracking.ad-system.com, cookies associated with www.ad-system.com will 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.

    Finally, it's worth noting that when a cookie expires, it is removed from your browser / computer entirely. However, as the expiry date was normally chosen by the entity setting / controlling the cookie, it could be set very far in the future (10 years or more), ensuring that it would basically never get deleted. As we'll see, things are changing with ITP.

    The two main restrictions imposed by ITP 2.3 are the following:

    Since Web Analytics 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 this limitation for web-based analytics & testing platforms

    Capping JavaScript based cookies to a 7 day expiry is very agressive. Almost all Web Analytics platforms (including Google Analytics, the most popular solution) are now JavaScript / 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 first visit of this user to your website. Later, on all subsequent pageviews and visits, it is reused to identify this particular user. This allows for instance Google Analytics to know if a visitor is a new visitor (new identifier / cookie is generated) or a returning one (a previously set cookie was found). Since cookies now have a lifetime of 7 days in Safari (overriding, of course, the default expiry date normally set by GA, which is obviously much longer) a visitor making a first visit on Monday, then returning on Tuesday of the following week will be considered as a totally new visitor. His new visit won't be linked to the previous one. As a result, your new visitor metric, as reported by Google Analytics, is completely false for any Safari traffic. Many, many other metrics are completely distorted as well (number of unique visitors, time to buy, etc). It's actually hard 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 marketshare is relatively low (between 5% and 10% generally). We would still argue that it is a serious issue for accurate web analytics and data analysis. For mobile heavy websites, it is a totally different story: as the marketshare of iOS devices is closer to the 40%-50% range, almost half of your traffic can be affected!

    The majority of testing and conversion optimization platforms also bundle 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, a variation is selected for him. This variation must be remembered, since if the visitor comes back, he must see the same variation he saw previously. All front-end testing solutions store this information (association between experiment and variation) in a cookie. So, with ITP, a visitor coming back more than 7 days after initially triggering an experiment runs the risk of seeing a different variation. Under these conditions, A/B testing is useless and does not produce reliable results.

    For much more technical details, see this excellent (and very exhaustive) blog post on ITP and its implications for Web Analytics. This post also provides a list of solutions (or rather, workarounds) to the ITP challenge, which is what we'll also discuss in the next section.

    Suggested solution for Kameleoon

    Cookies set by JavaScript, which were not 100% trustworthy even before ITP because users could manually wipe them out (as with any cookies), basically became totally unreliable with ITP. The first workaround that we implemented was to save important information, such as variation allocations, in the LocalStorage rather than in cookies. In fact, using LocalStorage instead of cookies in Kameleoon even predates ITP, because the LocalStorage has several (unrelated) advantages over cookies. This worked graciously for about a year, however with the latest version of ITP, the LocalStorage is now treated like a cookie and expires after 7 days. As a result this method is no longer enough to guarantee reliable AB tests and personalizations on Safari.

    Our current recommended solution is thus to set the kameleoonVisitorCode cookie, which contains the very important visitorCode identifier, on the server via an HTTP header and not only on the browser via JavaScript. ITP does not impose any restrictions on server set cookies, so this cookie will have a sufficiently far expiration date. In essence, we are synchronizing this cookie between front-end and back-end, and as a side-effect the cookie lifespan is no longer restricted by ITP.

    On Safari, once Kameleoon obtains its visitorCode by reading the (server set, so reliable) kameleoonVisitorCode cookie, it will check if its current LocalStorage is empty. If it is the case, which probably means the visitor last visit was more than 7 days ago, Kameleoon will perform 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 over, data will be restored in the exact state it would have been if ITP did not wipe it out. Normal operations can then resume.

    Implementing cookie synchronization between front-end and back-end

    Implementing the kameleoonVisitorCode cookie synchronization on the backend can be done via different methods (adding a custom DNS entry, using one of our SDKs, adding a specific code snippet for the backend technology you use, or editing your web server configuration). For more details, see this specific section on our Back-end / Front-end Bridge article. Note that setting up a Back-end / Front-end Bridge has other advantages in addition to mitigating ITP, which the rest of the article explains.

    The list of synchronization methods is available here.

    Caveat

    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 as before. We recommend that customers discuss the situation with the vendors of their chosen solution.

    Conclusion

    Solutions exist to continue to run reliable AB experiments on the Safari user base. We provide a recommended workaround and really encourage our customers to implement it rather than just excluding Safari from the test base (or worse, doing nothing and having incorrect / false data on your AB tests).

    Of course, ITP 2.3 is not the last move Apple will make in its war 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 (Firefox has something similar to ITP, but not as extreme as of yet). Any breaking changes will be swiftly analyzed and solutions will be provided as soon as possible.