Skip to main content
An illustration of am exhausted man slumped in front of a computer.

I hate cookie banners

Carl Gottlieb
Carl GottliebData protection officer
Advice and expertise7 mins

I’m a data protection officer, so you won’t expect me to say this, but I will. I hate cookie banners. I think everybody does, whether they are privacy people like me, or web people like most of you.

But sadly, you probably need a cookie banner on your website, so in this blog I’m going to talk about what they actually are and the many things you’ll need to consider when implementing them. Please note that nothing in this blog constitutes legal or professional advice. It’s just one man’s observations and opinions, which you’ll hopefully find useful.

It’s important to start off with a quick note about the word “cookie”. Despite us talking about cookie banners, we’re not really talking about cookies. We’re talking about active components on web pages that are usually lines of javascript which usually drop and read cookies on your system. Cookies themselves aren’t problematic from a privacy perspective, it’s how they are used – as is the way scripts are used in non-essential ways in general. Really, cookies are a by-product of the main issue, which is scripts. If you use a tag manager product such as Google Tag Manager then you might refer to scripts as “tags”, but for the purposes of this blog I’ll use the word script to denote the primary thing we want to control with this banner.

The other huge thing to mention at the very start is the important question of compliance and to what degree you bother with all of this. I’m not going to discuss the ethics of following the rules, or the morality of doing the right thing by the individual. And I’m not going to criticise anyone’s privacy practices. I know full well that privacy is not the top agenda for most organisations, and I’m not going to pretend anything different or preach to you. You will see in this blog that implementing a cookie banner in a compliant way can (and likely will) materially hurt your analytics, advertising revenue and marketing goals. So, despite many of your best efforts, it is very likely your organisation may push back and lead you into a non-compliant compromise. But for the purposes of this blog, I’m going to make the assumption that complete compliance is your plan.

Why bother?

Why do you even need a cookie banner? After all, nobody reads them, right?

Well, the law says you do. Across the EU and UK we have two sets of laws in play.

First is the GDPR, which is about personal data, and from 2021 there will be the UK version of the GDPR, which will look pretty much the same. Two parts of the GDPR that are particularly relevant to the cookie banner topic are the need for a “lawful basis” to process personal data, and the GDPR’s definition of consent. The lawful basis part means that you have to find a lawful reason to handle the person’s data according to a set of rules that are fair and just generally make sense.

Consent is one of those lawful bases and is defined as a “freely given, specific, informed and unambiguous indication of the data subject's wishes” through “a statement or by a clear affirmative action”. This means that consent as a lawful basis is used when you can freely opt in and out of something, such as receiving a marketing newsletter. But consent wouldn’t be appropriate for something that is essential, where removing your consent would break the website or service. It would be nice to tell your employer that you don’t consent to having your pay details shared with HMRC, but sadly they rely on their legal necessity as their lawful basis instead.

A bronze statue of Justice.

The other law to look at is The Privacy and Electronic Communication Regulations, also known as “PECR”. PECR is the UK’s implementation of the EU’s ePrivacy Directive. Each EU country implemented the Directive in their own national law. This means there are 28 different versions of the rules across the EU and UK. But fortunately, for the purposes of cookie banner rules they’re all virtually identical. I’ll mainly refer to PECR when describing the ePrivacy rules, but if you have an international focus then you’ll want to look at the rules for those other countries. PECR’s rules around cookie banners relate to public networks only – not intranets – and are generally focused on regulating the use of non-essential scripts.

Each country has its own privacy regulator or “Data Protection Authority” or “Supervisory Authority”. I don’t know why we have three names for the same thing, but we do. The UK’s regulator is the Information Commissioner’s Office, the “ICO”. These regulators provide guidance on how to comply with the laws and rules and they can also enforce them and punish rule breakers, such as with monetary fines.

So, remember that you have to consider both PECR and the GDPR when trying to make any public website compliant. Here is a very high level summary of what each law requires from a technical perspective:

PECR (most prescriptive)

  • You must get prior consent before enabling non-essential end-device processing, e.g. scripts, dropping cookies.


  • You must get consent for any data sharing or where you’re reusing data for another purpose.
  • You need records/proof that you actually got the consent.
  • Consent must meet the standard of being a “freely given, specific, informed and unambiguous indication”.
  • You must provide a way to withdraw consent as easily as it was to give it.

