Cookies and localStorage in snippets

You can uniquely identify visitors, track their actions, and deliver consistent experiences across page loads with persistent visitor-level cookies and localStorage. Each cookie Optimizely Experimentation sets stores a different set of data. See Intelligent Tracking Prevention and Optimizely Web Experimentation for information.

Do not directly reference the cookies and localStorage keys in code, as the specific data format and the cookies may change over time and break your experiences. Instead, use the JavaScript API for Optimizely Web Experimentation.

If your Optimizely Experimentation account uses custom snippets, you might see multiple snippets listed for your projects. See Custom snippets in Optimizely Web Experimentation for information. 

Cookies

The Optimizely Web Experimentation's JavaScript snippet uses cookies to store some data in visitors' browsers. These are first-party cookies.

Do not reference the cookies and localStorage keys directly, as they may change anytime.

The following are descriptions of the cookies that Optimizely Experimentation sets:

optimizelyEndUserId

• What – Stores a visitor's unique Optimizely Experimentation identifier. It is a combination of a timestamp and a random number. No other information about you or your visitors is stored inside.

• Example value – "oeu1383080393924r0.5047421827912331".

• Expiration – Six months from the last page visit or a period of your choice (using the setCookieExpiration and extendCookieLifetime APIs).

optimizelyRedirectData

• What –After Optimizely Experimentation has executed a redirect experiment, it stores various data from the original page so that Optimizely Experimentation still has access to it on the new page.
• Expiration – Five seconds.

optimizelyDomainTestCookie

• What – When Optimizely Experimentation loads a URL, the snippet places the cookie to get the current domain for determining whether cross-domain syncing is possible. If successful, the cookie is immediately removed. 
• Expiration – Six months, but the cookie is removed by Optimizely Experimentation immediately after the set action is successful.

optimizelyOptOut

• What – Stores a boolean indicating whether the visitor has opted out of participating in Optimizely Experimentation powered experimentation. A visitor can opt-out by using the opt-out tool. See Data Subject Rights – Third Party End Users for information. An Optimizely Experimentation customer can set this cookie's value through the snippet's optOut API call.
• Example values – "true", "false".
• Expiration – Ten years from using the opt-out tool or snippet's optOut API.

In Optimizely Experimentation, you can use the JavaScript API to set the cookie domain. You can also use the API to set the cookie expiration and enable or disable the extend cookie lifetime function.

Consent

Optimizely does not hold a specific stance on classifying the set cookies. These classifications are used by laws and regulations like GDPR, and there are multiple interpretations that have not been fully tested in court yet. Optimizely's goals are to provide flexibility and let you decide how to use the cookies.

There are three basic interpretations:

1. The cookies are entirely unnecessary – Optimizely is not part of your ecosystem and does not restrict any core functionality. The user must consent to Optimizely cookies. This method often guarantees flickering.
2. The cookies are unnecessary, but Optimizely can set cookies as long as no analytics are being recorded on the server yet – This is usually the compromise between following regulations enough and not guaranteeing flickering. This requires you to use some JavaScript APIs in the snippet to ensure Optimizely does not activate events but caches them locally until the block is removed.
3. The cookies are necessary – Because Optimizely helps deliver user experiences, it can run without consent.

RUM cookies

For a small percentage of your visitors (less than ten percent), Optimizely Experimentation tries to collect performance and product usage telemetry. Optimizely collects no personal data.

This process is called Real User Monitoring or RUM. Visitors who are sampled for this telemetry data have two cookies on the domain rum.optimizely.com. These are session cookies and do not persist on the visitor's device. The domain attribute of these cookies is rum.optimizely.com.  The aforementioned set cookie domain API has no effect on these. See Cookie domain for information. 

AWSELB/AWSELBCORS

• What – Enables sticky sessions. RUM requires sticky sessions. Its value is random data. With CORS (cross-origin resource sharing) requests, some browsers require SameSite=None; Secure to enable stickiness. In this case, Elastic Load Balancing creates a second stickiness cookie, AWSELBCORS, which includes the same information as the original stickiness cookie plus this SameSite attribute. Clients receive both cookies. See AWS load balancer documentation for information.
• Example value – 

  "799B7FFB1A5DA8D5E09A5D5213B368BD54D987883D4B3B3193567422FA84E59605DE048B6A4B6B488C4DAEFC462F7170F3506CF8FB2F0CBDAA360D722F3F52CFE3A55DF331A5DE690D18747252F1146EF3D3629B00"

