GDPR and Google Consent Mode v2 for D2C Stores
Short answer
Under the GDPR and the UK GDPR a store handling data about people in the EU or the UK needs a lawful basis for processing it, and under the separate ePrivacy rules it generally needs prior consent before setting non-essential cookies or similar tracking. Google Consent Mode v2 is the wiring that tells Google's tags what the visitor chose, using signals including ad_storage, analytics_storage, ad_user_data and ad_personalization. Where consent is refused, measurement degrades rather than stops: you lose the ability to join a purchase to a click at user level, remarketing audiences stop filling, and part of your reporting becomes modelled. This is a practical overview and not legal advice, so confirm your own obligations with a qualified data protection adviser.
Published 2026-09-28 · Updated 2026-09-28
What the rules actually require
Two separate sets of rules are usually collapsed into one conversation. The GDPR, and the retained UK version of it, govern the processing of personal data: you need a lawful basis, you must tell people what you are doing, and you carry obligations around access, retention and security. Separately, the ePrivacy rules, implemented in the UK as PECR, govern storing or reading information on somebody's device, which is what cookies, pixels and most tracking scripts exist to do.
The practical consequence is that the cookie question is answered mainly by the ePrivacy side, and it asks for prior consent for anything that is not strictly necessary to provide the service the visitor requested. Analytics and advertising tags are not strictly necessary in that sense, however useful they are to you. Regulators have also been consistent that consent must be freely given, specific, informed and as straightforward to refuse as it is to give.
None of this is legal advice, and the detail differs by member state, by regulator and over time. What follows describes how the mechanics usually work, so that you can hold an informed conversation with a qualified data protection adviser, who should be the person telling you what your particular store must do. If you sell into the EU or the UK at any scale, that conversation is considerably cheaper than the alternative.
Consent Mode v2 in plain terms
Google Consent Mode is a way for your consent banner to tell Google's tags what a visitor agreed to. It is not a banner, not a consent management platform and not a compliance product in itself; it is the wiring between the two. Version 2 added two signals to the original set, so the four that matter for advertising and analytics are ad_storage, analytics_storage, ad_user_data and ad_personalization, each controlling a different behaviour.
In a correct setup the signals default to denied for visitors in the European Economic Area and the UK before any choice is made, the tags respect that default, and the banner sends an update once the visitor chooses. Google has required these signals from advertisers who want to continue using personalisation and audience features for European traffic, so this is a condition of the tooling as well as a regulatory question.
Getting the default wrong is the most common implementation fault by a wide margin. A banner that fires tags first and records consent afterwards passes a visual inspection and fails the actual requirement, because the storage has already happened. Check with browser developer tools rather than with the banner vendor's own preview: load the page, refuse everything, and look at what has been written. If advertising cookies appear before you click anything, the implementation is not doing what the dashboard claims.
Basic and advanced consent mode
Basic consent mode blocks Google tags from loading at all until consent is given. Nothing is sent for a visitor who refuses, which is conservative and simple to explain, and it means those visitors are entirely absent from your measurement. Advanced consent mode loads the tags in a restricted state, in which cookieless pings can be sent without identifiers, and Google uses those as an input for modelled conversions.
Advanced generally preserves more reporting, which is why platforms encourage it, but it does send a request before a choice has been made, and whether that is acceptable is a question for your adviser and your regulator rather than for your marketing team. Several European authorities have taken a strict view of pre-consent signals. Choose deliberately, write down the decision and the reasoning with a date against it, and revisit when guidance changes.
- Basic: no tag fires before consent, cleanest story, largest measurement gap
- Advanced: restricted pings without identifiers, more modelling, more scrutiny
- Either way, refusal must be as easy as acceptance
- Record which mode you chose, why, and on what date
What actually breaks when consent is refused
Nothing goes blank. What you lose is the ability to join events to a person. Without ad_storage the click identifier that ties an ad to a session cannot be stored, so a purchase that follows cannot be credited to the campaign that caused it. Platform-reported conversions fall, cost per acquisition appears to rise, and the campaign looks worse than it is while the underlying business performance has not moved at all.
Audiences shrink in parallel. Remarketing lists and customer match segments only fill with consented users, so a store with a low consent rate in Europe finds its warm audiences too small to target efficiently and its lookalike seeds thinner than expected. Dynamic remarketing feels it first, because it depends on product-level browsing signals. Frequency capping and exclusion lists degrade for the same reason, so some refusing visitors will see ads for items they have already bought.
Reporting also becomes partly modelled. Where consent is missing, platforms estimate conversions from the behaviour of consenting users, and estimation needs volume, so smaller accounts receive less modelling and noisier numbers than larger ones. That is a reason to anchor on your own order data and treat platform totals as directional for European traffic. Comparing this year's reported return on ad spend with a figure from before a consent change compares two different measurements.
Server-side tagging does not remove the consent requirement
Moving tags into a server container changes where requests originate, not whether you are permitted to process someone's data. If you are storing or reading information on a device, or processing personal data without a basis, the rules apply in the same way. Server-side tagging is a resilience and data-quality measure. It is not a consent workaround, and treating it as one buys a compliance problem dressed up as a technical upgrade.
Used properly it is genuinely valuable: a server container can receive the consent state, drop or redact parameters for refusing visitors, control exactly which fields leave your infrastructure, and improve the reliability of events that browsers now block or shorten. The discipline is to make consent the gate at the top of the pipeline rather than a check at the end. Build it so that a refusal produces no identifiers anywhere downstream and the argument does not arise.
Getting a consent rate that is not self-inflicted
Consent rate is the variable most within your control and the one most often left to a default template. Banners that bury refusal behind a second click, grey out the reject button, or open onto a wall of vendor toggles depress consent and, in several jurisdictions, have drawn regulator attention for precisely that reason. A clear two-button banner with plain language about why you track usually performs better than a manipulative one, as well as being easier to defend.
Test the wording as you would test ad copy, within the bounds of what is permitted. Explaining the benefit honestly, such as remembering the basket, showing relevant products and keeping the site working, tends to lift acceptance. Be careful not to cross into pressure or misdirection, which is both a legal risk and a trust problem with the same customers you are asking to buy. Measure the rate by market, because it varies widely and an average hides where the problem sits.
A practical order of work
Sequence it so each step is verifiable. Choose and configure a consent management platform that supports Consent Mode v2 and, if you need one, the relevant EU vendor framework. Set the defaults to denied for European Economic Area and UK traffic. Wire the signals into your tag manager and confirm, in both the tag assistant and the browser, that nothing fires before a choice. Then gate the non-Google tags through the same platform, including Meta, analytics tools and session recorders.
Afterwards, re-baseline. Record the date of the change in your analytics annotations, expect a step down in reported conversions, and compare against your own order data rather than against last quarter's platform numbers. Then have your adviser review the result, including the privacy notice, retention periods and your record of consent. The technical work and the legal position are related but they are not the same job, and only the first of them is a marketing task.
The four Consent Mode v2 signals and the practical effect of denial
| Signal | What it controls | What happens when it is denied |
|---|---|---|
| ad_storage | Advertising cookies and click identifiers | A purchase cannot be joined to a click at user level |
| analytics_storage | Analytics cookies and session identity | Sessions fragment and returning visitors read as new |
| ad_user_data | Sending user data to Google for advertising | User data is withheld and matching degrades |
| ad_personalization | Use of data for personalised advertising | Remarketing and customer match audiences stop filling |
Related questions
Do we need a cookie banner if the business is outside the EU?
Where the business is registered is not the test; whose data you handle is. If you knowingly sell to or target visitors in the EU or the UK, those rules can apply to that traffic regardless of where you are incorporated. Many stores handle this by applying consent controls geographically. Confirm your own position with a qualified adviser rather than assuming distance is protection.
Will implementing consent mode reduce our conversions?
It reduces reported conversions, often noticeably on European traffic, while actual orders continue at the same rate. Annotate the date, compare against your own order data, and reset campaign targets against the new baseline instead of trying to restore the old numbers. Teams that skip the re-baselining routinely cut spend on campaigns that never stopped working in the first place.
Is Consent Mode the same as a consent management platform?
No. The platform shows the banner, records the choice and stores proof of it. Consent mode is the signalling layer that passes that choice to Google's tags. You need both, and you also need the platform to gate non-Google tags such as Meta's pixel, which consent mode does not cover. A store with consent mode configured and Meta firing freely has solved half the problem.
Does the Meta pixel need the same treatment?
In principle yes. The lawful basis and the device storage requirement apply to any tracking technology, not only to Google's. Meta has its own consent-related controls and terms, but the gating is your responsibility and is normally handled by the consent platform blocking the tag until a choice is made. The Conversions API is subject to the same requirement rather than exempt from it.
Who is responsible if we get this wrong, us or the agency?
As the business deciding why and how data is processed you are normally the controller and carry the primary obligation, while an agency acting on your instructions is usually a processor. That is why a written processing agreement matters and why implementation sign-off should involve your data protection adviser. This describes the general shape of the position rather than advice on your specific circumstances.