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 😊
It is completely possible to perform experimentation with Optimizely while adhering to the law. With Optimizely you have a few options:
optimizelyOptOutis used to determine if it is allowed to set cookies. If it is set to
trueOptimizely will not track a site visitor. The code to set
optimizelyOptOutis shown below. In Optimziely Web you can add this snippet within the
TIP: You might be tempted to set the
optimizelyOptOut in a cookie directly, don't!
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.cookiewill 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.cookieAND are created by a tracking domain AND use link decoration will expire in 24 hours
local storagefor 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
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 (
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 🤘