• Expiration – N/A; it is a session cookie.

optimizelyRumLB

• What – Controls the AWSELB cookie's attributes (SameSite and Secure). For information, see the AWS documentation on application-controlled session stickiness. See Configure sticky sessions for your Classic Load Balancer in the AWS documentation.
• Example value – "1".
• Expiration – N/A; it is a session cookie.

localStorage

Optimizely Web Experimentation and Optimizely Performance Edge store data under the following keys in localStorage.

Keys set by Optimizely Experimentation

The following are keys set by Optimizely Experimentation. {visitorId} is dependent on the visitor ID and stored in the optimizelyEndUserId cookie, and {projectNamespace} can be a project ID or its account ID depending on whether the project is linked. See Custom snippets in Optimizely Web Experimentation for information. 

Do not reference the cookies and localStorage keys directly, as they may change anytime.

visitorId is a combination of a timestamp and a random number. No other information about you or your visitors is stored inside.

• optimizely_data$${visitorId}$${projectNamespace}$$event_queue – Stores event instances that are waiting to be added to the previous ...$$events key.
• optimizely_data$${visitorId}$${projectNamespace}$$events – Stores event instances that describe the visitor's actions on your website.
• optimizely_data$${visitorId}$${projectNamespace}$$layer_states – Stores bucketing decision (variation and holdback assignment) for each layer in Optimizely Web Experimentation and Optimizely Personalization.
• optimizely_data$${visitorId}$${projectNamespace}$$session_state – Tracks the session identifier and timestamp, which helps Optimizely Experimentation identify sessions for analytics purposes.
• optimizely_data$${visitorId}$${projectNamespace}$$variation_map – Records the variation that the visitor sees for each experiment. This lets Optimizely deliver a consistent experience on successive page loads.
• optimizely_data$${visitorId}$${projectNamespace}$$visitor_profile – Stores the visitor's values for various audience conditions. This is important for sticky conditions like Ad Campaign, Source Type, and Referrer, for which the first observed value is important.
• optimizely_data$${visitorId}$${projectNamespace}$$layer_map – Stores bucketing information within mutual exclusion groups.
• optimizely_data$${visitorId}$${projectNamespace}$$tracker_optimizely – Temporarily stores the events that are sent in batches to the Optimizely Experimentation Event API.
• optimizely_data$${visitorId}$${projectNamespace}$$pending_events – Temporarily stores XMLHttpRequest information, enabling the snippet to reliably send requests (for instance, to the Event API) even if the visitor navigates to a new page while a request is in progress.
• optimizely_data$${visitorId}
• optimizely_data$${visitorId}$$events
• optimizely_data$${visitorId}$$event_queue
• optimizely_data$${visitorId}$$layer_states
• optimizely_data$${visitorId}$$session_state
• optimizely_data$${visitorId}$$visitor_profile
• optimizely_data$${visitorId}$$variation_map

Origins

Unlike cookie data, localStorage is scoped to a single origin. An origin is a combination of a specific hostname, protocol, and port on your site. Two pages have the same origin if the protocol, port (if one is specified), and host are the same for both pages. See the Same-origin policy in Mozilla documentation. 

This is an example of pages that do not have the same or different origins as https://shop.example.com:

• http://shop.example.com – Different security protocol.
• https://example.com  – Different subdomains.

The documented localStorage keys are set on every domain that uses Optimizely Experimentation.

For Optimizely Web Experimentation or Optimizely Performance Edge to recognize visitors across your pages and deliver consistent experiences, each visitor's data replicates on all of your subdomains by routing it through another origin: https://{yourAccountId}.cdn.optimizely.com/. Your visitors' data is set on that origin as well, and on every page load with an Optimizely Experimentation snippet on it, Optimizely Experimentation makes an async call to this origin to sync this data. This syncs information across origin and across subdomains. See Cross-origin tracking for information. 

Optimizely Web Experimentation and Optimizely Performance Edge do not combine visitor data from multiple accounts.