Optimizely uses persistent visitor-level cookies and localStorage to uniquely identify visitors, track and attribute their actions to experiments and personalization campaigns, and deliver consistent experiences across page loads and visitor sessions. However, in browsers that use Intelligent Tracking Protection 2.1 as their default behavior, all client-side cookies—including those used by Optimizely—have a maximum expiration period of seven days.
This means that for visitors who have a gap of seven days or more between site visits, their previous
optimizelyEndUserId cookie will not be present when they return, and their existing user identity and state will no longer be available.
If a visitor’s Optimizely cookie is deleted during the course of an experiment or campaign, they will be subject to a new random variation allocation in any experiment or personalization experience for which they meet URL and audience targeting conditions, as shown in the image below and explained in How the Optimizely X snippet works: Order of activation.
These visitors’ on-site actions will no longer be counted toward metrics based on initial variation assignment. Instead, their actions will be counted as part of their variation assignment as a net-new visitor or not captured if they do not meet targeting conditions.
ITP 2.1 is currently the default behavior for iOS 12.2 and Safari 12.1 on macOS High Sierra and Mojave, and other browsers are expected to adopt it in the near future as well.
Optimizely X Web Experimentation and Personalization mitigations
Re-bucketing instances are likely to be limited and will not necessarily result in bias or invalidation of experiment results. However, you can take steps within Optimizely and your implementation to mitigate the impact of ITP 2.1 on your visitor experience and experiment results.
In-product mitigations (partial)
There are two browser-based options for mitigating the impact of ITP 2.1: using Optimizely's built-in browser segmentation capabilities, or using localStorage to persist user IDs.
Optimizely X Web provides out-of-the-box support for filtering your experiment and campaign results by a default set of user segments, including Browser. To validate cross-browser consistency of the results for an experiment, use the Browser segment option to view results that both include and exclude Safari.
At the top of the Results page, click the Segment menu.
Select the Match Any Value toggle. This allows an aggregate view of multiple values for a given segment.
Select all of the browsers listed in the menu, excluding Safari.
This allows you to view results with all typical reporting figures and statistical significance calculations, with and without the population of visitors who may be affected by ITP 2.1.
localStorage ID persistence
Browser limitations on the lifetime of client-side cookies currently work by overriding the expiration date property of cookies within the browser. localStorage is another way to store information, including Optimizely data, on the client side that is not subject to the current ITP 2.1 expiry limitation. Customers can take advantage of this browser feature to persist client-side cookies and other data in accordance with their general cookie and data policies.
External Mitigations (full)
document.cookie, which is currently the only means for Optimizely X Web to manage the cookie-setting process.
One way to ensure the persistence of your cookies, including the
optimizelyEndUserId cookie, is to manage the cookie creation process at another point in your stack.
Another is to configure cookie creation through a CDN. This is an option for UI-based and -managed implementation of server-side cookie creation in many cases. Optimizely currently supports server-side cookie creation through Akamai's configuration; if you are using another CDN or need guidance on implementing this process in your own stack, contact Optimizely support.