A cookie banner isn't only a legal matter. For an eCommerce business investing in Google Ads it can also become a measurement, optimisation and revenue problem.
If the banner collects consent but doesn't communicate it properly to the tags, GA4 and Google Ads can end up receiving incomplete signals. If instead the tags fire before the user has made a choice, the problem isn't only technical: it can become a privacy risk too. And if everything is blocked indiscriminately, the campaigns lose part of the journey and learn from poorer data.
Consent Mode v2 exists precisely at that delicate point: making Google tags behave according to the user's choices and sending Google consistent consent signals. It isn't there to "bypass" consent, it doesn't automatically make a site compliant, and it doesn't replace a properly built banner. Its job is to connect consent, tracking and advertising platforms in a tidier way.
For an eCommerce owner the question isn't "do we have a banner?". The right question is: is our consent correctly driving Google Ads, GA4 and conversions?
What Consent Mode v2 is, in plain terms
Consent Mode is the mechanism by which Google tags change their behaviour according to the consent the user has expressed. If the user accepts, the tags can work normally for the permitted purposes. If the user refuses, the tags have to limit what they collect and what they store.
Version v2 made two additional signals central compared with the classic setup:
- ad_user_data: indicates whether the user's data can be sent to Google for advertising purposes;
- ad_personalization: indicates whether the data can be used for personalised ads, remarketing and similar features.
These signals sit alongside other consent states that were already familiar, such as ad_storage and analytics_storage, that is, consent tied to storage for advertising and analytics.
In practice, the site has to tell Google not only "can I use advertising cookies?", but also "can I use the data for advertising and personalisation?". That's an important distinction, especially for eCommerce sites using Google Ads, remarketing, Performance Max, GA4 and audience lists.
Why eCommerce businesses should care
An eCommerce site lives on signals: product views, add to cart, checkout, purchases, order value, margin, returns, new customers, returning customers. Google Ads uses those signals to work out where to put budget and which users to go looking for.
If consent is handled badly, three rather unpleasant things can happen:
- conversions are measured incompletely;
- automated campaigns receive less useful data;
- remarketing, audiences and personalisation become less reliable or can't be used properly.
You often see the result in the reports: strange drops in conversions, GA4 data that doesn't match the ERP, campaigns that appear to get worse after a banner change, remarketing lists that empty out, duplicate events, or conversions that only show up in some tools.
The trouble is that many people treat the cookie banner as a cosmetic or legal component to install and forget. In reality the banner is a piece of the marketing system. It has to talk to Google Tag Manager, GA4, Google Ads, any server-side tracking, the feed, the CRM and the eCommerce platform.
Basic and advanced: two different ways of implementing it
Google distinguishes two main approaches to Consent Mode: basic and advanced.
With the basic approach, Google tags don't fire until the user interacts with the banner. If the user accepts, the tags load and receive the consent state. If the user refuses, the tags send no data to Google.
With the advanced approach, tags can load with consent denied by default and adapt their behaviour to the user's choice. When consent is denied they can send limited, cookieless signals that are useful for modelling, always within the consent settings.
The difference is not trivial. The advanced approach can give Google more to work with when modelling conversions and behaviour, but it requires a more careful configuration. It isn't a shortcut to switch on at random. It should be assessed with whoever manages privacy, the banner, the tags and the campaigns.
For many eCommerce sites, this decision shouldn't be taken automatically by the banner plugin. You need to understand the whole chain: which tags exist, which purposes they declare, which regions are served, which advertising platforms use the data and how the user's choices are stored.
The false sense of security of "the banner is installed"
Plenty of sites have a visible banner and assume the matter is settled. Then, when you actually look at the configuration, problems like these emerge:
- the banner doesn't send Consent Mode signals to Google;
- tags fire before the user makes a choice;
- GA4 is blocked, but Google Ads isn't;
- Google Ads receives conversions with no consistent consent state;
- ad_user_data and ad_personalization aren't configured;
- consent is read correctly only on the first page, then it's lost;
- the banner changes language or geographic area, but the defaults stay the same;
- Tag Manager contains old tags that ignore consent;
- the theme or eCommerce plugin injects scripts outside Tag Manager;
- server-side tracking receives events without handling consent properly.
That's the point: it isn't enough for the banner to appear. You have to check what actually happens in the browser, in Tag Manager, in GA4 and in Google Ads.
What happens to Google Ads when consent is wrong
Google Ads doesn't work in a vacuum. Automated bidding strategies learn from the data they receive. If that data is incomplete, inconsistent or dirty, the account can make worse decisions.
A classic example: after a new banner goes live, conversions drop by 30% in the reports. Sometimes that's normal, because the site was previously tracking too much. Sometimes the drop is down to a technical error instead: the purchase event no longer fires, consent isn't updated, the conversion tag stays blocked even after acceptance, or GA4 and Ads are reading two different realities.
Another frequent case involves remarketing. If ad_personalization isn't handled well, audience lists may not work as expected. If ad_user_data isn't communicated correctly in the areas where consent is required, some advertising features can be limited.
This connects to a broader theme: you shouldn't optimise campaigns on wrong or incomplete signals. We've covered this in the articles on Performance Max and cart conversions and on ROAS distorted by conversion value, margins and returns. Consent Mode adds another layer: the data has to be useful, but also collected and transmitted correctly.
A technical checklist for an eCommerce site
A serious Consent Mode v2 review should check at least these points.
- Compatible banner: the CMP or cookie banner must support Consent Mode v2 and send the correct signals.
- Consistent defaults: before the user makes a choice, consent states must be set cautiously and consistently with the legal strategy.
- Update after the choice: when the user accepts or refuses, the signals must genuinely change.
- ad_storage: consent for storage tied to advertising.
- analytics_storage: consent for storage tied to analytics.
- ad_user_data: consent to use user data for advertising purposes.
- ad_personalization: consent for ad personalisation.
- Google Ads tags: conversion linker, remarketing and conversions must respect the consent states.
- GA4: eCommerce events such as view_item, add_to_cart, begin_checkout and purchase must be tested with consent both accepted and refused.
- Duplicate events: updating consent must not fire the same event twice.
- Scripts running loose: theme, plugins, checkout modules, chat, pixels and marketing tools must not sidestep the consent logic.
- Server-side: if you use server-side Tag Manager, consent has to travel with the events on the server side too.
- Real debugging: test with Tag Assistant, GTM preview, browser tools and the Google Ads/GA4 reports.
The checklist isn't there for the theory. It's there to stop an apparently small change to the banner from breaking data that thousands of euros a month are being spent on.
The most common mistakes
On eCommerce sites the same mistakes come round with some regularity.
- Installing a plugin and testing nothing: the banner appears, but the signals don't arrive as they should.
- Confusing compliance with tracking: a banner can look great and still fail to configure Google Ads properly.
- Blocking everything with no strategy: it reduces risk, but you lose visibility over essential data without understanding what's going on.
- Leaving hardcoded tags in place: old scripts in the theme or checkout fire regardless of Tag Manager.
- Not distinguishing countries and regions: the rules for users in Europe, the UK or Switzerland may require specific signals.
- Not updating Google Tag Manager: old containers, copied triggers and custom tags can ignore consent states.
- Not testing the checkout: the purchase often happens on different templates, domains or steps from the product pages.
- Trusting GA4 alone: GA4, Google Ads and the ERP need to be compared, not read as isolated truths.
- Not documenting the configuration: six months later nobody remembers why a consent setting was set the way it was.
The worst problem is the silent one: the site looks like it's working, the campaigns keep spending, but the data feeding the decisions is no longer reliable.
Mini case: new banner, conversions halved
Picture an eCommerce site that changes cookie banner because the old plugin was dated. After release, Google Ads conversions drop sharply. Sales in the ERP don't fall in the same way, but the Ads reports do.
There can be several hypotheses:
- the site previously tracked users without consent as well, and the data is now more realistic;
- the purchase tag doesn't fire after acceptance;
- consent is updated after the event has loaded, so it arrives too late;
- the checkout sits on a template that doesn't include the new banner's logic;
- the conversion linker isn't working properly;
- GA4 and Google Ads receive events under different logic.
Without debugging, all these hypotheses turn into pointless arguments. With debugging you can see the whole path: initial consent state, user choice, update, tag firing, parameters sent, conversion recorded, comparison with the real order.
It's the same approach we use in Google Ads audits and in tracking and CRM work: looking at the final result isn't enough, you have to see how the data is born.
What to ask your agency
If you run an eCommerce site and you're spending budget on Google Ads, these questions are very concrete.
- Does our cookie banner genuinely support Consent Mode v2?
- Which consent states are set before the user makes a choice?
- Are ad_user_data and ad_personalization configured correctly?
- Have we tested what happens when the user accepts everything?
- Have we tested what happens when the user refuses everything?
- Do GA4 and Google Ads receive the same eCommerce events?
- Does the purchase tag fire once, and only when it should?
- Are there Google scripts inserted outside Tag Manager?
- Does the checkout follow the same logic as the rest of the site?
- Have we verified the configuration with Tag Assistant?
- Does server-side tracking, where present, receive and respect consent?
- Do we compare Ads conversions with real orders, cancellations and the ERP?
- Is there any documentation of the current configuration?
If the answer is "yes, the banner is there", half the work is still missing. A visible banner doesn't prove the tracking is correct.
How we handle this at BitHub
At BitHub we treat Consent Mode as part of the eCommerce system, not as an isolated switch.
The work can include:
- an audit of the cookie banner, CMP and Google Tag Manager;
- mapping the Google Ads, GA4, remarketing and conversion linker tags;
- verifying consent states before and after the user's choice;
- checking ad_storage, analytics_storage, ad_user_data and ad_personalization;
- testing the main eCommerce events, especially purchase and order value;
- hunting for hardcoded scripts in the theme, plugins, checkout and third-party modules;
- checking any server-side tracking;
- comparing Google Ads, GA4 and real orders;
- documenting the configuration so the following months don't descend into chaos.
This connects to our work on SEO and Google Ads, web compliance, GDPR and cookies, bespoke eCommerce development and CRM/ERP platforms connected to real data.
The goal isn't to chase yet another Google setting. It's to build tracking that respects the user's choices and, at the same time, lets the campaigns learn from clean signals.
Useful sources
For the technical side, start with Google's official documentation on Consent Mode, the guide to setting it up on websites, the Google Ads updates on user consent in the European Economic Area and the page on checking consent signals.
FAQ
Does Consent Mode v2 make a site automatically GDPR compliant?
No. Consent Mode manages the behaviour of Google tags according to consent, but it doesn't replace the privacy notice, the banner, the legal basis, the CMP configuration and the privacy assessments. It's a technical part of the system, not the whole of compliance.
Is Consent Mode v2 only for people running Google Ads?
It's particularly important for anyone using Google Ads, remarketing, conversions and GA4 linked to campaigns. Sites without Ads can also use Consent Mode to manage Google tag behaviour better, but the subject becomes critical when advertising budget depends on the data being collected.
What's the difference between basic and advanced Consent Mode?
In basic, tags are blocked until the user interacts with the banner. In advanced, tags can load with consent denied by default and send limited cookieless signals when consent isn't given. The choice should be assessed case by case.
Why do ad_user_data and ad_personalization matter?
Because they tell Google whether the user's data can be used for advertising purposes and for ad personalisation. Without these signals, some features tied to measurement, audiences and remarketing can be limited in the areas where consent is required.
How do I know whether Consent Mode is set up properly?
You need to test the site with tools such as Tag Assistant, Google Tag Manager preview and browser tools. Check what happens before the choice, after acceptance, after refusal, during checkout and on the order confirmation page.
Why can conversions drop after a new cookie banner?
It can come from previous measurement that was too permissive, but also from technical errors: tags blocked after consent, purchase events not sent, consent updated too late, duplicate scripts, or a checkout that the new configuration doesn't cover.
Want to check whether your consent setup is breaking Google Ads?
We can review your cookie banner, Tag Manager, GA4, Google Ads conversions, checkout and real orders. The aim is to work out whether you're measuring less because users have legitimately chosen so, or losing data because of a technical error.