A cookie banner that really blocks: Consent Mode v2 and proof of consent

Almost every store has a cookie banner. Far fewer have a banner that works. It is common to open a store in a private window, touch nothing and already see analytics, advertising pixel and chat cookies in the browser. The banner is there, with its buttons, but it prevents nothing: it is decoration.

This article is not a general overview of the GDPR. It covers three specific things: how to tell whether your banner really blocks, where Google Consent Mode v2 fits into all this and what proof you need to keep of each visitor decision.

What the law requires, in short

Article 22.2 of the LSSI (Spain's Information Society Services Act) states that cookies that are not strictly necessary may only be set with the user's informed consent. Consent must meet the GDPR requirements: freely given, specific, informed and unambiguous. And Article 7(1) of the GDPR adds something that is often forgotten: the controller must be able to demonstrate that the data subject consented.

The cookie guidance of the AEPD (the Spanish Data Protection Agency) sets out how to do it in practice. The two points most often breached:

• Rejecting must be as easy as accepting. If «Accept» is a big green button and «Reject» is a grey link hidden in a second layer, consent is not freely given.
• Nothing that is not necessary is set before the visitor decides. No analytics, no advertising, no embedded videos that set their own cookies.

Why so many banners block nothing

In PrestaShop, each module puts its scripts wherever it likes: in the <head>, at the end of the page or loaded later by JavaScript. A banner that only «draws» the window and stores a cookie with the answer has no way of stopping what other modules have already injected. The typical failures:

1. The banner loads after the tags. By the time the visitor sees the window, Google Analytics or the pixel have already fired.
2. Blocking whole modules. Some cookie modules disable entire modules until there is consent. That works for a pixel, but if the blocked module is a payment gateway or a financing system, checkout breaks for anyone who rejects.
3. Anything added by JavaScript slips through. A chat or widget that creates its scripts and iframes in the browser, after the page has loaded, does not go through any server-side filter.
4. Iframes are left untouched. An embedded YouTube video or map sets third-party cookies as soon as it loads.
5. The cookie inventory is out of date. The cookie policy lists what was there on the day it was written, and three new modules have been installed since.

How to check yours in five minutes

1. Open the store in a private window, without logging in.
2. Open the browser developer tools, the storage tab (cookies and localStorage) and the network tab.
3. Do not touch the banner. Browse the home page, a category and a product page.
4. Look at which cookies are there and which domains have been called. Anything that is not technical (session, cart, language, the consent cookie itself) should not be there.
5. Click «Reject all», delete the cookies, reload and repeat. It should be just as clean.
6. Place a test order after rejecting: payment has to work.

If in step 4 you see analytics or advertising cookies, your banner is not compliant, however nice it looks.

Google Consent Mode v2: what it is and what it is not

Consent Mode is the way Google tags (gtag, Google Tag Manager, Google Ads, GA4) receive the visitor's decision. It is not a banner and it does not replace consent: it is the channel through which your banner tells Google what it may do.

Version 2 uses four main signals:

Google requires these signals to keep using advertising and audience features with visitors from the European Economic Area. If they do not arrive, conversion measurement and remarketing lists suffer.

Basic or advanced

• Basic mode: Google tags do not load until the visitor accepts. It is the most cautious option.
• Advanced mode: tags load from the start with everything denied, send cookieless pings and update when the visitor decides. It lets Google model conversions, but you should assess it with your data protection adviser.

The technical detail that fails most often: the consent default value must be declared before any Google tag, at the very top of the <head>. If GTM loads first, its tags start without knowing anything about consent.

Proof of consent

If one day you are asked to prove that a visitor accepted advertising, «we have a banner» is not an answer. The sensible approach is to store, for each decision:

• A consent identifier, the same one stored in the visitor's cookie.
• Date and time.
• Which categories were accepted and which were rejected, and the signals sent to Consent Mode.
• The version of the policy in force and what was shown: texts, categories, providers.
• The IP address truncated or hashed, not in full, so as not to store more data than necessary.

And a maintenance rule: if you change the categories or a new provider appears, ask again. What the visitor accepted six months ago does not cover a pixel you installed yesterday.

An up-to-date store also means this

Many cookie modules in stores that have spent years on 1.6 or 1.7 stayed on the first version of Consent Mode, or on none at all. When you update PrestaShop or migrate to a new version, check the banner with the same private-window test: it is one of the first things to stop working without warning, because nobody looks at cookies after a migration.

Checklist

• «Reject all» at the same level as «Accept all», in the first layer.
• Private window without deciding: technical cookies only.
• Test order after rejecting: payment works.
• Consent Mode v2 declared before GTM or gtag, with all four signals.
• Embedded videos and maps held back until accepted.
• A record of each decision, exportable.
• A cookie policy with the real inventory, and a new version whenever it changes.
• A permanent link or button so the visitor can change their mind.

How to solve it in PrestaShop

RKR Cookies shows «Reject all» and «Accept all» as identical buttons, which cannot be made to look different from the back office, and declares Consent Mode v2 at the very top of the <head>, in basic or advanced mode. The blocking is real: it rewrites the HTML to make scripts from non-accepted categories inert, replaces iframes with a notice offering «Load this content» and stops in the browser anything added by JavaScript, without ever blocking payment modules. It stores each decision with its snapshot and exports it to CSV, keeps a cookie inventory that fills itself in and a table for your policy. It imports the configuration from hicookielaw, Cookies Plus and EU Cookie Law, and has a test mode so you can see it before your customers do.

This article is for information only and is not a substitute for legal advice. For a specific case, consult your data protection adviser.