Implementation of a cookie management system
If you want to respect the law and if your site is using cookies, you'll have to inform your users of it and allow them to block them if they want. In this article, we'll see together what are the steps you'll need to follow to implement it.
If you want to correctly understand what we'll talk about, it's highly recommended to get a good knowledge of Google Tag Manager. If it's not the case, you can discover this tool thanks to this article that I've already written.
#What does the law says ?
Here we'll talk mainly about the French law (but we can imagine that the main principles can be applied to more countries). You can find all the related information on this page of the website of "la CNIL". Here are the main information to remember of:
- you have to inform your users of what the cookies you'll create will be used for
- you have to get their consent (they have to explicitly say that they accept it and not the opposite)
- they have to get a way to refuse them
- their consent has a validity of 13 months
- some cookies can be used without getting any consent (eg: cart cookie, authentication cookie, etc.). A more complete list can be found on the website of "la CNIL".
- if your user continues to navigate on your website (by going on another page), we can consider that they gave their consent. Otherwise, the banner informing them of the usage of cookies have to remain visible.
- your users should get a way to change their choice at anytime
Regarding GDPR, as long as you don't collect any personal data thanks to those cookies, there is nothing to worry about. Beginning of 2020, "la CNIL" has published some recommendations to the developers to be GDPR compliant. You'll find in it some information about cookies usage when you want to measure performances on your website.
#What is a cookie ?
Before going any further, it could be good to define exactly what is a cookie and why the law demands us to control them. A cookie is a small file that is stored on your computer which allows a website to save some information in it. Thanks to it, when a user is going on a website that has created a cookie, the website can access it and read the information inside to use them.
Nowadays, a big number of those cookies are storing information about your interests which will result in, for example, showing you some targeted adverts. This intrusion in private life can be disturbing and this is why "la CNIL" and the european community have decided to start to put some constraints on the creation and usage of the cookies. The main idea is to allow the users to know what the cookies are used for and to be able to refuse them if they want.
Concretely, a cookie is a key/value couple on which we can add some specific attributes. The key is the identifiant of the cookie, its name. The value is... its value :). The possible attributes are :
- Expires: this is the maximum lifetime of the cookies. During its creation you can precise when the cookie will expire via a precise date or by setting it a lifetime Max-Age (which is a number of seconds). If no value is set, the cookie is considered as a session cookie and it'll expire when the user's session will be terminated. If we set a negative Max-Age, the cookie will expire immediately.
- Domain: indicates on which domain the cookie will be sent. This can be a precise domain (eg: www.code-trotter.com) or domain and all its subdomains (eg: code-trotter.com which will include www.code-trotter.com and also all its subdomains like app.code-trotter.com).
- Path: the url(s) the cookie will be sent on
- Secure: if the cookie is set as Secure, it'll be sent only on the urls that use
https:. That said, it doesn't mean that the cookie is more secure.
- SameSite: indicates how the cookie will be sent depending on the domain you are on. There are 3 possible values:
Nonemeans that the cookie will always be sent even if you're on another domain (eg: widget of your site, affiliate program, etc. - this cookie should have been set as Secure). If you choose
Strict, the cookie will be sent for each request done from your website.
Laxvalue is like
Strictexcept that the cookie will be sent also on the initial request to your website when you come from an external website. You can find some further explanations on this attribute here.
#Different types of cookies
The domain name associated to First party cookies is the domain name of your website. There are usually created by your own code (front or back) or by some external code (scripts or iframes). They can be read only by your domain.
Third party cookies are the cookies created by some external code (most of time by some scripts or iframes) that you've added on your website. They can be read by all the websites that also include this external code. It's mainly because of those cookies that you'll get targeted adverts on the internet.
#Different categories of cookies
If you want to better control your cookies, it's generally a good idea to categorise them. Thanks to that, your users will be able to accept or refuse each category. The law is not really precise about categorisation which means that you can do whatever you want. That said, there is a categorisation that is generally used which helps you to easily categorise every cookie without creating a too complex technical implementation of the cookies management:
- Required cookies: this is the only category mentioned by the law. For those cookies, your users don't have to give their consent because if they don't have them, your website won't be able to be used correctly. Some examples: cart cookie, authentication cookies, load balancing cookies, etc.
- Performance cookies: those cookies are used to measure the traffic on your website which will help you to improve its performances. Eg: Google Analytics, Amplitude, Hotjar, etc.
- Functional cookies: they improve the functionalities and the personalisation of your website. Without them, some functionalities may not work correctly. Eg: A/B testing cookies, live chat cookies, etc.
- Targeting cookies: those cookies may build a profile of your interests and show you relevant adverts on other sites. Eg: Facebook, Twitter, etc.
Based on what we've just seen and in order to be compliant with the law, we can list 3 steps to follow to implement our cookies management system:
- list / identify all the cookies present on our website to categorise them
- get the users' consent
- block or not the cookies based on users' choices
#List all the cookies and categorise them
For each cookie that you'll find, you'll need to know if this cookie is a session cookie (cookie that ends up when the user's session terminates) or a permanent cookie. For permanent cookies, you'll also need to know for how long it's created (its lifetime). And finally, as required by the law and the RGPD you'll have to provide a short description about what is doing each cookie. As much as possible, this list has been updated regularly.
For the cookies created by your own code, you should be able to find them quite easily. Some of them are created directly by you / your team but some others can also be created by your framework for example.
For the cookies created by external dependencies, it's a bit more complicated... Because usually, you don't really control their creation. Moreover, if some of your scripts are only present on a few pages, you'll have to navigate on all the pages of your website to be able to find all the cookies. And regarding their description, it's really not easy to provide one. And let's imagine that one of those scripts is creating a new cookie, how will you be aware of it (except by checking all the pages again)?
Based on all this, it could be good to find a tool to help us identify the cookies and to automate the search. We'll now go through some of those possible tools.
This list is not exhaustive but you'll find the most efficient solutions available online. A lot of free tools only scan 4 or 5 pages of your website so the results are clearly not accurate enough.
You can use this tool for free for 14 days. Since rencently they even have a new interface (not really more UX friendly according to me). You can scan your entire domain name as well as all its subdomains without any page limitation. It's also possible to go through an authentication form to allow you to scan the connected part of your website. The scan is working pretty well even if I faced some cache issues.
For categorisation, OneTrust comes by default with the 4 main categories and allows you to automatically assign your cookies on them, based on their database Cookiepedia. It's really useful and saves you a lot of time ! And of course, you can modify those categories and their content; you can even add new ones.
The scan can then be automated and warns you when it detects new cookies.
Today, according to me it's the most complete solution available online. But after using it for a professional project, I faced a lot of blocking issues that have been fixed by contacting their support team.
Can be tested here: https://www.onetrust.com/free-trial/
For a tool with a no time limit free version, I think this is the best you'll find. I hate the UI / UX but it does the job ;). You can register a domain and run a scan. That said it's not possible to go through an authentication form... But it's possible to manually add some cookies if you know exactly which ones (mainly first party) are missing. Categorisation has to be done manually. The scan is then run automatically and warns you when it detects new cookies. The main limitation of the free version is that it runs only on 1 domain (not including subdomains) and up to a maximum of 100 pages.
Can be tested here: https://www.cookiebot.com/fr/
When I was doing my researches, I've found this article which explains you how to do a manual scan of your website using PhantomJS. I must admit that I haven't tested this solution but for sure, if you use it, you'll have to run the script manually on a regular basis, you'll have to find the differences (new cookies) between each run, you'll have to manually categorise the cookies, etc.
#Get the consent
This can be done in a lot of different ways. The most common one is to display a banner on your website that will ask your users if they accept the cookies or not. It's also possible to give them the possibility to do a more customised choice, category by category (this is what can be called a "Preferences center"). This choice can be done directly on the banner of somewhere else on the same page (in a modal for example). Don't forget that navigating to another page of your website can be considered as a consent ;).
When the user has done his choice, he should be able to modify it. It means that you have to offer him a page or a link that will open again the banner / preferences center.
By default, OneTrust has a banner you can customise (colors, display, etc.) and that allows you to accept all the cookies or to open a modal to make a more precise choice. It's pretty well done.
You can also easily integrate a button on a page to open this modal again if the user wants to change his choice.
You have to know that OneTrust also offers some customisation choices that don't always follow the GPDR / french law recommendations and nothing warns you about that.
Here the choices are much more limited. At least with the free version. But it's enough to get access to main functionalities. Then their documentation is simple and pretty well done so with it, you'll be able to create the functionalities that may be missing. Here again, no real mention of the GDPR / the French law so you have to be careful about the choices you're making.
There are not a lot of other good tools available online. Except maybe cookie-script. Otherwise, you can still create your own banner / preferences center.
In React, there is the components-extra library which is based on material-ui and where you'll find a cookie banner and a preferences center totally customisable. That said, it means that it's up to you to register the choices made by your users and to create all the API around it to get the value and use it to block or not the related cookies.
#Block / authorise cookies
Usually, the most common way to save the choices made by your users is to save it in a cookie. And then it's this cookie that you'll have to read to know if you can create / read the non required cookies.
First party cookies
For the first party cookies that are created in your own code, unfortunately you'll have to do some modification directly in your source code to control their creation / reading. It's up to you to find a good architecture to respect the choice made by your users.
Third party cookies
If you've correctly put all your external scripts into Google Tag Manager, it's now a matter of creating some configuration in it. The main idea is that we're gonna read the value of the cookie and based on it we'll create some Triggers (that will be used as triggers or as exceptions) to control our tags. And so it'll indirectly block the creation / reading of the cookies.
I don't want to go too much into details as the implementation may vary base on the tool you've decided to use but I'll present how your GTM configuration should look like. This example is mainly based on what is presented in this article.
If you decide to 100% follow this related article, I would suggest you to move your OneTrust script out of GTM as some users (thanks to browsers extensions) are blocking all the requests to googletagmanager.com so they may not see your banner.
For the variables, you have to know that there is a "1st party Cookie" type of variable and thanks to it, you'll be able to easily read the value of the cookie in which you've save your users choices.
false based on the choice of your users.
This is here where you'll have to do the main part of your configuration:
- Triggers of consent updated: it's triggered every time your user is making a choice regarding the user of cookies on your website. It has to be triggered for every saving of their choice. There are multiple ways to implement it. You can for example use a "Custom Event" or a "Click on Element". You can use it to trigger a tag as soon as a choice is made.
- Exceptions for each type of cookies: those triggers will be used as exceptions; they will prevent your tags from being triggered. They are "Custom Event" and as we want them to be fired every time (ie: for each event), their value will be
.*and we'll activate the regex matching. And then we set the event to be fired only if the variable (previously created) of the corresponding cookie's category is equal to
false. The following image shows you what it could look like.
Now, you just have to use your triggers. For each tag creating or reading cookies, just add as an exception the corresponding triggers that you've just created. And as we said, you can also add as a classic trigger the trigger of consent updated.
As we've just seen, the main difficulty is to be able to correctly list all the cookies created on your website (especially if this one has been created years ago and you've never really taken care of how you're creating / reading cookies) to be able to block them.
If you're using Google Tag Manager, this management is pretty easy and efficient even if you add new scripts.
If you liked this article, please share it on Twitter.