Consent management with Google Consent Mode: why you should (or shouldn’t) adopt it

In recent years, we’ve witnessed a continuous evolution in the digital world regarding privacy and data protection. Between the institutional advances to protect users’ rights to know and decide on the information collected about them, the efforts of big players such as Google or Facebook to adapt to them, and, in between, the real implications that this continuous tug-of-war has for brands and service providers, we often find ourselves not only with new requirements to meet but also with doubts about what exactly these requirements are and the right way to meet them.

In this context of evolution and uncertainty, Google has been making continuous progress.  Not long after joining the IAB’s Transparency and Consent Framework and adopting compatibility with its version 2 (TCF 2.0), the tech giant surprised the world with another announcement: its proposal for GDPR-compliant data collection, which they have dubbed Consent Mode. 

Although officially still in beta, it has been in operation for some time now and is fully integrated with its main analytics and marketing platforms: Google Analytics (in its two versions, Universal Analytics and Google Analytics 4), Google Ads, and Floodlight.

But how does this launch affect us? Should we integrate Consent Mode into our analytics and advertising ecosystems? What are the implications for our brands? 

What is (and what isn’t) Google Consent Mode?

First of all, it’s important to clarify that Consent Mode is not a complete solution (and it doesn’t intend to be). It’s not a Consent Management Platform (CMP). The functionality needed for managing user consent —cookie warnings, preference registration, blocks and restrictions… — should continue to be provided separately in any case. 

However, it does provide a common standard for defining and storing the state of user consent, with the idea of mediating between Google’s analytics and advertising platforms, such as Analytics or Ads —as well as other third-party platforms that decide to adopt it—, and the corresponding manager or CMP.

More specifically, it defines several categories or types of consent, analogous to the usual cookie categories with which most CMPs work, and offers a common access point through which to define or consult, for each case, the status of the user’s consent (allowed or rejected): 

• On the one hand, the CMP or cookie management solution will provide the necessary technical infrastructure to inform, query, and remember user preferences. 
• On the other hand, the tags (the pixels or pieces of code that each respective platform needs to insert into the website), will block or limit their functionality based on the preferences selected. 

Once all this is in place, the desired goal is finally achieved: Google Analytics, Ads, and any other compatible platform will launch their requests even if the user rejects their associated category of cookies, albeit in a more limited way but —at least in theory and according to their criteria— compatible with RGPD compliance.

Implications: is it for me?

The advantages this model has for Google are obvious: it increases both the total volume of data received (compared to models that block measurement altogether) and its quality  —at least from their point of view—, as they take control over how information is limited (instead of leaving this decision to the CMP or other external actors). 

But, what about us? Is it in our interest to adopt Consent Mode?

I’m afraid the answer is… it depends. Both in terms of compliance and the quality of the data obtained, Consent Mode has advantages and disadvantages. 

Firstly, it is not 100% clear yet whether Google’s solution will ensure compliance with the GDPR, at least not in its strictest interpretation. In theory, it should be considered sufficient, and it certainly sets the bar for the rest of us: we don’t want to be below sufficiently widespread solutions like this one. 

But if our priority is to play it safe and avoid any problems altogether, the only secure solution is a strict implementation, which does not provide any data to third parties until users have confirmed their consent. 

As for data quality, the decision will depend on the nature of our business and the data we need and consume most regularly. Consent Mode offers automatic modelling that tries to fill in the information that users have not agreed to provide us with. Thus, we will have to ask ourselves: do we prefer a more global but more limited view, or complete and reliable data, but from a more limited subset of users? 

The first option is for you if your website has direct and punctual conversions, short user journeys, or simple attributions, and therefore enriching the statistics with data from restricted users could be of help. In this case, installing Consent Mode can be a good idea.  

If, on the other hand, you have complex customer journeys, long funnels with multiple intermediate steps, or multi-domain, multi-session, or multi-platform tracking, Consent Mode may be of little help or even counterproductive, and it may be better to stick to real, concrete data.

Let’s get to work 

If we finally decide to implement Google Consent Mode, the best thing to do is to put ourselves in the hands of a specialised provider that can offer a customised solution adapted to our particular case. With the integration of Aukera, one of the few Spanish agencies certified by Google in 6 of its Marketing Platform products, at Good Rebels we bring you all the keys to tackle this implementation:

How is it managed?

We can manage Google Consent Mode through Google Tag Manager or Global Site Tag (gtag.js).

