Consent Mode v2: What It Actually Is and How to Set It Up

A cookie banner and Consent Mode v2 are not the same thing

A cookie banner asks a visitor for permission. Consent Mode v2 is how that permission gets communicated to Google, before a tag like Google Analytics or Google Ads ever receives a single data point. They sit at different levels: you can have a banner that is perfectly GDPR-compliant and a Consent Mode setup that is still wrong, because the banner is a user interface while Consent Mode is a protocol between your site and Google's tags, made of signals with a specific name and a specific order in which they need to be set.

Since version 2, mandatory for anyone in Europe running Google tags against an audience subject to GDPR, the signals are no longer two but six: ad_storage and analytics_storage already existed in v1, and ad_user_data (permission to send personal data to Google for advertising) and ad_personalization (permission to use it for ad personalization) were added, while in practice almost every real implementation also handles functionality_storage and personalization_storage for the site's own preferences. A seventh signal, security_storage, stays granted at all times, since it covers technical security cookies, not tracking.

Order matters more than content: the default has to arrive before the tag

The most common mistake is not in the values chosen but in the sequence. A Google tag (GTM, gtag.js) that loads before the site has declared a consent default behaves as though no consent framework exists at all, which is the most permissive state for it. A properly built Consent Mode v2 setup always follows the same pattern, in this order:

• As soon as the document starts loading, before any third-party script, a denied default is declared for every tracking signal (denied on marketing and statistics, granted only on security_storage), with a short grace window (500 milliseconds in our own implementation) that gives a previously stored choice time to be re-read before a tag can fire with the wrong values.
• If the visitor already chose something on an earlier visit, that choice is read back from the consent cookie and immediately pushed to Google as a consent update command, still before GTM or gtag.js are actually requested from Google's servers.
• Only at that point, with the consent context already declared, do GTM, a direct Google Analytics 4 tag (if you are not routing it through GTM), and any third-party pixel such as Meta's get loaded, and the pixel itself still needs its own separate consent call, not a plain "if the cookie says yes, load the script".

Setting the default in the right spot in the code is a three-line job. Setting it in the wrong spot, say inside the same block that loads GTM instead of before it, defeats the entire mechanism: Google still sees the tag arrive before the signal does.

The banner alone blocks nothing: you need a generic blocker too

A practical gap Consent Mode v2 does not close by itself is that it only covers Google's own tags, not the other third-party scripts a theme or another module may have dropped onto the page (an embedded map, a review widget, a video). A serious implementation adds an independent layer that watches the DOM as the page builds itself, recognizes a script or iframe against a list of domain patterns (for example google-analytics.com, facebook.net, doubleclick.net, or a video service's domain), and, if the category it belongs to has not been accepted yet, swaps it for an inert placeholder before it manages even a single network request. Only once the visitor accepts that category does the real script get put back. Without this layer, a denied default only covers the tags the site itself wrote to respect it, not the ones shipped inside third-party modules that ignore your Consent Mode and fire anyway.

A real case: a technically correct default, a banner nobody could read

In our own consent module we found an instructive defect on September 14, 2026: the Consent Mode mechanism itself was correct, the denied default fired at the right point, and yet the banner's text (title, body, the three buttons, the category names) came out in English for anyone browsing a store in French, Spanish or German, while Italian and English were fine. The cause was not a missing translation in PrestaShop's own string catalog: the banner text was written directly in the module's code, in an array that only covered two languages, and for any other language the code silently fell back to English. We fixed it by adding the three missing language blocks (French, Spanish, German, 17 strings each, with real accented characters rather than plain apostrophes) and shipped version 1.0.9.

This is not just cosmetic. Consent collected while showing text the visitor cannot read is weak consent: GDPR's own requirement is that the notice be understandable to the person reading it, not just technically present on the page. A Consent Mode setup that is flawless at the code level does not count for much if the person standing in front of the banner is reading a language they do not speak.

A practical checklist to verify your own setup

• Open the homepage's page source, actual "view source", not the dev tools, and check that gtag("consent","default",...) appears before any Google Tag Manager or gtag.js tag in the document, not after it.
• Verify all six signals are present in the default, not just the ad_storage and analytics_storage inherited from Consent Mode v1: missing ad_user_data or ad_personalization is the most common mistake in setups that were "upgraded" in name only.
• Check, with the browser's network tools, that a script like Google Analytics does not actually fire before consent is given: a denied default has to translate into zero network requests to that domain, not just a declared and ignored signal.
• Switch the store's language and look at the banner again: text that only got translated halfway is as common a defect as it is invisible to whoever published it, since it is almost always checked in the language the team actually works in.

In short

Consent Mode v2 is not a checkbox in a cookie module's settings panel: it is a precise sequence of signals, where the order matters as much as the content, and a blocking layer that has to cover scripts the site itself never wrote. A technically correct implementation can still miss its own point if the text accompanying the consent request never actually reaches the person who needs to read it, in their language. Dedicated modules exist for PrestaShop, including a free one in our own catalog (cll_consent), but the sequence described above holds regardless of which module ends up implementing it.

Module installation and configuration guide

Cookie Consent & Google Consent Mode v2Free module: download and install it right away. GDPR cookie banner with granular categories, Google Consent…View product