Just another quick note about language, here are two important terms to know:

  • Data Controller (The organisation that decides what to do with data, e.g. a University.)
  • Data Processor (The organisation that acts upon direct instructions of the Data Controller, e.g. Microsoft.)

Some organisations might appear to be just a data processor, but since they also reuse the data for their own purposes they can also become a Data Controller. Google is a good example of this. When it comes to setting up Google Analytics, how you configure it will determine if Google remains a data processor or actually becomes a fellow data controller.

What is a cookie banner?

If you ask a cookie banner vendor what their product is they will tell you that, “It’s not a cookie banner, it’s a Cookie Consent and Website Scanning Content Management Platform.”

This actually means it is a cookie banner, but it also provides these functions:

  • Website auditing for scripts.
  • A user accessible Preference Centre that lets the individual read what all the scripts are doing and choose what to enable or disable.
  • Dynamic enabling/disabling of active components, such as scripts.
  • Automatic cookie policy generation.
An example of a Cookiebot cookie banner.

A cookie banner is more than just a banner (Example: Cookiebot)

So really, a cookie banner is only one quarter of the solution. Here are the main four parts of the thing:

  1. [Front-end] The cookie banner that a user sees on first arriving at the website.
  2. [Front-end] The preference centre that sits a virtual layer below the banner, accessible at any time to make consent choices.
  3. [Front-end] The hidden Javascript technology that the banner and preference centre use in the page that enables/disables scripts and integrates with tag managers.
  4. [Back-end] The cloud based control centre that administrators use to define the banner, the preference centre, perform audits and track records of consent.

What do I need consent for?

The PECR rules boil down to one simple fact – you need prior consent before enabling any non-essential scripts on your website. And by “essential” I mean the components that will break the core of the website or its security if you were to disable them, such as the components of content delivery networks, load balancers, tag managers or authentication systems.

Below is a table describing different types of scripts and their cookie banner consent requirements.

Type of Script



Consent Requirements


Crucial components will break if this is disabled.

CDN, CMS, load balancing, authentication tokens, Google Tag Manager.

Enabled by default. No consent needed. No ability to disable.

Non-essential functionality.

Things work fine with these disabled, but the visitor loses some additional optional functionality.

Remembering passwords, language settings, chat functionality.

Disabled by default. Prior Consent needed. Ability to opt in.

Tracking (by the Data Controller), aka First Party Tracking.

No impact to the user if these are disabled. Web host loses analytics and tracking capability.

Web page analytics that are solely managed by the Data Controller (can be hosted on a SaaS platform).
Piwik, basic Google Analytics.

Disabled by default. Prior Consent needed. Ability to opt in.

Third Party Tracking (data is shared with another Data Controller).

Social features are likely disabled. Ads are not personalised. Ad attribution is not possible. All analytics and tracking capability is lost.

Facebook Pixel, LinkedIn tracking, Google Ads.

Disabled by default. Prior Consent needed. Ability to opt in.

Which cookie banner to use?

You really have two options with cookie banners – build a solution yourself (don’t do this) or use an off-the-shelf product. I say you shouldn’t build it yourself because frankly you won’t do as good a job as the off-the-shelf vendors have done and it’ll cost you hundreds of times more. The off-the-shelf vendors have invested tens of millions of dollars developing these products over many years and have deployed them to the largest websites in the world, so they’ve got this nailed down. Unless you have an extremely special need and have some of the best developers in the world sat around doing nothing, buy an off-the-shelf product such as the great ones I’ve listed below:

Here are some visual examples of these out in the wild on live websites as of September 2020:

CookiePro (OneTrust)

The Privacy Preference Centre screen in CookiePro.
The cookie bar from



The Civic cookie bar from



An example of a Cookiebot preference centre.


An example of a Metomic cookie bar.


In the next blog I’ll describe some of the nuances and gotchas to look out for when implementing these solutions, including client-side versus tag manager script management and how to handle embedded YouTube videos that bring their own tracking onto your website.