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
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.
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
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.comgets a cookie from
www.ad-system.comvia 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.comwon't get the original cookie data as Safari will not send it.
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
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
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.
The LocalStorage fetching mechanism via a Server Synchronization Call is only available if you are subscribed to the Personalization module. However, reliable AB experiments are still possible even if you do not have this module. On Kameleoon, the variation allocation is computed from the visitorCode. For a given experiment and traffic repartition, the same variation is always guaranteed for a single visitor code. This is usually enough for AB testing purposes. However, be aware that other data related to the previous visit (suchs as dates, number of pages, and custom data) won't be reliable.
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.
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.