Cookies and tracking

The following explains the different options of our platform for opt-in and cookie handling. Before you read on, it is important to know that this page is not legal advice. Every use case is different. So, make sure to read the Data Processing Addendum and consult with your legal experts before taking action.

What is a cookie policy?

A cookie is a small piece of data stored by the web browser while browsing a website. It typically contains an identification number, used to relate a unique visitor to data that is collected across multiple page views. This is called “tracking”, and it can be very useful. If you wouldn’t be tracked, a website would think that you are a new visitor at every pageview, and forget all of your settings, preferences, or even if you are logged in or not.

This technique can be abused, so you need to be transparent about it. Therefore, you need a public cookie policy. A cookie policy should explain to your website visitors which cookies are active on the website, for what purpose, and how they relate to the data that is stored. Do not take this lightly: you are legally required by the European GDPR and the Californian CCPA to have one available to your users on your website.

In some cases, this policy should allow people to choose whether they are okay with this type of tracking or not. If they don’t choose at all, the default answer should be “no”. This is called “opt-in”. There are many tools available that can help you create this feature, but Unless has a built-in solution for it that is very subtle. Read on to find out if this applies to your use case.

Does Unless use a cookie?

Normally, we do. But it is a little bit more subtle than that.

To understand why, here is a quick recap of what we do. Unless adds an additional layer of functionality and content to your existing website. Using the service, your website can start showing specific experiences under pre-defined circumstances and to specific groups of visitors - called “audiences” - because they may have specific needs. To help you do this right, a control group mechanism is used to measure the performance of these new experiences with respect to your website goals.

We need to set a cookie to cater for two situations:

• Long audience membership duration. If an audience membership is valid for longer than just one pageview, the consequence is that we will need to recognize a visitor across pageviews. For example, if you define a group of “returning visitors”, you need to set a cookie to determine that they have been on your website before.
• Goal tracking and performance measurements. To measure the success of your experiences with respect to your website goals, we will put certain visitors in a control group. These visitors do not see any variations, so we can measure the difference with the people who do. Because website goals (like a purchase) may be achieved at any time, control group memberships last for a prolonged experiment time and across pageviews as well.

That is why - in our normal operation - we set a cookie called “unless_id”, so we can remember that you are the same person as the visitor of the previous pageview. It does not mean that we know who the visitor is. It’s just a number.

But... sometimes, we don't use the cookie.

Intermezzo: cookieless experiences without tracking

But hypothetically, we don’t always need to set a cookie. A certain kind of experience simply extends the website with functionality without setting a cookie or storing any data.

To be more precise: if experiences are shown to visitors based on the circumstances of a single pageview, we don’t need to remember this visitor across pageviews. For example, if you want to show a specific message to people from Amsterdam, we can do so without tracking at all. Or maybe you want to offer a very successful experience for everyone, which also does not require tracking. The only disadvantage is that you can’t measure the effect of these experiences without a control group, for which we would need to set a cookie.

So, assuming that you wouldn’t want to know how well these experiences perform, these examples could be “cookieless experiences”. Our system is smart enough to figure out which experiences are potentially “cookieless”. We use this in our opt-in procedure, which is explained a few paragraphs down. Let’s first investigate if you need opt-in at all.

Do I need my visitor’s consent for the Unless cookie?

Maybe. It depends on what you want to do with it. Typically, cookies can be divided into three categories.

1. Functional cookies, meant to power website features like language switching and logging in - typically, this kind of tracking is non-privacy intrusive, so consent (opt-in) is probably not required.
2. Performance cookies, meant to analyse the website’s performance and improve it - explicit visitor consent is most likely required.
3. Marketing cookies, tracking online activity to help advertisers deliver more relevant advertising, as well as any other cross-domain tracking cookies. Consent is definitely required.

So, depending on your objective, you may need to ask for consent.

You may not need to ask for permission if...

If the experiences that you will create are meant to support the user experience with useful features and relevant content, you may not need to ask for consent. Our cookie will be considered a “functional cookie”. You can probably still use control group checks, just to be sure - or you can just disable those entirely. Take note: you will need to verify this with your legal experts, because opinions tend to vary per industry.

You definitely need to ask for permission if...

However, if your primary objective is to run experiments and test different configurations of your website and content across funnels, you will need to ask your visitors for permission first. Our cookie will be considered a “performance cookie”.

Sometimes, the Unless cookie even counts as a “marketing cookie”. It is an edge case example, but if you connect Unless to a third party system that subsequently starts firing more relevant ads on other websites, you will have to ask for permission as well.

The built-in consent procedure at Unless

As mentioned, there are many services to set up a cookie consent procedure. They typically work by disabling the script snippet that sets the cookie. This has a big disadvantage: it disables everything, so you couldn’t even show experiences that simply extend the website with functionality without setting a cookie or storing any data. And for many of our customers, these make up for the bulk of what Unless does for them. So, we thought of something better.

In your dashboard, you can choose to enable or disable the cookie consent procedure.

• By default it is disabled. We assume that you will use Unless with a “functional cookie”. This means that Unless will operate normally, right from the beginning of any visitor session. You can show specific experiences to visitors, and you will be able to see insights in your dashboard about their performance, based on control groups and A/B tests.
• If you enable the cookie consent procedure, Unless will start to operate normally only after consent.

But what happens before consent? If you decide to enable cookie consent, you can choose between two options for the system’s behavior prior to consent:

• Cookieless experiences. Our system will automatically figure out which experiences we can still show without setting any cookies and without tracking. These experiences will still show, even before cookie consent. Take note: as a result, visitors who did not explicitly consent yet will not show up in your insights dashboard and A/B tests will not be applied.
• No experiences at all. This eliminates the entire Unless functionality before consent.

If you need to implement consent, we strongly recommend using the cookieless experiences! It will allow you to gracefully stick to the rules, while still leveraging most of the features on Unless prior to consent.