WooCommerce CRO Technique

How to set up Google Consent Mode v2 correctly on a WooCommerce store for EEA and UK traffic

This technique is about wiring a real consent management platform (CMP) into Google Tag Manager on WooCommerce so Google receives the full Consent Mode v2 signal set — ad_storage, analytics_storage, ad_user_data, and ad_personalization — with a verifiable default state and post-banner updates.

Summary

Bottom Line: On a WooCommerce store, correct Google Consent Mode v2 setup means using a CMP to manage consent, sending all four Google consent signals through GTM with a denied default before other Google tags run

  • Consent Mode v2 is not complete unless all four signals are handled: ad_storage, analytics_storage, ad_user_data, and ad_personalization. Google added the last two as part of the v2 update for EEA traffic.
  • Basic and advanced mode are materially different. Basic blocks Google tags until interaction and falls back to a more general model, while advanced loads tags with denied defaults, sends cookieless pings when consent is denied, and can support advertiser-specific modelling.
  • In GTM, use the Consent Initialization - All Pages trigger for CMP/default-consent logic, and remove legacy exception triggers or extra consent checks from Google tags that already have built-in consent behaviour.
  • WooCommerce’s official Google documentation expects consent to come from a separate CMP. Google for WooCommerce recommends a CMP plugin compatible with the WP Consent API, and Google Analytics for WooCommerce explicitly says it has no banner UI.
  • The ICO’s 29 April 2026 guidance makes the UK “statistical purposes” exception deliberately narrow. It is about aggregate service-improvement analytics with a simple way to object, and it does not cover online advertising, ad measurement, or linking purchases back to prior ad clicks.

How To Implement

  • Audit which WooCommerce Google integration is currently live before changing anything

    In WP Admin, check whether you are using WooCommerce → Settings → Integration → Google Analytics for the Google Analytics for WooCommerce extension, and whether you are using Marketing → Google for WooCommerce for feed/campaign features. Measurement note: before any consent change, export a baseline of purchase and begin_checkout trends in GA4 and your current Google Ads conversion totals for EEA/UK traffic so you can separate implementation issues from expected consent-related movement later.

  • Install a CMP plugin rather than expecting Woo’s Google extensions to provide the banner

    In WordPress this usually starts at Plugins → Add New. If you rely on Woo’s official Google integrations, pick a CMP path that is compatible with the WP Consent API, because Woo’s Google documentation explicitly recommends a CMP with a WordPress plugin that can work that way, and the Google Analytics for WooCommerce extension says it does not provide cookie-banner UI itself. The WP Consent API is only the communication layer; it still requires a banner plugin and another plugin that supports it.

  • Configure Consent Mode v2 defaults so they are set before other Google tags fire

    In GTM, use the Consent Initialization – All Pages trigger for the CMP/default-consent tag so consent is available before any other triggers run. Your denied default should cover all four Consent Mode v2 signals: ad_storage, analytics_storage, ad_user_data, and ad_personalization. If your banner is asynchronous, allow a short wait_for_update window so the CMP can update the state before tags proceed. If you regionalise, Google supports region-specific defaults; that is useful where your banner is shown only for certain markets.

  • Use GTM’s native consent tooling, not improvised Custom HTML consent code

    Enable Admin → Container Settings → Additional Settings → Enable consent overview so you can review tag-level consent configuration centrally. Google’s current documentation explicitly warns against using Custom HTML to configure consent settings inside GTM and says to use Tag Manager Consent APIs / supported templates instead. This is the cleaner and safer route for most WooCommerce stores without a dedicated developer.

  • Clean up your Google tags so advanced mode can actually work

    In GTM, open each Google tag and review Advanced Settings → Consent Settings. For Google tags with built-in consent checks, remove old exception triggers and do not layer on extra required consent checks unless you have a very specific reason. Google’s documentation says Google tags already modify behaviour based on consent state, and extra checks can stop them firing correctly, especially if the CMP loads asynchronously. Keep extra consent checks for non-Google tags that are not consent-aware.

  • Design the banner and preference centre so the setup is defensible, not just technically “passing”

    The ICO now expects consent mechanisms to make it as easy to refuse as to accept, require positive opt-in before non-exempt technologies are set, explain the purposes clearly, identify relevant third parties, and let users revisit their choices. Avoid “continue browsing = consent”, hidden reject routes, or banners that give prominence only to “accept all”. The CMA’s work on online choice architecture is the broader reason this pattern is risky: interface design can materially distort user choice.

  • Choose basic or advanced mode deliberately

    If you hard-block all Google requests until banner interaction, you are using basic mode. That can be a valid policy choice, but Google states it sends no data at all before consent and relies on a more general model when consent is denied. If you want advanced mode’s better modelling, allow GTM / the Google tag to load with denied defaults so cookieless pings can be sent until the CMP updates the consent state. Do not present this as a compliance shortcut; it is a measurement choice that still needs a properly designed banner and legal sign-off.

  • Add one WooCommerce-specific conflict check if you use Google Analytics for WooCommerce

    That extension can set consent defaults itself. Woo documents the filter woocommerce_ga_gtag_consent_modes so merchants can modify those default consent values, and specifically notes this is useful if another CMP extension is setting its own defaults and you do not want Woo’s extension to overwrite them. This is a real source of duplicate or conflicting consent calls on WooCommerce sites.

  • Verify in Tag Assistant on real WooCommerce journeys, not just the homepage

    Start a session in Tag Assistant, then check the earliest Consent event and the most recent Consent event after banner interaction. Google says the earliest event should show all four parameters on the API call or in the Consent tab with “On-page Default” set to denied, and the later event should show the updated granted or denied state after interaction. Then check which tags fired or were blocked. Run this on the product page, cart, checkout, and order-received page. In practice, this is not a classic-vs-Blocks implementation split — the consent signal is sitewide — but you should still test the actual checkout flow you run live, whether that is classic shortcode checkout or Cart & Checkout Blocks, because purchase tracking still depends on the real order completion path your gateway uses. For Google Analytics for WooCommerce specifically, purchase tracking requires a gateway that redirects to the thank-you / order-received page after payment.

  • After publishing, validate Google Ads diagnostics and wait for the lag

    In Google Ads, go to Goals → Conversions → Summary → [website conversion action] → Diagnostics. Google says consent mode status can take about 48 hours to appear, and in some cases up to 2 weeks. Impact reporting and active modelling also have thresholds and time windows, so do not treat a missing uplift table on day one as proof the implementation failed.

