This article provides technical options to help you understand and mitigate the impact of ITP. You should review these options with your privacy counsel to ensure that you are transparent with your visitors and are complying with requirements in the regions you operate. You should also ensure that your implementation does not circumvent your visitor’s privacy settings, such as cookie settings they may select through your cookie banner. Please refer to the article on how to Enable opt-in options for Optimizely Web Experimentation cookies and local storage for an explanation of how to manage Optimizely Web Experimentation cookies using our APIs.
Optimizely Web Experimentation 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 Prevention 2.1 as their default behavior, all client-side cookies—including those used by Optimizely Web Experimentation—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 Web Experimentation 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 Web Experimentation snippet works: Order of activation.
These visitors’ on-site actions will no longer be counted toward metrics based on the 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.3 - localStorage Expiration
With the release of ITP 2.3, Safari has begun applying the same expiration periods to localStorage as it does to cookies set client-side. Optimizely Web Experimentation depends on localStorage to persist event data for behavioral targeting, some visitor-level attributes, and to maintain visitor bucketing for experiments through mid-experiment traffic allocation changes. These functionalities will be constrained to Browsers' persistence capabilities.
Optimizely Web Experimentation and Optimizely Web Personalization mitigations
Re-bucketing instances are likely limited and will not necessarily result in bias or invalidation of experiment results. However, you can take steps within Optimizely Web Experimentation and your implementation to mitigate the impact of ITP on your visitor experience and experiment results.
Mitigations
The changes introduced as part of ITP 2.1 and 2.2 specifically affect cookies created client-side in JavaScript via document.cookie, which is currently the only means for Optimizely Web Experimentation 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 server-side at another point in your stack.
Option 1: Enable and use BYOID
This can be done by enabling Bring Your Own Visitor ID feature on Optimizely Web Experimentation. This feature allows you to define your own visitor ID, either as a cookie, local storage key, query parameter, or javascript variable. This has several advantages beyond ITP 2.x mitigation, including giving you control over your ID persistence strategy, allowing for a uniform visitor ID across multiple platforms, and reducing cookie bloat. Please see the documentation for further details.
Option 2: Set optimizelyEndUserId on CDN
This is not recommended because BYOID is a more complete approach, but another way is to configure cookie creation is through a CDN. This is an option for the UI-based and UI-managed implementation of server-side cookie creation in many cases. Optimizely Web Experimentation currently provides documentation for 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 Web Experimentation support.
If you are following this process, in addition to the above CDN settings changes, you should also disable the automatic lifetime extension of the visitor ID cookie by running this in the project JS.
window["optimizely"].push({
"type": "extendCookieLifetime",
"isEnabled": false
});
This strategy also has limited functionality when cross-domain tracking is enabled, especially when the different domains follow different strategies for visitor ID persistence.
Results based mitigation
Browser segmentation
Optimizely Web Experimentation 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.
Here is how:
-
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.
-
Click Apply.
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.
<%= heading %>