Protecting a user’s privacy rights with a website begins with your first line of code. From this point on, all developers should have data protection in the back of their minds. This is especially true for the backend. Once that’s been acknowledged, the frontend has its own data protection measures that need to be taken, the most relevant of which is a site with a concisely written (presented content), easy-to-use cookie consent.
*I’m not a lawyer so don’t take everything I have to say on lawfulness to be the best source of legal counsel. Just trying to help people of interest gain some understanding in the relevance of privacy experience and data protection.
A GDPR-compliant cookie consent is the first step in telling a user that your organization has taken steps to provide a privacy experience for the user and that the user should trust in their data being processed appropriately. Regardless of the law, it's important for every organization to have an established strategy about privacy in general. PX is about building trust by giving transparency and control to individuals over the processing of their personal data. Showing your users they are using a site from the from a reliable service provider who cares about their personal data makes them feel comfortable from the get-go of CX.
One example in working towards compliance with your cookie consent is building anonymous user profiles / segmentation, "personalization,” so to say, can be done in a way that literally doesn't go against any security and data protection laws. Take into account that this might be annoying to the users in that they are being tracked, categorized etc. However, giving your users such information and control over such personalization features will be received as good PX.
Laws Behind Having a Cookie Consent
The EU’s ePrivacy Regulation (ePR) refers to cookies and allows the usage of the category “strictly necessary”.
(66) ... It is therefore of paramount importance that users be provided with clear and comprehensive information when engaging in any activity which could result in such storage or gaining of access. The methods of providing information and offering the right to refuse should be as user-friendly as possible. Exceptions to the obligation to provide information and offer the right to refuse should be limited to those situations where the technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user.
This is also the case for GDPR and is one of the utmost important points of GDPR for site builders to take into account. Throughout GDPR, there is only one explicit reference to cookies in Recital 30: Online Identifiers for Profiling and Identification:
Natural persons may be associated with online identifiers provided by their devices, applications, tools and protocols, such as internet protocol addresses, cookie identifiers or other identifiers such as radio frequency identification tags. This may leave traces which, in particular when combined with unique identifiers and other information received by the servers, may be used to create profiles of the natural persons and identify them.
Additionally in GDPR, data subjects have the right to withdraw consent in Article 7 Conditions for Consent, one of the key requirements for your cookie consent. Your cookie consent must provide an opportunity for users to opt-in/out of specific cookies your site is collecting. The cookie consent must present language that is “in an intelligible and easily accessible form, using clear and plain language.”
For the cookies which are considered as personal data you need to identify the lawfulness of processing (Art. 6 of GDPR). If the result of a legal interest assessment states that it's Lin your organization’s legitimate interest to set some of your cookies, then those can be set without consent. Instances of personal cookies can include: a session cookie for the purpose of identifying a logged in user; 3rd party cookies. It should be noted that it cannot be guaranteed that the 3rd party provider will never connect the collected information to personal data
There are, of course, certain examples of cookies which are not personal data. One instance of this is a cookie from the loadbalancer / CDN infrastructure to identify the client and drive traffic to the same application server, where it is sure that this cookie and the information collected by the potential tracking will never be connected to personally identifiable information
Since GDPR has gone into effect
Studies have recently begun to come out on how GDPR is affecting organizations and the means by which organizations reach and track their users. One of the more noteworthy studies comes from Oxford Press, titled Changes in Third-Party Content on European News Websites after GDPR, by authors: Timothy Libert, Lucas Graves and Rasmus Kleis Nielsen. They analyzed 200 news sites throughout Europe and how these sites collected cookies for 3rd-party content. Overall, The number of third-party cookies per page dropped by 22% across all news sites, the biggest drop coming from the UK at 45% and biggest increase (and only increase in the study) coming from Poland at 20%. There’s clearly quite the gamut of change here.
In addition to breaking down the study by country, the study also broke down cookie usage within those 200 sites.
It can likely be inferred from the drop in advertising and marketing that these news sites have taken in less revenue from advertising since GDPR has gone into effect. Perhaps even these news sites raised prices in order to make up for the drop, but who really knows.
As design optimization is pivotal for improving CX and converting users into customers, it's sure that there are fewer leads leading to fewer conversions. Design optimization plays a critical role in reaching out to users and converting users into clients. But if 3rd-party cookie data is being collected less and less, companies will have to find more channels for connecting with users.
A Couple of Examples of Compliant Cookie Consents
Here’s one example of a cookie consent that I found to meet all the requirements of GDPR.
This cookie consent provides all categories of cookies which could be collected and definitively notifies the user of the purposes of those cookies, providing further information for each cookie categorie. This also allows the user the option to immediately accept all cookies or reject all cookies. It’s important to note here that when this purposes instance opens, the boxes are automatically unchecked. This is more appropriate in terms of GDPR as your cookie consent should deliberately give the user the ability to opt-in at their own will to do so.
After accepting or rejecting the cookies of the user’s choice, the user is then reverted back to a confirmation page.
It’s not only GDPR which directly tackles appropriate usage of cookies. The recently passed California Consumer Privacy Act also addresses cookies directly, categorizing cookies as “unique identifier’ and ‘unique personal identifier.’ Under CCPA, users must opt-out of having their data processed and/or have the right to access the processing of their personal data, particularly in a B2B transaction. This is very different from the opt-in approach of GDPR, yet, is still heavily relevant to how your cookie consent should be devised.
We have developed our own cookie consent solution (implemented and tested first on our www.brainsum.com homepage, then on www.tieto.com) that we're very pleased to offer as a free and open source solution. We’d like to thank Tieto for sponsoring the development, and allowing us to make it open source.
Source code: https://github.com/brainsum/cookieconsent
Demo site: https://brainsum.github.io/cookieconsent
This is a deliberately minimalist-designed cookie consent that will pass automated Cookiebot report. Side note, we were so proud to get the Cookiebot report back that our solution met GDPR compliance.
When going to our homepage the user will see a bar at the bottom.
Once the user has clicked on the cookie settings link the following box pops up:
Our cookie description is short and sweet, yet still meets GDPR compliance by informing the user of the purpose of these cookies as defined in GDPR. We also display the default opt-out for the user, allowing the user to choose to opt-in at their own discretion. It should be noted that under the California Consumer Privacy Act, the cookie settings could be in the opt-in default position.
Testing your Cookie Consent
We use CookieBot on a regular basis to give our clients and potential clients an automated, detailed, concise report for meeting GDPR compliance with a cookie consent. Cookiebot is one of the more reliable and readily to use tools to check where your site is at in terms of compliance.
We recently ran a Cookiebot report for a potential, enterprise-level client. We soon after received the report, which determined that the site did not have cookie consent which met compliance. Strangely, the screenshot captured and posted to the top of the report clearly displayed that a cookie consent was present; yet, the report told us that the option to opt-in wasn’t present. It was absolutely perplexing to us. I should note here that I'm purposefully not referencing the cookie consent we analyzed in order to keep the privacy of the company that created the cookie consent and any potential reference to their client.
Brainsum then reviewed the report after the screenshot clearly displayed a cookie consent.
We weren't quite sure as to why the Cookiebot test revealed that prior consent because we felt the given cookie consent provided an opt-in with clear and concise reference to necessary cookies. So, we reached out to Cookiebot directly and received this response:
The result that you are referencing should not be interpreted as "not allowing for opt-in" or "not having a cookie consent solution in place on the website". The result refers specifically to 'prior consent' which under both the GDPR and the ePrivacy Directive refers to the fact that you are not allowed to set any cookies other than those strictly necessary until you have received the proper consent from your users (for the GDPR this is limited to cookies containing personal data whereas for the ePrivacy Directive it is for all kinds of cookies). This ability to "hold back cookies" is something that many consent solutions lack. If you get a test result listing prior consent as problematic - as in this case - then it is either because there is no such functionality implemented on the website or because it has not been implemented correctly. In either case, the result is that (all or some) cookies are being set even before a user consent has been obtained and thereby not in compliance with GDPR and ePR.
I hope this clarifies - otherwise do reach out again.
Have a nice afternoon.
We later determined that the cookie consent hadn't been installed properly, either by the client or the agency that developed it. We passed this info on to their client and they were grateful for pointing out the flaw in their cookie consent.
There are numerous cookie consent products out in the web consisting of various approaches to data protection requirements and objectives. Some are definitely better than others in meeting compliance. If your organization has yet to implement a solution for informing users what kind of cookies are being collected on your site, the purpose of collecting cookies, and giving users the right to opt-in/opt-out of cookie collection (especially with 3rd-party cookies), then you had better make it a priority.