In theory, the Google Consent Mode is a great idea – it natively builds in consent control into your data collection set up. But there is a considerable flaw in Google’s approach that in my view breaks privacy laws. That is, even when a visitor explicitly selects “No” to being tracked, Google deliberately continues to collect data. In this post I explain what is going on.
The Mechanics of Gaining Consent
It’s important to note that Google Consent Mode is not a Consent management platform (CMP). Examples of a CMP include Cookiebot, OneTrust etc. These are tools that show a banner when a visitor first arrives at a site. They collect and save a visitor’s consent choice by providing the mechanism for explaining what different data collection technologies are used (e.g. cookies), providing opt-in/out choices, saving these and enabling the visitor to change their mind and edit their consent choices later if they wish.
However, these are just saved choices. What happens next is determined by you (the data controller/processor) and how you integrate the CMP with the data collection tools you have e.g. Google Analytics, Facebook pixels, Hotjar pixels et al.
For the purposes of this post, I am going to illustrate the set up you need to be aware of using Google Analytics implemented via GTM.
How Google Consent Mode Works
The ability to use Google consent mode is implemented in all GTM tags – even custom HTML. You access this under the tags Advanced Settings > Consent Settings. That said, the tag you use must be “consent aware” in order to do anything with these settings. As you would expect, Google has four such products: Analytics, Ads, Floodlight and Conversion Linker.
This is what a default Google consent mode looks like for a Universal Analytics tag in GTM:
The Consent Settings section shows the Built-in Consent checks. These inform you of what consent settings are used by the Google tag. In this case
analytics_storage. Note, the built-in checks cannot be modified.
The prevailing advice from Google and CMPs, is to keep the default settings shown above. That is, the logic of what data to send and when is determined by Google. As I explain in the next section, that is not good enough and leaves you exposed to a serious privacy breach. Here is an example of what I mean from Cookiebot’s documentation:
Google “Ghost” Hits Break Privacy Laws
This is the major concern of mine: With only the default settings of consent mode in place, Google will continue to collect data when a visitor has explicitly stated no to tracking. Remarkably, this is quite transparent from Google – see the official documentation. Their rational is to collect “anonymised” data from your non-consenting visitors so that they can model the impact of non-consent. The irony!
Note the data collected from non-consenting visitors does not go into your Google Analytics account – it is for “Google eyes” only. The data hit sent is almost identical to a regular Google Analytics hit, but with the following anonymisation process (from the official documentation):
What this means:
- If a generated hit does NOT have consent, it is still sent to Google corp. – not to the Google Analytics account. This is the “ghost” hit, and its URL appears very similar to a regular Google Analytics data it. Without consent it cannot access the
_gacookie and instead a unique random CID is generated for it. When/if consent is granted, access to the
_gacookie is restored.
- However by examining the URL it is trivial to see that Google’s ghost hits STILL contain the visitor’s
transaction_id(if collected), and the visitors IP address is transmitted to Google servers. Collecting, storing and processing such data when the visitor has explicitly stated no to this, would surely be considered illegal in any jurisdiction.
You can identify a Google Analytics “ghost” hit by viewing the network requests in your browser. Load a page that uses consent mode with only the built-in settings configured for a Universal Analytics tag. Without providing any consent, use your browser developer tools and observe the ghost hits – they appear very similar to the regular looking Google Analytics network requests, except having a
gcs=100 query parameter appended. The two 0’s correspond to no consent given for
analytics_storage respectively. Oddly, nothing gets exposed in the dataLayer.
If consent is granted for both checks, the parameter would be a
No consent = No tracking, right?
Within the context of GDPR/ePR, there is a citizen’s right to privacy written into the EU Charter of Fundamental Rights (Article 7). Applying this to a website collecting visitor data, this is generally accepted to mean that the website controller needs to ask its visitors for explicit consent before collecting personal data. I summarise what is personal data as meaning any data that can directly or indirectly identify the individual. The key term here is indirectly identify. That is, given enough “anonymous” data points, any individual can be identified – it’s known as the jigsaw effect.
Note, this does not mean all data collection is forbidden without an annoying pop-up banner requesting consent. Any data point or cookie that you can reasonably justify as “strictly necessary” for the functioning of your site/app, does not require consent. That is, there is such as thing as benign analytics that does not require consent, but sending data to a “mass aggregator” such as Google, does not count as benign. See my Planet49 article on LinkedIn for further thought on this.
Hence, I cannot see any way of defining the ghost hits from consent mode as being strictly necessary. They contain plenty of personal identifiers and these are specifically for Google’s eyes only – it is a trivial matter for Google to stitch together these hits to identify individuals.
Therefore to be privacy compliant for laws such as GDPR/ePR, you need to actively block the Google ghost hits. In fact, Google should make this an opt-in feature by default i.e. not active unless specifically set up. At present you need to opt-out.
The Fix: Block the Google Ghost Hits
In order to stop Google Consent mode collecting data when it should not, you need to enforce this setting: “Require additional consent for tag to fire” on every Google Analytics tag (Note this cannot be done in the settings variable), as follows:
What this does:
- Require additional consent allows you to force the Built-in checks to only be evaluated if these are explicitly set to true. Google’s documentation is quite poor on this, but all you need to do is add the same check names as the built-in checks. Then the built-in checks will only be used if these are explicitly set by the visitor i.e. consented. If required, this setting can also be used to add different consent requirements – for example you wanted
personalization_storageto be evaluated as true for the tag to fire.
To double emphasise my recommendation…
The built-in checks highlight what checks the tag uses – how they are used is determined by Google and that means “ghost” hits are still sent without your visitors consent. Built-in checks can not be edited i.e. you cannot add or remove these.
To override Google’s behaviour and block the ghost hits, you must force every GA tag to require explicit consent before any data is sent. You do this using the Require additional consent settings.
Note, consent management platforms such, as Cookiebot and OneTrust, do not block Google’s ghost hits for you – they simply work with the Built-in consent variables (though I have urged them to changed this). If you are using one of these tools, ensure you understand your set up and how it works with Google Consent Mode.
“People seem to think consent mode is somehow a compliance solution for making sure data processing adheres to some laws and regulations. It’s not. ” – Simo Ahava, 8-bit Sheep.
Conclusions – Consent is not about technology
If a visitor explicitly states they do not want to be tracked or have their data processed (beyond the category of “strictly necessary” for the functioning of the site/app), and you as the data processor ignore that request and continue to collect/process the visitor’s data regardless, you have just deliberately broken GDPR/ePD laws. In fact, most likely any privacy law regardless of jurisdiction.
An explicit no means no, yet Google’ s consent mode is extremely flawed in this regard.
The approach that Google has adopted with consent mode is that it is legitimate for them to collect data without consent, so long as no cookie is set – but it’s for Google eyes only. That is, the data collected via the Google tags, is not shared with the Google Analytics user. But consent is not about the technology used i.e. whether a cookie is set not, its about the right to privacy. Google’s whole approach simply smells bad.
Fortunately, the fix is relatively straightforward – just poorly documented and a non-intuitive. That said, consent management platforms such as Cookiebot and OneTrust are not exactly helping in this regard. They should be on the side of protecting the visitor until explicit consent is given, but they are not. Whether this is due to the poor documentation from Google, or lack of willingness for them to go against Google, I do not know. In my view, such tools should be taking the lead when it comes to protecting the privacy of users and blocking any ghost hits.