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:
- Strictly Necessary – any cookies that are essential to how the site operates (e.g. storing shopping cart information on an ecommerce site).
- Preference/Functional – cookies that store information on any aspects of the site that users can customise (e.g. saving login details for automatic login).
- Performance/Statistics – cookies containing information on how users interact with the site (e.g. Google Analytics).
- Marketing – cookies with information to be shared with advertisers (e.g. Facebook pixel).
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:
- Let users know that you’re using cookies on your site
- Explain what the cookies are for and why they’re there (in clear and plain language)
- Give users a means to provide explicit and granular consent for all non-essential cookies that must be obtained before they become active
- Log records of collected consent of cookie usage
- Give users the option to withdraw that consent at any point
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.
dataLayer.push({
'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:
- Set it to fire on the earliest data layer event.
- If your TMS allows you to manipulate the load order for tags, use this in conjunction with the previous tip.
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:
- Two triggers for the same event that differ by which consent group ID is needed for the respective tag.
- Two exclusion triggers for that event, if the respective consent group ID is not present in the data layer.
Takeaways
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:
- Make sure all consent groups are well defined and as granular as possible (with IDs).
- The documentation of the groups should be as comprehensive as possible to show distinctly how the site’s cookie fit in.
- Your cookie banner should allow visitors to give/revoke consent at any time and explain each cookie group clearly.
- Make sure the firing logic for all relevant tags is as granular as possible to avoid cookies firing at incorrect times.
Thanks for reading, and if you have any questions, do let us know – myself and the Data team are always keen to help!
