If you are thinking of introducing a new SaaS tool into your tech stack, like Optimizely Web, you need to know it complies with all the latest cookie laws and regulations. It is understandable and natural why a lot of companies who are thinking about new to web experimentation tend to have concerns about cookies. This guide has been written as a one-stop-shop to answer all Optimizely Web cookie-related questions, hopefully, written in a way that technical and non-technical people can understand it:

  • Can Optimizely Web comply with the next new browser update, e.g. First-party Vs Third-party Cookies

  • Can Optimizely Web comply with the latest Cookie law, e.g. Opt-In

  • Can Optimizely Web comply with the next security patch, e.g. Intelligent Tracking Prevention (ITP)

In this guide, I will provide you with a deeper dive into each of these topics, so if you want to become a cookie ninja or have an Optimizelty Web related cookie query, read on 🐱‍👤

First-party Vs Third-party Cookies

First, let us start with the easiest question. There is a lot of noise around the Cookie armageddon. Third-party cookies will become a thing of the past soon. As an Optimizely web customer, you do not need to worry about these changes. Optimizely web uses a combination of first-party cookies and local storage to manage the experiments. Simples 😊

Cookie Management

The European ePrivacy Regulation combined with the national laws of many European countries dictates that if your website uses cookies you need needs to provide a cookie opt-in feature. A site visitor must opt-in before you can create a cookie within their browser. To adhere to these laws, you might want to restrict Optimizely web from setting a cookie until a user has consented. No problem!

It is completely possible to perform experimentation with Optimizely while adhering to the law. With Optimizely you have a few options:

  • Javascript: You can prevent Optimizely from setting cookies by adding a little snippet of code onto your page. You can add this snippet of Javascript via the Optimizely Web interface. Behind the scenes, Optimizely uses a setting called optimizelyOptOut is used to determine if it is allowed to set cookies. If it is set to true Optimizely will not track a site visitor. The code to set optimizelyOptOut is shown below. In Optimziely Web you can add this snippet within the Settings ➡ Javascript page:

TIP: You might be tempted to set the optimizelyOptOut in a cookie directly, don't!

  • Tag Manager/Cookie Loader: If you use Tag Manager, or, a cookie managing tool to manage your third-party Javascript libraries, a developer can add some simple conditional logic within Tag Manager to only load the Optimizely JavaScript snippet if a visitor has provided consent. The issue with this approach is that you need to consider the flicker effect. The flicker effect occurs when an experiment takes too long to run and the user sees a noticeable shift in page payout. Only loading the snippet after a page has loaded may cause a flicker.

  • Optimizely Fullstack: All browser-based experimentation will always need to use some form of cookies. If you want to run experiments without cookies you can alternatively use server-side experimentation. If you want to learn more about this option, research Optimizely FullStack

Intelligent Tracking Prevention

Intelligent Tracking Prevention (ITR) has been around since 2017. ITP is a privacy feature developed by WebKit and is shipped as a feature within Safari browsers. Since its first launch, other browsers like Firefox do the same thing. The issue with ITP and web experimentation is user bucketing. ITP will automatically clear a users cookies and local data if that user hasn't interacted with your website within a week. ITR 2.3 a browser follow these rules:

  • Third-party cookies are blocked by default

  • First-party cookies created with document.cookie will expire after a week. If the user visits your site within 7 days, the expiration date will be extended another week

  • First-party cookies created with document.cookie AND are created by a tracking domain AND use link decoration will expire in 24 hours

  • The users local storage for your site will be wiped after a week. If the user visits your site within those 7 days, the expiration date will be extended a week

document.cookie is the only way most applications can write cookies. This means the results of every A/B testing tool that uses cookies or local storage could be impacted by ITR. This new policy is great for privacy, however, it causes headaches for web experimentation. Most experiments that you run will be left running for months not days. If a user only interacts with your website infrequently, this could impact the validity of your experiment data 😔

Let us walk through how your experiments data could be impacted. Assuming a site visitor has visited your homepage, taken part in an experiment and then not visited your site again for 10 days. Their cookie will have been wiped automatically. When they visit the homepage again with the same experiment running, they will be re-bucketed. Any events and actions they trigger within the experiment will be associated with their new bucket rather than the old one. The effects of this will likely be marginal, however, it could potentially skew results. The same person might be counted several times within the same experiment. The data scientists of this world will want their experiment data to be more accurate, so what can you do?

Fear not, things are not all doom and gloom. As you probably guessed there are tips and tricks that can help mitigate this problem. First, if you have your own way to persistently identify users use that rather than relying on Optimiezly to bucket a user for you.

Don't think you have a way to globally identify users already? Do you use Google Analytics or a CDP like a Segment? The chance of a cookie, like Google Analytics, expiring is a lot lower. Using a more global identifier will minimise the chance of a user not being correctly identified and bucketed into a new experiment. This is possible using Optimizely Webs Bring Your Own ID feature. Instead, of using the Optimizely unique ID (optimizelyEndUserId) you can use your own. If you can access another ID either via a first-party cookie, a Javascript variable, local storage and query string, you can use that instead very easily 😊. Bring Your Own ID (BYOI) is not just useful for dealing with ITR, it has other benefits. These are:

  • Performance... fewer cookies,/better performance

  • Easier report generation. Instead of writing joins within downstream reporting tools to map the Optimizely ID and your analytics ID, using the same ID makes report creation easier

  • Consistent bucketing between different applications, including Web and Fullstack

If you use BYOI, there are some considerations. If Optimizely cannot locate a BYOI, the Optimizely snippet stops executing and that user will not be added to any of your experiments. Making sure the ID is set correctly is vital ✔️. The important thing is that the ID is set before the page loads.

There are three ways to mitigate this issue. Two approaches will require some technical knowledge. You could set the third-party ID at the CDN level using an edge-side function, or you still use the optimizelyEndUserId and set that on the CDN. BYOI is a better practice though!

A more manual way to test if IFT is not impacting you is to simply filter out Safari results in the Stats Engine report. You can then compare the results against the people who used Safari, comparing the data sets. If they are the same or similar, you have a good steer that there are no false/positives within your data👊

You are now a Jedi master with all things Optimizely and cookies. As you can see Optimizely Web is very flexible and can be tailored to fit your needs. Happy Coding 🤘