Questions and answers from the webinar “What you need to know about Consent Mode v2” on the ProstoDoKasy by Satisfly channel:
This article concerns rapidly changing technology and legal regulations and is not updated on an ongoing basis (last update: 26 February 2024). In particular, legal matters should be treated as illustrative and verified each time with a lawyer or Data Protection Officer.
In connection with activating Consent Mode v2 (advanced implementation), do I need to make any changes to my privacy policy? If so, could I get information on what and to what extent?
This is a question better addressed to a lawyer or Data Protection Officer. That said, the changes in v2 are very minor, so if someone already had Consent Mode in place, then in my opinion no changes are required after moving from “v1” to v2.
Consent Mode (advanced) itself, however, involves processing certain limited data for analytics purposes (including analyzing ad performance) without the user’s consent.
This is a small part of the data collected with consent, and the way it is processed includes anonymization of that data and limits, or even practically prevents, identification of the user. So the scope of the data processed does not change, but some data is processed without consent.
It’s also worth noting that the data processed under Consent Mode does not exceed the data collected “normally” in a server log, which is done to observe how the site works, create statistics, and identify errors and security breach attempts. In other words, this is data we collect anyway and that is generally assumed not to require consent. Even the Polish DPA (UODO) does this — see uodo.gov.pl/privacy-policy.
The main purpose of Consent Mode is to estimate the impact of consent refusals on the reliability of statistics obtained from measuring the behavior of users who gave consent, and to extrapolate that data so that it reflects — approximately, but closer to reality — the activity of users coming from different sources and using different devices.
Assessing to what extent this information should additionally be included in the privacy policy is a question for a lawyer. For my part, I can say that while adding information never hurts, it’s also worth making sure the privacy policy stays concise, clear, and understandable for the user.
In the privacy policy, do we have to list in detail all cookies with their descriptions, or is it enough to describe the categories of cookies used?
Describing the cookies is good practice. CMP platforms usually make this possible through an automatically generated cookie declaration, such as the one at the bottom of this page adequate.digital/privacy-policy — you paste in the appropriate code and the CMP generates it.
Most generally, the user should be informed how the data is processed and by whom — to my knowledge the minimum is indicating the companies to which the data is passed. Again, this is a question for a lawyer or Data Protection Officer.
It’s also worth noting that even without this declaration in the privacy policy, the user can review the details of the cookies by re-opening the platform’s widget — the same one they could review when giving consent. The declaration simply has a different graphical form.
If I don’t have any cookies on my site, do I still have to show a banner?
If the site doesn’t use cookies or other similar technologies (e.g. identifiers stored in the browser’s memory, etc.), then no banner is needed.
This is the case with bakoma.pl, which uses no cookies and has no banner.
If I’ve had my consent setup in place for a long time, is it possible that it’s no longer up to date, or that something “broke” and it doesn’t work correctly?
Consent Mode v2 requires changes in the consent management system. They are minor and sometimes simply take the form of a software update, but they are necessary. So at the very least, that needs checking.
As a rule, though, if nothing changes on the site, the CMP should keep working.
In practice, however, many different things can happen: someone may add a new tracking code, someone may plug a new add-on into the platform, someone may embed content on the site and not make the corresponding changes in the consent management system at the same time.
Some CMPs do have automatic script blocking, which largely protects us against such cases, but either way it’s worth checking from time to time whether the system still works correctly.
How often should consent be renewed?
This is also one of those questions better directed to a lawyer or DPO.
It’s usually a period in the range of 6-12 months. There are no clear-cut regulations here, but above all you shouldn’t persistently ask for consent, while on the other hand consent shouldn’t last too long, because the technology, the nature of the processing, etc. may have changed. For example, the Irish data protection regulator considers that it should be 6 months (both the validity of consent and the time after which we can ask for consent again).
If a site has completely changed its character, new tracking scripts have been introduced, etc. — purists would probably consider it justified to immediately invalidate all consents (because the current data processing is not what the user agreed to). CMPs usually offer such a function. If you do this, every user will be asked for consent again on their next visit.
If I disable the Google Analytics tag in GTM, is that enough to stop tracking users?
I’m not sure I understood the question correctly. Google Analytics is just one of the tags that can track a user.
How do I implement consent on a site completely from scratch?
The recommended method is to use one of the CMP platforms recommended by Google together with Google Tag Manager (GTM).
Roughly, the process looks like this. We install the CMP and place all tracking codes in GTM. We install the CMP tag from the template integrating the CMP platform with GTM, and then set the appropriate consent conditions for each tracking tag (“require additional consent”).
For Google tags in Advanced Consent Mode, we choose the “no additional consent required” option, because these tags will use the consent status sent from the CMP and fire in the appropriate mode. Installation instructions can be found in the documentation of the given CMP platform.
In Basic Consent Mode, Google tags in GTM should also be conditioned on additional consent.
There are also many guides online on installing a CMP and Consent Mode.
I’d like to emphasize that platforms outside Google’s recommended list are permissible and many of them certainly also support Consent Mode v2; however, it’s hard for me — without the support of reliable external verification — to recommend solutions whose operation I don’t know.
This doesn’t mean it’s the only and always simplest way to implement consent management. The above implementation method is, in my opinion, the most universal and should work in most cases.
How do I implement Google’s Consent Mode v2 if some e-commerce data (sales, add to cart, etc.) is sent via the Measurement Protocol, while everything else — Hotjar, Google Ads, etc. — is implemented through GTM? Which solution is correct? Will the CMP handle it?
Generally, it’s worth asking yourself whether it really makes sense for e-commerce data to be sent via the Measurement Protocol, especially events like add to cart. As a rule, what happens on the website should rather be reported from the site, and the Measurement Protocol should be used rather for offline events or generally events occurring outside the website.
If we have user consent configured correctly, then in case of refusal the collected data won’t use the user identifier, so there will be no way for data sent to Analytics via the Measurement Protocol to relate to a specific user. In that sense the CMP will “handle” it and no unauthorized processing of personal data will occur.
Recently the ability to pass consent status via the Measurement Protocol was officially introduced: developers.google.com/protocol. Nevertheless, by default Google Analytics will use the consent settings received earlier from the user associated with a given identifier.
So retrieving the consent status collected on the site solely in order to re-enter it in a Measurement Protocol event makes no sense, because it will be the same as the default (and there’s even a small chance that it would make it less up to date).
These variables apply to situations in which the consent status could change between the visit to the site and the conversion — e.g. the user, when signing a contract, gave the appropriate marketing consent and we want to include it in the Measurement Protocol conversion event.
In Google’s Measurement Protocol documentation, only advertising consent is mentioned, because without analytics consent we won’t be able to use the user identifier (because it won’t exist).
The question remains what to do when we don’t have analytics consent. In theory we can generate a random identifier ourselves (similarly to how it’s done in Consent Mode) and use such a Measurement Protocol event. Of course, such a conversion wouldn’t be linked to any user (Analytics wouldn’t be able to identify its source). There is no clear answer to this in the documentation, but PERHAPS (YOU CAN TRY) in such cases adding the parameters gcs=G100&gcd=13q3q3q3q5 to indicate that this is data without consent. Thanks to this Google PROBABLY could use it for modeling (it would be a ping like the one from the site in the case of Consent Mode). I’ll stress that this is not an officially supported solution. We’ll have to wait until Google officially comments on this.
So if I don’t click anything — neither consent nor refusal — I understand that no data is collected?
That’s how it should work. Until consent is given, it should be assumed that there is no consent (the opt-in principle).
How do I measure the number of people who refuse cookies?
Most CMP platforms provide such statistics.
Can Microsoft (and e.g. Bing) have its own Consent Mode that differs from Google’s Consent Mode v2?
Currently Microsoft and Meta have their own consent mode. As of today (February 2024), however, they work in such a way that in case of no consent the data is not sent, so there is no difference between simply firing these tags only after consent without those parameters.
So in GTM you can define these tags so that, depending on the consent status, they are fired appropriately too. As of today this changes nothing in the way of processing.
It’s not out of the question — indeed it’s likely — that this will change in the future and the other tech companies will apply solutions analogous to Google’s and will require consent status to be sent with every tag call.
Guides say analytics tags should be in Google Tag Manager (but we have them via a plugin). What are the solutions on PrestaShop in this situation?
It seems that if the plugin and platform don’t natively support consent management and the CMP, or it doesn’t work correctly, the simplest and universal solution will (after all) be to move the Analytics code into Google Tag Manager.
Does no consent mean that some data will be passed to Google anyway? Do we know exactly what? The IP?
Google declares that the IP is deleted after the user’s approximate location is determined. Google collects information about the pages visited, conversions, the user’s country, the time of day, the type of device (smartphone, computer), and the browser type. In this article I described roughly what data is used.
It’s worth remembering that this data is not processed in the context of tracking identifiers, but collectively for all users who did not give consent.
In Consent Mode v2, does gcd replace gcs? That is, when testing the solution, might gcs not show up?
As of today both parameters are sent. Remember that these parameters are generated by the Google tag itself based on the consent statuses. It’s worth knowing them only so you can easily check whether Consent Mode is working correctly. We don’t insert these parameters directly anywhere ourselves, nor does the CMP.
It’s possible that one day Google will decide that gcs is redundant, because all the needed information is in gcd, and then the Google tag will stop sending it — but that would be a change solely on the Google tag side.
Do you know whether the ad_personalization flag should be sent via the API for Import from Clicks or for Enhanced Conversions, or are these services only within the scope of the ad_user_data flag?
I don’t fully understand the context of the question, but perhaps this explains it: developers.google.com/consent.
The ad_personalization flag is for Customer Match; ad_user_data is for Enhanced Conversions and Import from Clicks.
If we don’t implement Consent Mode at all, will GA4 by default start treating the absence of gcs/gcd parameters as no consent? And should we therefore expect GA4 to stop collecting data altogether?
The Consent Mode v2 requirement currently applies to Google Ads and generally to the use of data in Google advertising. Analytics will collect data normally, but it probably won’t be available for advertising (i.e. remarketing lists imported from Analytics won’t work, for example). At least for now, Google is not announcing a block on Analytics itself.
Let’s remember, however, that in Analytics it is we (the site owner) who are the data controller, and Google is only the processor — it provides the analytics software and maintains it on its servers. That’s why collecting the legally required consent (not necessarily in Consent Mode) is the site owner’s legal obligation, especially since in Analytics we can process pseudonymized first-party personal data, such as a User ID or a transaction ID.
We have a store on Atomstore and some tags are implemented directly by the store platform, and some (for which we didn’t have ready integrations) via GTM. When implementing Consent Mode 2.0, do all tags need to be moved to GTM for it to work correctly?
That’s probably a question for Atomstore, but from what I can see, Atomstore offers native integration with both Analytics and GTM and Consent Mode — we can only hope it works (we haven’t tested it).
We recommend working with a CMP and GTM as universal, but it’s not the only possible solution.
In Advanced Consent Mode, Google gains access without consent to information such as the IP address or device info — which, as I understand it, also falls under ePrivacy. So does the so-called “Advanced Implementation” actually let us stay compliant with ePrivacy, or rather with its Polish implementation? Or should we rather use the so-called “Basic Implementation”?
Again, this is a question for a lawyer and DPO. In the presentation I pointed to the related doubts and, indeed, the IP address is at least controversial here.
Google declares that the IP is deleted after the approximate location is determined, which doesn’t change the fact that it is transmitted and read. It’s possible to process the IP address on the server side and send only location information to Google, but that is also processing of the IP and usually also takes place on a server hosted by… Google or another hosting company. In my opinion this doesn’t differ significantly from processing on the Google Analytics side, apart from greater control over the data.
Of course, the basic implementation (Basic Consent Mode) doesn’t raise such doubts. Personally, I’m waiting for the regulators to comment on this.
What could the consequences be if, from the start — i.e. in consent default — we set analytics_storage to granted?
It’s hard for me to say what the consequences will be, but this generally won’t be correct (certainly not on the first visit to the site). Google will receive the information that we have consent by default. I can only speculate that this might raise their suspicion that we’re misleading them by stating we have consent when we don’t yet.
Default consent status of granted — is it really incorrect? If we have a situation where the user consented, refreshed the page, so we have consent info = granted. Logically, the default in that case could be granted.
This is normally implemented so that on every page the default status is denied, and then, based on the consent information (from the CMP cookie), an update is performed.
Yes, in one of the instructional videos Google shows that once we already have consent, the default status should be consent — i.e. to generate the default consent state based on the currently held consent:
Nevertheless, the current documentation on this clearly states that the default status is denied on every page: developers.google.com/consentmode.
Performance considerations also argue for this. Checking the consent state for the default state requires reading a value in a cookie, which is an additional page delay. There’s also the question of why an update would then be done at all, if the consent state has already been checked.
In summary, the correct solution is always default = denied, followed by an update.
I have a small / simple site built in a ready-made tool like Wix or Carrd. How do I add Consent Mode there?
You can check in the given platform’s help whether it natively supports consent management and Consent Mode, either natively or through plugins. More and more platforms offer this — but it’s hard for me to comment on specific solutions.
Generally, a universal solution will be adding Google Tag Manager to the site and using a CMP, which can also be implemented using GTM itself.
So if I don’t use GA on the site and don’t use Google ads, I don’t need a CMP on the site — e.g. on a simple blog?
If the site uses only cookies necessary for its functioning, no consents are needed.
An example is uodo.gov.pl, which uses only first-party cookies necessary for its functioning. They are merely described in the privacy policy: uodo.gov.pl/privacy-policy
So the question is which cookies a given site uses, because consent doesn’t concern only Google tags.
You can check this in the browser under Developer Tools > Application > Cookies.
You can also use cookie scanners available online and often offered by browsers, which will scan more pages on your site — because it may turn out that some of them have scripts that aren’t on, say, the home page, and these will be responsible for cookies that aren’t necessary and require consent. This can happen, for example, in the case of embedded content (e.g. a YouTube video built into the page).
Do the developer tools return all cookies present on the site? A cookie scanner from external tools identified more cookies for me than this tool does.
A scanner usually visits more pages than just the home page, so it’s possible that some subpages somewhere set other cookies. The developer tools, on the other hand, are a “first-hand” source.
When implementing the currently required Consent Management, can the referrer be lost (causing an increase in traffic attributed to direct)?
Some implementations cause the page to refresh after the update, and if this isn’t supplemented by passing the referrer, such an effect can occur. To my knowledge, such an implementation (with a page refresh) is incorrect anyway.
We do, however, observe a problem with “not set” in session sources in Analytics, which results from the fact that after the Consent update no session start is generated, which is responsible for the session source. To my knowledge Google is working on solving this problem, because it’s solely due to data processing by Analytics. As a stopgap you can try to reduce this effect by manipulating the timing of the script firing, but that in turn creates a risk of losing some data. So it’s a “hack” that may prove redundant after a while and work to our disadvantage, and it’s a solution for very advanced administrators who monitor the situation on an ongoing basis.
Is the way of triggering the consent-change window (that floating button in the corner) required in that form, or can it be, for example, removed and replaced with a link to change consents in the site footer?
You can, and I personally even recommend it. A negligible percentage of users change their consent, and this widget, in my opinion, only gets in the way of using the site. Placing a link in a visible and easily accessible spot* in the footer makes it no harder to change consent if someone wishes to. But in a specific case, that’s again a question for a DPO/lawyer.
*) e.g. a footer that doesn’t “run away” as you scroll or that requires long scrolling.
What if we have Advanced Consent Mode implemented but don’t meet the traffic requirements/thresholds for modeling? Will modeling not work, or will it work more like Basic Consent Mode?
There simply won’t be any modeled data; only the data of the users who gave consent will be reported.
I wouldn’t compare it to Basic Consent Mode, because there modeling does take place in Google Ads and is based on comparing the number of ad clicks with the number of visits with consent.
Is there an open-source alternative to commercial CMPs?
I’d rather not comment on this. The problem with such solutions is that I can’t be sure they’re compliant with Consent Mode, and even if they are compliant today, it may turn out that the creators of that software won’t provide an update at the next technology change.
This doesn’t mean open-source solutions can’t be great, but in the case of commercial platforms certified by Google, the risk of non-compliance or discontinued updates is much lower.
In GTM, in the Community Template Gallery I see only two templates. On your slide there were far more. Any idea why I see only two? Are templates imported from outside?
I think it’s a matter of the search term used: tagmanager.google.com/?q=consent.
Generally you should search for the template of the CMP platform you chose for consent management, using its name as the keyword. I deliberately used the word consent, because I don’t want to favor a specific CMP.
For Meta, TikTok, etc. tracking codes in GTM, do you need to set up additional consent checking?
Google isn’t interested in this, but from a legal point of view we have to collect consents for the use of these codes, and taking that into account, you should choose the “requires additional consent” option. It must be consent appropriate for these tags (generally, for Meta and TikTok this is marketing), and these tags should be fired on the consent update event.
Shouldn’t we place googlesyndication in the “Necessary” category? For example, Cookiebot, which I see on adequate, scans for cookies and trackers.
Advertising cookies are not necessary. To be honest, I don’t know which cookies are meant (see adequate.digital/privacy-policy), but “googlesyndication” refers to Google’s ad network.
I updated Consent Mode with Google technical support, but I admit I have some doubts. We had it correctly implemented via Cookiebot with integration through the official Cookiebot CMP-to-GTM connection, and we were only missing those new two tags to bring it up to version 2.0. Technical support suggested I disable the data in that Cookiebot plugin and implement it through some other one, going around. From what I understood from that training, all I needed was to update the Cookiebot CMP. Is it possible that Google technical support didn’t know this?
It’s hard for me to comment on this specific situation. In the case of Cookiebot CMP with GTM, updating the GTM integration template is usually enough.
In some cases, if updating the template alone doesn’t work, you need to remove the Cookiebot tag from GTM and add it again — that should help.
In some implementations (depending on how you did it), the Consent default script is placed in the site code, and then you also need to add these two variables in that code: ‘ad_personalization’: ‘denied’ and ‘analytics_storage’: ‘denied’.
Does the cookie banner have to be set up in a form that blocks access to the site, or can it be, say, in the corner of the screen so the user can normally browse the site, add to cart, etc. even without giving/refusing consent? In particular, if we have consent set to “granted” by default, then until the user clicks “no consent” on the banner, everything will be collected. This is a version tested with the Google team and supposedly everything is fine, because when the user doesn’t give consent the parameters are sent correctly.
Until consent is given, we must assume there is none. The user can use the site without consent, but then it can happen that they give consent somewhere in the middle, and then we may have distorted landing-page statistics in Analytics. Personally, I rather recommend expecting consent/refusal right at the entrance.
In my experience this doesn’t negatively affect the consent rate, and in some cases it even improves the conversion rate — probably because the consent widget trailing after the user covers part of the screen and worsens the UX.
A default status of “granted” during the user’s first visit is definitely wrong and is not properly collected consent. The opt-in principle applies, not opt-out. Technically it can of course work, but it’s not a correct implementation and may cause “full” Analytics to run without consent.
Finally: how does sending data via the Customer Match API relate to consent given through the CMP? If I’m not mistaken, in the latest version of the API for Customer Match you have to pass the consent status. How do you pass the consent status for the uploaded list?
We pass the consent status via the API, see: developers.google.com/customer-match.
Whether consent given in the CMP can be sufficient for Customer Match is a question for a lawyer/DPO.
As a rule, if the user consents to the use of identifiers (cookies and similar technologies) for advertising purposes, then a hash of the email is also such an identifier (I once discussed this topic with attorney Agnieszka Grzesiek-Kasperczyk in the context of Enhanced Conversions). This way you could consider passing such consent from the website to the CRM when acquiring the user’s email and phone number, and using it to build a customer list.
You can also limit Customer Match to only those customers who consented to the use of their email for this purpose by ticking a consent checkbox already on the site, e.g. at the transaction. This should presumably be a separate checkbox, because a user may want to receive emails but may not want to see our store’s ads everywhere.
All these matters should be agreed with your lawyer / DPO or you should seek additional legal advice.
