Intelligent Tracking Prevention
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 exactly are the technical limitations imposed by ITP 2.3;
- its consequences on the operation of Web Analytics and Conversion Optimization software;
- the details of Kameleoon's recommended solution to avoid being affected by ITP.
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).
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
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:
- In all ITP versions, third-party cookies suffer from a variety of restrictions. 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 have been set. They are not technically deleted, but are no longer being sent to the third party server via HTTP requests. In our previous example, a visitor coming to
www.randomshop.comgets a cookie from
www.ad-system.comvia an HTTP call to that server during their first visit. If he comes back more than 1 day later, his next HTTP request to
www.ad-system.comwon't get the original cookie data as it will be blocked.
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
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
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.
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.
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.