Cookie banners and Consent Mode v2: a practical guide
Why GA4 shows fewer visitors, what the four Consent Mode v2 signals are, what a correct banner looks like, and how to check your implementation in five minutes.
If you have installed Google Analytics and the visitor numbers in the report look lower than they should be, it is probably not a measurement error. It is consent: every visitor who does not press “Accept” in the banner cannot be tracked with cookies, and if the implementation is not done properly, those people simply disappear from the data.
Consent Mode v2 is the mechanism by which a site tells Google’s tags what each visitor chose. It is not a banner, it does not replace one, and it does not make you compliant on its own — but without a correct implementation the measurement stays incomplete, and some Google Ads features can no longer be used for traffic from the European Economic Area. This article explains what the four signals are, what a correct banner looks like, the five mistakes that lead to complaints, and how to check the implementation in five minutes.
A note. We are a web design agency, not data protection consultants. This article describes the technical side and the usual practices. For an assessment of your own company’s compliance, consult a specialist.
Contents
- Why your report shows fewer visitors than you have
- What Google Consent Mode v2 is and when it is needed
- The four signals
- Consent Mode is not a banner: who does what
- Basic or Advanced
- What a correct banner has to look like
- Five mistakes that lead to complaints
- How to check in five minutes
- What a cookie policy has to contain
- What to do about scripts that are not Google’s
- What to do about data collected wrongly
Why your report shows fewer visitors than you have
Three causes combine:
1. Those who decline. Depending on the site and the audience, a considerable proportion of visitors do not accept analytics cookies. Without Consent Mode, they generate no events at all.
2. Those who never get to choose. A visitor who arrives, looks for ten seconds and leaves without touching the banner is, technically, a visitor without consent.
3. Blocking at browser and extension level. Some traffic never reaches Google, whatever the consent.
The result: the report shows a fraction of reality, and decisions taken on it are taken on incomplete data — usually without anyone knowing.
What Consent Mode solves
It does not turn a refusal into consent and it does not give you individual data about people who declined. In the Advanced implementation, Google’s tags can send cookieless measurements that include the consent state and certain technical information; Google can then use those for aggregate modelling. That gives you more useful estimates of volumes and trends, without reading or writing the analytics or advertising cookies for which consent was not given.
What Google Consent Mode v2 is and when it is needed
Google Consent Mode v2 is the mechanism by which a site tells Google’s tags each visitor’s choice about the storage and use of data, through four signals. The tags adjust their behaviour according to those choices. Since March 2024, Google requires the updated signals to be sent in order to keep the measurement, ad personalisation and remarketing features that apply to users in the European Economic Area. It is a requirement of the Google ecosystem for those features, not a universal legal obligation to use Consent Mode.
The practical consequence of not implementing it: Google Ads campaigns lose remarketing and conversion measurement features for European traffic, and the Analytics data stays incomplete.
Sources: Google — Consent mode overview(opens in a new tab), Google Ads — updates for EEA traffic(opens in a new tab).
The four signals
| Signal | What it controls |
|---|---|
analytics_storage |
whether Analytics can use cookies to recognise a returning visitor |
ad_storage |
whether advertising cookies and identifiers can be read and written |
ad_user_data |
whether user data can be sent to Google for advertising |
ad_personalization |
whether the data can feed remarketing and personalised ads |
Each has two values: granted or denied.
The default state
Before the visitor chooses anything, all four have to be denied. That is the essence of it: consent is given, not assumed. A site that starts at granted and waits for a refusal has it backwards.
There is one usual exception: security_storage, for strictly necessary security functions.
What happens after the choice
When the visitor presses a button in the banner, the signals update, and the tags that were waiting change their behaviour from that moment.
Consent Mode is not a banner: who does what
The most frequent confusion. There are three distinct components:
THE BANNER (CMP) → collects the choice and remembers it
CONSENT MODE → translates the choice into the four signals
GOOGLE'S TAGS → adjust their behaviour to the signals| Component | What it does | What it does not do |
|---|---|---|
| The banner | asks, remembers, allows withdrawal | does not block other scripts by itself |
| Consent Mode | communicates the choice to Google’s tags | asks nothing; does not cover non-Google scripts |
| Script blocking | prevents third-party scripts from running | — |
Consent Mode covers only Google’s tags. A social network pixel, a chat widget, an embedded map or a third-party video player has to be blocked separately, until consent. It is the most commonly forgotten part: a correct banner, a correct Consent Mode, and a chat widget setting three cookies before the visitor has had a chance to read anything.
Basic or Advanced
Two implementation modes, with different trade-offs.
| Basic | Advanced | |
|---|---|---|
| When the tags load | only after consent | from the start, in a restricted state |
| Without consent | nothing is sent | the consent state and cookieless measurements are sent |
| Data quality | only the users who accept | estimates for all traffic |
| Complexity | lower | higher |
Advanced can give a more complete picture, because it allows modelling on the basis of cookieless measurements when storage has been refused. It neither writes nor reads the cookies for the refused categories, but it does transmit the consent state and certain technical data to Google; which is why the choice has to be assessed, not treated as a default.
Basic is the more conservative option, appropriate if internal policy requires that absolutely nothing leaves before consent.
The choice between the two is a compliance decision, not a technical one. Discuss it with whoever assesses your data processing.
What a correct banner has to look like
What it has to contain
- A short explanation, in the site’s language, of what is collected and why.
- Cookie categories, at least: strictly necessary, analytics, marketing.
- Buttons of equal visual weight for accepting and declining.
- A visible link to the cookie policy and the privacy policy.
- A way to change your choice later, permanently available.
What is not permitted
- “Accept all” only. Declining has to be as simple as accepting. A banner with a big green “Accept” button and a small grey “Settings” link raises an obvious problem.
- Pre-ticked optional categories. Consent has to be an active action.
- Cookies set before the choice, other than strictly necessary ones.
- Blocking access to content until acceptance, as a general rule.
- Scrolling treated as acceptance. That is not consent.
What works well in practice
A discreet banner, at the bottom, that does not cover the content, with three buttons of the same size: Accept all · Decline all · Customise. Simple, quick, compliant, and with an acceptance rate usually better than the aggressive versions — because people who do not feel manipulated accept more often.
Five mistakes that lead to complaints
1. Cookies set before consent. The most frequent and the easiest to prove: open developer tools and it is visible in two seconds.
2. Declining made harder than accepting. One obvious button and one hidden one.
3. No way to withdraw. Consent has to be as easy to withdraw as it was to give. In practice: a permanent link in the footer that reopens the preferences.
4. A generic cookie policy. Text copied from another site, listing cookies you do not have and omitting the ones you do. The policy has to describe your cookies, with the purpose and duration of each.
5. The banner appears but blocks nothing. The commonest case with quick installations: the banner is decorative, and the scripts run whatever the choice.
In Romania, the data protection supervisory authority has penalised operators for cookies set without valid consent. It is not a theoretical risk.
How to check in five minutes
Test 1 · A private window
- Open the site in a fresh private window.
- Do not touch the banner.
- Open the browser’s developer tools (
F12), go to the storage section and look at the cookies.
What you should see: only strictly necessary cookies — session, language preference, form protection.
What you should not see: analytics or advertising cookies. If they appear, the banner is blocking nothing.
Test 2 · Network requests
In the same window, move to the network section and reload the page without touching the banner. Filter by the names of the analytics and advertising services.
With Consent Mode Advanced you will see requests, but they have to carry the parameters marking the absence of consent.
Without Consent Mode, in a correct implementation, you should see no request at all before the choice.
Test 3 · The signals in Analytics
In Google Analytics 4, turn on debug mode and open the debug view. Visit the site and watch the events.
What to check: the consent state appears on the events, is denied before the choice, and becomes granted after acceptance. If the state does not appear at all, Consent Mode is not implemented.
Test 4 · Withdrawal
Accept everything, then look in the footer for the link to change preferences. Withdraw consent and check the cookies again: the analytics and marketing ones have to disappear.
If you cannot find the link, that is a problem. If you find it and the cookies stay, that is a bigger one.
What a cookie policy has to contain
The document most often copied from another site and, for exactly that reason, most often wrong.
What it has to describe
Your cookies, not cookies in general. For each one:
| Information | Example |
|---|---|
| Name | _ga |
| Who sets it | Google Analytics (third party) |
| Purpose | distinguishing visitors |
| Category | analytics |
| Duration | 2 years |
Plus: how consent can be withdrawn, how cookies can be deleted from the browser, and the controller’s contact details.
How to take your inventory
Not from memory. In practice:
- A private window, visit the site, accept everything.
- Browse a few pages, including contact and, if you have one, the basket.
- Developer tools → storage section → cookies.
- Note every cookie: name, domain, duration.
- For each, find out who sets it and why.
You will usually find two or three cookies from services you had forgotten or did not know you had.
Updating
The policy gets rechecked whenever you add a new service to the site. A chat widget, a map, a review widget — each brings its own cookies, and each adds them without asking anyone.
Recommended check: twice a year. It takes twenty minutes.
What is not enough
A page saying “we use cookies to improve your experience”. It describes nothing verifiable, helps nobody, and does not meet the requirement to inform.
What to do about scripts that are not Google’s
The part Consent Mode does not cover, and in practice the source of most problems.
What falls in here
Social network pixels, chat widgets, embedded maps, external video players, review widgets, behavioural analytics tools, externally hosted forms.
Each sets cookies or stores data on the device at the moment it loads — not when it is used.
How they are blocked
The script does not load at all until consent. In practice, instead of the usual script tag you use a marker the consent platform activates after the choice.
Most banner platforms provide the mechanism; the problem is that nobody applies it to scripts added after the installation.
The special cases
Embedded video. Many players set cookies on load, even if nobody presses Play. The fix: a preview image that loads the player only on click. You gain on speed too — see Core Web Vitals explained for business owners.
Embedded map. The same fix: a static image of the map, linking to the maps app. On a contact page, the interactive map is often the heaviest element there.
External fonts. A font loaded from a third-party domain transmits the visitor’s IP address to that service. The simple and correct fix: host the fonts locally.
The final check
A private window, do not touch the banner, developer tools → network. Look at the list of domains something is being downloaded from.
It should only be your own domain. Anything else is a script starting before consent.
What to do about data collected wrongly
The typical situation: you discover that for several months you collected data without valid consent, or with a faulty implementation.
Step 1 — fix the implementation. Nothing else matters until the problem stops.
Step 2 — note the moment. The data from before and after are not comparable. That matters for interpreting the reports: a sudden “drop” in traffic after the fix is actually the move from incorrect measurement to correct measurement.
Step 3 — consult a specialist about what happens to the historical data. It may need deleting. That is not a technical decision.
Step 4 — document it. What was wrong, when it was found, what was done, when. It is the first question in any investigation.
A practical note
If you have just installed Analytics, check the implementation now, not in six months. It is infinitely simpler to start correctly than to fix it and then wonder what to do about the history.
We configure consent banners, Consent Mode v2 and correct blocking of third-party scripts, with a check on every point in this article. Write to us if you want us to look over your current implementation.
See also our cookie policy, our privacy policy and the article on web accessibility becoming mandatory.