A guide to Cookie Consent with Tag Management Systems

Digital analytics is constantly changing, so it’s important to make sure your tracking practices are as safe and reliable as possible, especially when it comes to how – or indeed if – your users want to be tracked. This post sets out to give guidelines on how you can implement a consent management system on your own website. In particular, crafting cookie consent groups, implementing cookie banners onto your site and updating the tags within your Tag Management System (TMS). All information provided is designed to be platform-agnostic, so these steps for implementation will work with any TMS you’re using.

Step 1: defining your consent groups

Now, before we start thinking about implementation, the first thing you want to tackle is sorting all first- and third-party cookies on your site into consent groups. These classifications are essentially a list of categories that the site’s cookies can be sorted into, and each group should be as well defined and concise as possible. The goal here is to make sure there’s no ambiguity on what these groups represent. This will help users understand them quickly, and ensure no confusion during the implementation stage later on.

Consent groups vary from site to site, but they are generally based on the purpose of the cookies. As an example, CookiePro, a cookie consent management software, uses the following consent group set by default:

These aren’t the ‘be-all and end-all’ of cookie consent groups but can be used as a source of inspiration when tailoring them for your site. They’ll be driven by data protection and legal terms, so I recommend checking over those and conversing with any other relevant departments to help define what groups are needed and what they’ll cover. Once you have a defined set of cookie consent groups, give each group a short unique ID and compile this information into a document for reference (we’ll come back onto this later).

Step 2: implementing your cookie banner

With your consent groups sorted and documented, it’s time to start implementing the logic and UI to put them into action. The central piece when it comes to cookie consent management is the cookie banner. We’ve all come across them multiple times across the web, and they exist primarily for two reasons: to give users control over what cookies are deployed and to communicate user preference with your TMS. Your cookie banner should, at the very least, serve all the purposes outlined below:

Now, there are two ways you can approach implementing the cookie banner: creating one from scratch or using a pre-built consent management tool like CookiePro, for example. The former is the more difficult option but allows for the most customisation on how you approach the bullet points above. Whereas the latter has been built to handle those points and you can quickly deploy the banner with a script tag. Both have their place, and I’d personally recommend the consent management tool option for its ease of use, but it’s completely up to you.

Earlier, I briefly touched on giving each cookie consent group a unique ID – now it’s time to explain why! The key for setting up consent management is to figure out how the site will communicate with the scripts that deploy the categorised cookies, and the banner is one part of this. When the user picks which cookies they give consent to, the banner should then send a signal to allow the script to initialise the cookie, and this is usually done with a data layer push.

If you aren’t familiar with the data layer, it’s a JavaScript object that acts as a buffer between your site and TMS. This is where you’ll store all information relating to cookie consent, which you can reference in your TMS. For guidance on setting this up for your site, Google has created a dev guide to help you get started. It’s written in relation to using Google Tag Manager, but the data layer itself is platform-agnostic and can work with any TMS.

With the data layer ready, it’s time to start passing cookie consent data to it. Once the user has stated (or updated) their consent preferences, the banner should then send a data-layer event push, with a key-value pair containing the IDs of all consent groups the user has given permission to. That key-value pair will then be used to tell your TMS which tags can fire on the site. Bear in mind, as some cookies are needed for the site to function, the ID for that consent group will always be passed as those cookies are already active on the site.

For what this would look like in JavaScript, here’s a simple example, where CG1 and CG2 represent ‘necessary cookies’ and ‘functional cookies’ respectively. The event name can then be referenced in the tag trigger conditions in the next section.

    'event': 'consent-updated',
    'consentIDs': 'CG1,CG2'

Step 3: perfecting your TMS setup

Now comes (arguably) the most important step of the process: sorting your tags into their respective consent groups. The documentation covered earlier around consent groups will be of important use here, as we’ll begin to amend the firing logic for all tags that use cookies.

Just to recap, the user has made their choices for consent and the relevant group IDs are then pushed to the data layer. The next step is to link these IDs to the firing conditions setup for all relevant tags. The general idea for this is to create a system that acts as a ‘gatekeeper’ for the site that only lets in cookies that have the relevant ID(s) and block the rest. The points below outline the general steps required to implement this system into your TMS – make sure to test this in your staging environment first to help work out any kinks:

1. Create a variable that reads the data layer for the key-value pair containing the string of cookie consent group IDs, and returns the value to the TMS

2. If you’re implementing the banner through your TMS as a custom script, make sure you set the banner to fire before any other tags:

3. Amend all tag firing conditions to include the relevant cookie consent group ID, using the variable created in step 1:

If any tags share the same firing conditions but fit into different groups, make sure the conditions for each tag are as granular as possible. For example, say you have a GA event tag and a Facebook pixel tag on an ecommerce site, and they both fire on the same event that occurs when a user adds a product to their cart. Before you’d create one set of rules for both tags, but now you’ll need around four triggers to ensure the user’s consent is respected:


And that covers all the basics of setting up a consent management system on your website. There’s a lot to digest there, so I highly recommend bookmarking this post to use as a reference guide to come back to as you tackle each aspect.  In the meantime, here are a few important takeaways to remember:

Thanks for reading, and if you have any questions, do let us know – myself and the Data team are always keen to help!

Join the Inner Circle

Industry leading insights direct to your inbox every month.