How To Measure

The primary KPI is consent rate for EEA/UK traffic, and the practical way to read it is via your CMP’s own reporting plus a normalised GA4 event stream if you want it in one analytics stack. GTM’s data layer can pass named events, triggers can listen for those events, and GA4’s Reports → Engagement → Events report will show how often each event fired, with Realtime useful for immediate QA. In practice, many stores send a custom event such as consent_accept, consent_reject, or consent_update from the CMP into GA4 through GTM so they can trend banner outcomes alongside ecommerce events. Read this only in the EEA/UK slice, not sitewide, otherwise unaffected traffic hides the picture. Success looks like clean, stable decision capture and no unexplained drop in consent rate after a banner redesign.

The second KPI is modelled-conversion completeness / attribution, and for Google Ads the best operational source is the conversion action Diagnostics tab rather than GA4 alone. Google states that modelled conversions appear in the Conversions column when eligibility requirements are met, and that impact results are shown at domain × country level. Success looks like: Tag Assistant passing on all key pages; Google Ads showing “Consent mode is implemented” and then, where eligible, “Consent mode is implemented and modeling is active”; and impact data appearing once thresholds and timing windows are met.

For on-site funnel integrity, watch the GA4 recommended ecommerce events that populate ecommerce reporting, especially begin_checkout and purchase. Compare the EEA/UK slice before and after rollout, and separately compare consented journeys only if you have implemented CMP outcome events. Success here is not “numbers stay identical” — numbers often change when consent becomes properly enforced — but rather that the consented funnel stays stable and that post-launch losses are explainable by consent choices rather than broken tracking.

Guardrail metrics that must not get worse are: checkout completion for consented users; duplicate purchase events; the ratio between WooCommerce completed orders and GA4 purchase counts widening unexpectedly beyond expected consent loss; Tag Assistant showing missing consent defaults or updates on some pages; and Google Ads diagnostics showing that default/update calls are firing in the wrong order or not on 100% of pages.

Pitfalls

  • Myth: “Consent Mode v2 is my cookie banner.” It is not. Google’s own documentation says consent mode does not provide a banner or widget; it works with your banner or CMP. On WooCommerce, the official Google docs point you towards a separate CMP/WP Consent API route, and Google Analytics for WooCommerce explicitly says it has no banner UI.
  • Mistake: Sending only two signals. Some legacy setups still send only ad_storage and analytics_storage. For Consent Mode v2, Google added ad_user_data and ad_personalization, and they need to be present and verifiable.
  • Mistake: Blocking GTM or the Google tag completely, then expecting advanced-mode modelling. If you block the tag itself, you are back in basic mode. Google says advanced mode loads tags with denied defaults and cookieless pings; basic mode sends nothing before interaction and uses a less detailed general model.
  • Mistake: Leaving old GTM exception triggers or additional consent checks on Google tags. Google documents that Google tags already have built-in consent checks, and old blocking logic can stop them firing properly or stop consent updates from taking effect in time.
  • Mistake: Assuming the ICO’s statistical purposes exception covers a normal GA4 + Google Ads setup. The April 2026 ICO guidance is much narrower than that. It is about aggregate service-improvement statistics with a simple way to object, and the ICO explicitly says it does not cover online advertising, ad measurement, or linking purchase journeys to ad clicks.
  • Mistake: Treating banner UX as a cosmetic exercise. The ICO expects refusal to be as easy as acceptance, and its annual report shows active enforcement pressure on cookie banners. The CMA’s work on online choice architecture is the wider warning that dark-pattern-style interfaces can distort decisions.

Examples

FAQs

Sources & Further Reading

Want us to implement this for you?

We run measured CRO consultancy for WooCommerce. If you want help prioritising, testing & implementing these improvements, tell us about your store.

Book Pilot

About This Page

  • Written By: Eliot Webb – Founder & WooCommerce CRO Consultant
  • Last Reviewed: 17 Jun 2026
  • Last Updated: