In the first part of this series “Introduction and Risk Analysis“, we’ve provided you with an overview of which data protection regulations exist, which requirements you need to meet in order to collect data in compliance with the GDPR, and what the consequences are.
In this part, we will address the question how a CMP (Consent Management Platform) technically works.
Why do I see consent banners over and over again?
Perhaps you have wondered why you keep seeing the consent banner on a website, even though you have already made your decision? Well, there can be different reasons for that.
Apart from special situations, the most likely reason is that you are visiting the website with different devices or browsers. This is because, just like most web analytics systems, the CMP cannot recognize a user across different browsers or devices. So let’s have a look on how the CMP works.
Users are browser instances
So, when a user visits the page of a website where a CMP has been implemented correctly, this particular CMP will be involved immediately.
In other words, if a user visits the website for the first time (or repeatedly without having made an explicit decision), the corresponding Consent banner will be displayed.
If the user has already made an explicit decision in a previous session, this decision is used to fire those technologies to which the user has consented.
So how does the CMP distinguish the user and how does the CMP know what technology the user has consented to?
First, let’s take a look at how the CMP identifies a user. To do this, we will review the CMPs from Usercentrics and OneTrust.
Usercentrics
As soon as a web page is opened in the browser where Usercentrics is implemented, a controllerId is generated and stored in the browser’s Local Storage.
Initially, it does not matter whether the user explicitly consents to the use of technologies or not – the controllerId only serves the purpose of recognizing the user or the browser instance.
In the context of this controllerId, however, the explicit consent or rejection of technologies by the user is also stored.
The main advantage of storing the controllerId as well as the explicit consent/rejection in the Local Storage is primarily that this – unlike cookies – cannot be automatically deleted without further intervention.
OneTrust
If a user now opens a web page in the browser where OneTrust is implemented, a so-called consentId is created. However, unlike Usercentrics, this is not stored in the browser’s local storage, but rather as a cookie.
Similar to Usercentrics, it does not matter whether the user explicitly consents to the use of technologies or not, because the consentId also is used to recognize the user or the browser instance.
In the context of this consentId, the user’s explicit consent to or rejection of categories is also stored.
Storing this data in a cookie carries the risk that it will be deleted as well when cookies are deleted (e.g. via the browser settings) and the user will then be presented with the Consent banner again.
Visiting the website for the second or repeated time
Now, as soon as the user visits the website for the second or repeated time, the CMP extracts the stored information regarding the given or denied consent and then pushes this information into the browser’s data layer.
This information can then be used by the corresponding technology to fire a tag or not. In this way, you ensure that the tags requiring consent are actually only fired if the user has indeed given his or her consent.
Using data provided by CMP
Now let’s take a look at how we can use information provided by the CMP with Google Tag Manager.
First and foremost, the CMP provides the user-given consents in the DataLayer of the GTM upon initialization. How this is done depends primarily on the CMP being used.
For example, the CMP from Usercentrics provides the consent for each configured technology granularly in the dataLayer:
OneTrust’s CMP, on the other hand, groups several technologies into categories and thus only stores the category number in the dataLayer for which there is a consent:
Both approaches have their advantages and disadvantages, which I will discuss in more detail in another article.
The information available in the dataLayer can now be stored in a data layer variable and used accordingly in the configuration of triggers for the respective tags.
So, for example, if you want to customize the trigger to fire the Google Analytics tag, you will fire the trigger only if the dataLayer had the value
- “Google Analytics: true” when using Usercentrics or
- “C0002” in “OnetrustActiveGroups” when using OneTrust.
Potential problems
However, the procedure described here can also lead to so-called race conditions.
A race condition is an undesirable situation that occurs when the GTM attempts to trigger two or more triggers simultaneously, but these fail due to event sequence or missing data in the data layer.
Therefore, it is necessary to ensure that the information and events provided can be executed in the correct order. A proven means in GTM is, for example, the use of trigger groups.
Need help?
When you are unsure if you are experiencing a race condition or if you are completely unfamiliar with implementing a CMP, feel free to turn to us at e-CENS – we’re here to help.
Upcoming
The next part of the series will focus on how to compensate for the gaps created by the lack of consent…