Following the One Google Tag (OGT) strategy for managing Google tags and pixels, the idea is that a single script (the GTAG global site tag or a GTM container) is installed in our app or website, and everything else is integrated from there. 

That being said, the ideal situation is an implementation in which the entire analytics, marketing, and optimisation ecosystem are centralised in a Google Tag Manager container, including everything related to consent management, from Consent Mode to the CMP itself and cookie notices. 

This scenario allows for full integration, not only of Google tags but of any third-party tag, even if they are not explicitly compatible with Consent Mode.

How does it work?

The types of consent defined are the following:

• ad_storage: stores information for advertising purposes (e.g. identification of user profile for personalised advertising).
• analytics_storage: stores information for statistical purposes (e.g. identification of visits for session metrics).
• functionality_storage: stores information necessary for the correct functioning of the website or application (e.g. language configuration).
• personalisation_storage: stores information for content personalisation (e.g. personalised recommendations).
• security_storage: stores of information for security and access control (e.g. authentication).

Each tag or pixel on a given platform may require permissions from one or more categories, depending on their functionality and the nature of the data they collect. 

Of course, the focus will normally be almost exclusively on the first two types, analytics_storage and ad_storage, which correspond to the classic categories of “analytics cookies” and “marketing/advertising cookies” and are therefore the most relevant in terms of the main data protection regulations (GDPR/RGPD, UK-GDPR, and CCPA).

Once this structure has been defined, Consent Mode will allow us to do the following: 

• Define or modify the consent status (allowed or denied), according to the user’s choice.
• Define a default status that will be applied to visitors who have not yet expressed their preferences, and which could be different depending on their regional settings (and therefore the legislation applied). 
• Check the status at any time. 

This implies that any third-party tag or pixel inserted through Google Tag Manager or compatible tag manager will be able to check the consent status at any time and, in case it does not have the relevant permissions, cancel the process.

Partial tracking: pings

Without Consent Mode, there would be times when, depending on users’ consent preferences, we would not receive any data, as the tags would stop working. 

However, thanks to Consent Mode, we can modify the behaviour of these tags so that we don’t stop receiving data, but instead adapt the data we receive to users’ preferences. For example, if a user accepts analytics cookies but not advertising cookies, we will receive different information than if they accept all of them. 

The possibilities are endless, and will depend on the alternatives that have been considered when developing the tag. However, they all share a common objective: to comply with users’ consent preferences while still allowing us to receive the maximum amount of information possible.

If users don’t accept the analytics or advertising categories, cookies relevant to those categories will not be stored, which implies we won’t be able to correctly identify the user, and thus have less available, quality data to track  the user’s complete journey, session metrics, etc. 

In the strictest case —rejection of all cookies— we would receive an anonymous ping instead of the users’ full tracking data. Although pings don’t provide a complete picture of each website visit, they can still be used to compile general statistics and measure specific actions. For example, if a user who has rejected all cookies completes a purchase in our ecommerce, it would still be considered for general statistics, such as the conversion rate. However, all the previous browsing information relating to the users’ behaviour prior to completing the purchase would not be available. 

However, this doesn’t mean that information relevant to conversions such as previous actions, attribution, or demographic data will not be available; it is just that it will, at least partially, be based on estimates based on statistical models that will fill in the gaps.

In theory, the end result will be a less accurate view, but with a wider scope than if we completely excluded all users who do not give their full consent.

 Google’s official documentation provides more specific information on the models used.

What should I do, then? 

There will be few scenarios where the decision is clear and straightforward:

If you already have a comprehensive consent and cookie solution in place which (preferably according to an external audit) is sufficiently restrictive and robust in both compliance and data collection, then the best option is to keep it as is, in order to preserve data consistency and be able to compare new and historical data. 

On the other hand, if your integration is incomplete, outdated, or poorly implemented, then there is no doubt: any upgrade aimed at improving it is not only recommended but necessary. In this context, Google Consent Mode may be one of the options to consider as part of a possible solution. 

Let’s not forget that a partial implementation of consent management solutions, such as those that arbitrarily delete cookies without paying attention to the tags that generate them, is worse than having nothing at all: it does not comply with regulations and contaminates analytics with erroneous or poor quality data.
In any case, the best option is always to put yourself in the hands of a specialised provider who will analyse your particular case and propose and implement the best possible solution for your situation. If you want to count on us… let’s have a chat!