Intelligent Tracking Prevention

  • Updated
  • Optimizely Web Experimentation
  • Optimizely Personalization

This article provides technical options to help you understand and mitigate the impact of Intelligent Tracking Prevention (ITP). You should review these options with your privacy counsel to ensure that you are transparent with your visitors and comply with requirements in the regions you operate. Your implementation should not circumvent your visitor’s privacy settings, such as cookie settings they may select through your cookie banner. See Enable opt-in options for Optimizely Web Experimentation cookies and local storage for how to manage Optimizely Web Experimentation cookies using 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 ITP 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. 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 are subject to a new random variation allocation in any experiment or personalization experience for which they meet URL and audience targeting conditions. See How the Optimizely Web Experimentation snippet works: Order of activation for more information.

These visitors’ on-site actions are no longer counted toward metrics based on the initial variation assignment. Instead, their actions are 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 applies 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 are constrained to browsers' persistence capabilities. 

ITP 2.3 is currently the default behavior for iOS 13.1 and Safari 13.1 on macOS High Sierra and Mojave, and other browsers are expected to adopt it in the future. 

Optimizely Web Experimentation and Optimizely Personalization mitigations

Re-bucketing instances are likely limited and do 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 how Optimizely Web Experimentation manages cookie-setting.

You can ensure the persistence of your cookies, including the optimizelyEndUserId cookie, by managing the cookie creation process server-side at another point in your stack.

Option 1: Enable and use BYOID

You can enable the 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. Besides ITP 2.x mitigation, benefits also include control over your ID persistence strategy, allowing for a uniform visitor ID across multiple platforms, and less cookie bloat.

Option 2: Set optimizelyEndUserId on CDN

This is not recommended because BYOID is a more complete approach.

Another way is to configure cookie creation 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 use another CDN or need help implementing this process in your own stack, contact Optimizely Web Experimentation support.

If you are following this process, along with the above CDN settings changes, you should 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 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 to view results that both include and exclude Safari.

  1. Go to Results > Segment.

  2. Select the Match Any Value toggle. This allows an aggregate view of multiple values for a given segment.

  3. Select all of the browsers listed in the menu, excluding Safari.

  4. Click Apply.

You can 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.