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.
Great article Brian. I wish more people knew about it. I included a link to this information in my WordPress plugin (WP Full Picture – there’s a free one in the WP repo) and hopefully, people will click it and learn what the consent mode actually does, before blindly enabling it.
Nice looking plugin Krzysztof. Looks very thorough.
Great article Bian, thank you for getting this consent mechanics clear.
Just as an update on Italian interpretation, the Italian SA yesterday has taken a firm position where they “bans use of Google Analytics”. Is mainly based on “No adequate safeguards for data transfers to the USA” and “an IP address is a personal data and would not be anonymised even if it were truncated – given Google’s capabilities to enrich such data through additional information it holds.”
It would be interesting to know whet do you think Brian. Thanks
Here’s the source (scroll for eneglish version) https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/9782874
Agreed, but we are talking about two different things. Google Consent mode is not a GA feature, rather a separate mechanism from Google that allows implementers to control if, and when, a tracking pixel fires. However, as I show, it continues to collect data even when the visitor has explicitly says “no” to tracking.
Data transfer/Shrems II/FISA 702 issues that U.S. companies are currently facing from the EU is a separate discussion – though still relevant. My summary of that is here: https://brianclifton.com/blog/2022/02/18/google-analytics-gdpr-austria-schrems/. Feel free to add your thoughts there.
Related – looking under the hood of GTM’s consent checks: https://gtm-gear.com/posts/gtm-consent-settings-built-in-consent-checks/
Thanks Brian for bringing this out clearly (Simo Ahava tweeted that some days ago). My concerning is that, if we’re required to force this additional controls, Consent Mode is quite useless. Its power was to use ghost hits for data-modeling. If we completely stop tags to fire (as we did before Consent Mode release), this important feature is blocked. At this way, let’s completely drop Consent Mode and work directly with CMP with its blocking triggers, as we’ve always done.
Exactly my point Riccardo. The only entity that one could say has a necessary and legitimate “right” to collect a count of opt-out visitors, is the entity delivering the consent banner. That could be you and/or your CMP. However I would say care is needed to ensure that apart from the count, only a minimal set of aggregate data is collected or can be associated with the opted-out visitor e.g. general browser settings, such as language.
yes, Simo and I chat about these issues offline 😉
Got your point but, with my clients at this moment (at least), I keep Consent Mode active without forcing additional controls. In Italy we’re used to consider anonymous Analytics data as technical and not requiring consent. Consent Mode brings pseudo-anonymization to the ghost hits, and unless User ID is collected, is enough for me.
I understand what you are saying, though I would strongly encourage you to get legal advise on that approach. I am pretty sure it is *not legal* according to EU law…
GDPR has different interpretations among the EU countries. Last year, the Italian privacy-regulator has confirmed Analytics hits can be legitimately sent without consent if all the anonymization features are applied (no data can be used to personal identification). As the ghost hits in Consent Mode include no kind of this data (no IP, no User ID, no client ID..) and so no personal identification or aggregation can be done, should be fine.
For Google Consent Mode the IP address of the user is sent with the data hit, along with other finger print data points such as user-id and transaction-id. Also this data is sent to Google themselves, not to the website owner’s analytics account. The website owner does not see this data.
Please note that DPA’s don’t actually define EU laws.
That said, I have long argued for “benign analytics” – for example see this LinkedIn article from 2019. Also, CNIL explicitly allows benign analytics and lists approved tools. However, *not* when the collector is a global data aggregator, such as Google. This is because Google can stitch together “anonymised” data to re-identify the user – that’s the jigsaw effect (I write about jigsaws a lot!). So I cannot see how any regulator can say GA data can be anonymised.
When it comes to consent, the relevant law is ePrivacy directive, rather than GDPR. It came into effect in 2002. It is hideously out of date and problematic, but that is where we are. It’s why I feel CNIL and others have a more pragmatic approach.