Since March 2024, Google has required Consent Mode v2 for any site that wants to retain access to GA4 and Google Ads data for European users. In 2026, many PrestaShop stores are still running with a poorly understood configuration — either on forgotten Consent Mode v1, or on a badly wired v2, or worse, with no Consent Mode at all. The result is invariably the same: partial GA4 data, Google Ads audiences that no longer fill up, and a GDPR compliance risk that data protection authorities have taken increasingly seriously since their 2024–2025 sanctions.
This guide covers the complete Consent Mode v2 configuration on PrestaShop 8: what changed from v1, the technical stack to put in place (CMP + Google Tag Manager + GA4), typical errors seen in audits, and how to verify everything actually works before considering the topic closed.
What Consent Mode v2 changes concretely versus v1
Consent Mode v1 (launched in 2020) managed two consent parameters: ad_storage and analytics_storage. That was enough to differentiate analytics tracking from advertising tracking, and regulators accepted the approach.
Consent Mode v2 (March 2024) adds two additional parameters:
ad_user_data— authorisation to send user data to Google for advertising purposes (e.g. hashed email for Customer Match). Without this, your custom Google Ads audiences stop filling up.ad_personalization— authorisation to use that data for personalised advertising (remarketing, lookalike audiences, etc.). Without this, your remarketing campaigns run blind.
To keep full Google Ads functionality, both new parameters must be set explicitly in addition to the two legacy ones. If you don’t, Google considers you haven’t migrated and progressively blocks the most data-dependent features (Customer Match, advanced audiences, dynamic remarketing).
The other major change is the distinction between Basic Consent Mode and Advanced Consent Mode. In basic mode, if a user declines cookies, no Google tags fire at all — you lose 100% of that visitor’s data. In advanced mode, Google tags still fire but in “cookieless” mode (sending anonymous pings), and Google then uses statistical modelling to fill in the gaps for users who declined. Significantly more powerful, but more complex to implement — and this is where most configurations go wrong.
Last point: Consent Mode v2 must be declared before any other Google tag on the page (GA4, Google Ads, Floodlight, etc.). If the order isn’t respected, the first events fire without a consent state and your GDPR compliance is broken. This is the most frequent error we see in audits.
The stack to set up on PrestaShop 8
A clean configuration relies on three components that must work together.
A CMP (Consent Management Platform). This is the cookie banner visitors see, which collects their choice and exposes it technically to other scripts on the page. On PrestaShop 8, several options exist: tarteaucitron (free, French, IAB TCF not required for non-publisher sites), Axeptio or Didomi (IAB TCF v2.2 CMPs for those who need the advertising framework), or solutions integrated in dedicated modules.
Google Tag Manager. The central hub orchestrating your tags. Without GTM, managing Consent Mode v2 directly in PrestaShop code is feasible but becomes unmanageable once you add Google Ads, Meta Pixel, TikTok Pixel and other trackers. GTM centralises the logic and allows conditioning each tag to the current consent state.
GA4 and Google Ads destinations. Downstream, these are the destinations consuming the consent information. GA4 and Google Ads automatically read Consent Mode parameters when correctly set via GTM or direct tags.
On PrestaShop 8 specifically, the challenge is that these components come from different modules that don’t communicate by default. Without coordination, your CMP does its job, GTM does its, and GA4 collects everything or nothing depending on loading order chance. A dedicated module managing the complete chain is generally more reliable. That’s what the Google Tag Pro module does: complete GA4 and Google Ads enhanced ecommerce tracking, native Consent Mode v2, and compatibility with common CMPs (tarteaucitron, Axeptio, Didomi) via automatic detection.
GTM configuration with Consent State triggers
On the GTM side, configuration always follows the same sequence: initialise Consent Mode with a default “all denied” state, then fire a consent update event once the user has made their choice in the CMP.
Default configuration tag (fire first on all pages). This tag sets the Consent Mode defaults before any other tag:
gtag('consent', 'default', {
'ad_storage': 'denied',
'ad_user_data': 'denied',
'ad_personalization': 'denied',
'analytics_storage': 'denied',
'wait_for_update': 500
});The wait_for_update parameter tells Google to wait up to 500ms before sending the first pings — enough time for the CMP to determine the user’s choice (existing persistent cookie or new choice). This prevents duplicate pings that fire once in “all denied” mode then again after consent.
Update tag (fire after user choice). This tag updates values based on the choice expressed in the CMP:
gtag('consent', 'update', {
'ad_storage': 'granted',
'ad_user_data': 'granted',
'ad_personalization': 'granted',
'analytics_storage': 'granted'
});In GTM, this tag fires on a custom event (e.g. consent_granted) that the CMP pushes into the dataLayer after the user clicks “Accept all”. For granular choices, only the corresponding parameters switch to granted.
Verifying it all works: debugging with Google Tag Assistant
Once the configuration is in place, verification uses two Google tools.
Google Tag Assistant (https://tagassistant.google.com). Enter your store URL, the tool loads the page in a debug session and traces all outgoing events. For each event, you see the sent parameters including current Consent Mode states. The critical test: open Tag Assistant, run the complete purchase journey (homepage → product page → add to cart → checkout → payment), and verify all events fire with the correct states.
Before user consent, all events must fire with denied on all 4 parameters. After “Accept all” consent, all must switch to granted. If you see an event firing with an incoherent mix, or an event firing with granted before consent, your configuration is broken.
The GA4 “Consent states” report. Once the configuration has stabilised over a few days, go to GA4 > Administration > Diagnostics. The “Consent states” report shows the percentage of events received with granted vs denied consent. On a European store with a properly configured CMP, you should see 30–60% granted events (depending on your banner design). 100% granted means your CMP isn’t actually asking for consent. 0% granted means your Update tag never fires.
Typical errors seen in audit
In GDPR/Consent Mode audits of PrestaShop stores, these six errors recur constantly.
Error 1: Default tag fires after the GA4 tag. Consent Mode must be initialised first on the page, before GA4 or Google Ads loads. If the order isn’t respected, GA4 sends its first ping (page view) without a consent state. Solution: in GTM, set the Default tag with the “Initialization” trigger (fires before all other triggers).
Error 2: Update tag never fires. Classic symptom: all pings remain in denied even after the user clicks “Accept all”. Cause: the CMP doesn’t push the expected event into the dataLayer, or GTM listens for the wrong event name. Check in the console: type dataLayer and look for the consent event after clicking Accept.
Error 3: GTM blocked by the CMP itself (the paradox). Some poorly configured CMPs treat GTM as a third-party tracker to block before consent. Result: GTM doesn’t load, so Consent Mode is never initialised, so nothing works. The CMP must allow GTM to load before consent (GTM itself is neutral — it’s the tags it fires that depend on consent).
Error 4: Multi-module conflicts. Stores that have accumulated multiple tracking modules over the years (old GA Universal, native PrestaShop GA4, a GTM module, a Meta Pixel module) get tags short-circuiting each other. Solution: audit all active tracking modules and keep only one that orchestrates everything.
Error 5: no handling of user preference changes. When a user changes their mind and clicks “Edit my preferences” in the footer, the CMP must fire a new Update event passing the parameters to the new choice. Many setups handle the initial Accept event but not subsequent changes.
Error 6: Consent Mode v1 left alongside v2. Sites migrated from v1 to v2 sometimes keep the old tag by mistake. Both Consent Modes coexist and fight over parameters with unpredictable results. Solution: remove all Consent Mode v1 traces before setting up v2.
Statistical modelling: what you recover despite refusal
The big argument for Advanced Consent Mode is statistical modelling. When a user declines cookies, Google still sends anonymised pings (no identifier, no cookie), and its ML algorithms use these signals to estimate what would have happened if the user had accepted. In practice, your GA4 reports show modelled conversions in addition to observed ones.
Modelling only activates above minimum volume thresholds (around 1,000 events/day and 1,000 users without consent per day). Below that, GA4 shows raw data without modelling. For Google Ads campaigns, the benefit is more immediate and visible on reported ROAS — Advanced Consent Mode can recover 20–40% of “missed” conversions in reports, and more importantly, keeps Smart Bidding algorithms learning despite the decline in explicit consent.
Conclusion: a mandatory investment that demands rigour
Consent Mode v2 on PrestaShop is no longer optional in 2026. It’s a requirement both for GDPR compliance and for retaining full Google Ads functionality. The configuration isn’t extraordinarily complex, but demands rigour: precise trigger order, CMP/GTM/GA4 coordination, systematic verification with Tag Assistant.
For related topics, browse our PrestaShop tutorials or our e-commerce news. And for a complete GA4 and Google Ads tracking setup with native Consent Mode v2 and automatic CMP compatibility, the Google Tag Pro module implements the full chain on PrestaShop 8.