Consent mode is the mechanism by which your measurement and advertising tools adapt their behaviour to what the visitor has accepted. Setting it up has become a condition of access to certain advertising features in Europe, and it is often done halfway.
The general rules of the cookie banner have been covered separately. This article deals with the technical articulation with the measurement tools.
The principle
Without consent mode, your choice is binary: either the measurement script loads, or it does not.
With consent mode, the script loads in a restricted state as long as the visitor has not accepted. It writes no cookie, it transmits no identifier, and it can send signals stripped of personal data.
Two practical consequences. You keep aggregated measurement on visitors who decline. And the move from refusal to acceptance is taken into account immediately, with no page reload.
A point not to confuse: this mechanism does not remove the need for consent. It defines what your tools do in its absence.
The four signals
The setup rests on four indicators, each granted or denied independently.
Two concern audience measurement: storage for analytics purposes, and transmission of measurement data.
Two concern advertising: advertising storage, and use of data for personalisation or ad measurement.
Three implementation rules.
Each signal must map to a purpose in your banner. If your banner offers “audience measurement” and “advertising”, the mapping is straightforward. If it only offers a global choice, you cannot set the signals correctly.
All signals must be declared, even the ones you do not use. A missing signal is treated as unset, which is not the same thing as denied.
The default state is denial, until the visitor chooses.
Execution order, the critical point
This is the most frequent technical error and it makes the whole setup inoperative.
The default state must be declared before the measurement scripts load. If the script loads first and the state arrives afterwards, the first event goes out with the tool’s own defaults, which is to say with no restriction.
In practice the sequence is: declaration of the default state, then loading of the tag manager, then update of the state when the visitor chooses.
On PrestaShop this means the declaration code must be injected very high in the page, before any other measurement script. A consent module that loads after the tag manager cannot work correctly.
Check: look at the order of the scripts in the source of your home page. The state declaration must come before everything else.
DataFirefly Cookie Manager — powered by the open-source tarteaucitron.js engineThe GDPR-compliant cookie banner without giving up measurement.€220.00
Prior blocking is still necessary
A frequent confusion worth clearing up.
Consent mode governs the behaviour of the tools that support it. It does not block the others.
Your chat, map, embedded video, customer review or behavioural testing scripts know nothing about it. They must be blocked by your consent setup, as before.
The correct configuration therefore combines two mechanisms: prior blocking for everything that drops trackers without supporting it, and consent mode for the compatible tools.
An error to avoid: believing that implementing consent mode removes the need for blocking. It only covers part of your page.
Updating at the moment of choice
Three implementation points.
The update must be immediate, with no page reload. A visitor who accepts must see full measurement activate on their current session.
It must reflect the choice per purpose, not apply a blanket agreement. A visitor accepting measurement and declining advertising must produce two granted signals and two denied ones.
The choice must be stored and reapplied on every visit, until it expires.
A complementary point: withdrawing consent must also update the signals, in the other direction. A setup that only handles acceptance is incomplete.
What you measure when consent is refused
A legitimate question, and the answer deserves nuance.
In the restricted state, the tools can transmit signals with no identifier and no cookie. Those signals allow an estimate of the behaviour of visitors who declined, through modelling.
Three honest clarifications.
That estimate is a model, not a measurement. It produces orders of magnitude, not exact figures.
It requires a sufficient volume of observed data to be computed. On a small store it may not be available at all.
It does not restore what the refusal removed. It softens the loss, it does not cancel it.
Presenting this mechanism as a way to “recover lost conversions” is an overreading that circulates widely.
Checking that it works
Four checks, all doable in the browser.
Before any choice, open the console and look at the outgoing requests. Measurement calls may go out, but with no cookie and with the parameters indicating the restricted state.
After a refusal, confirm that no measurement or advertising cookie is dropped.
After an acceptance, confirm that the cookies appear and that the calls carry the expected identifiers.
On a return visit, confirm that the previous choice is reapplied without asking again.
Add a check in the measurement tool itself, which usually exposes a report on the state of the signals received. That is where the inconsistencies the console does not show become visible.
Frequent errors
A single signal set. Some configurations only declare analytics storage and leave the other three unset.
The default state granted. A serious error: it amounts to collecting before consent.
Approximate mapping. A “marketing” purpose in your banner mapped onto all four signals at once, which does not respect the visitor’s choice.
The setup missing on some pages. The checkout funnel or advertising landing pages sometimes escape the banner, through a different page template.
That last case is the most damaging: the pages that matter most to your measurement are the ones where the setup is missing.
The articulation with server-side sending
A point to handle if you transmit events from your server.
Server-side sending does not go through the browser, so it is unaware of the signal state unless you pass it explicitly.
Two consequences. Your server implementation must know the visitor’s consent state, which means storing it and associating it with the session.
And it must condition or restrict the sending accordingly. Transmitting advertising data from the server for a visitor who declined it in the browser is a circumvention, not an optimisation.
The Cookie Manager for PrestaShop implements this chain on PrestaShop 8 and 9: declaration of the default state before any measurement script, mapping between the banner purposes and the four signals, immediate update on choice and prior blocking of the third-party scripts that do not support the mechanism.
