Setting up a consent banner is good. But to be truly compliant, you must translate your visitors' choices (or lack thereof) into concrete technical actions.
Thus, your site must behave differently based on the user's consent status :
✅ If the user consents to a service :
→ You can load the service and execute the associated scripts.
❌ If the user explicitly refuses the service :
→ The service must not be loaded, and no data should be transmitted to this service.
🕓 If the user has not yet interacted with the banner (consent not expressed) :
→ By default, the service must be blocked until a choice is made.
This conditional behavior is called consent conditioning logic. It ensures that services subject to consent are only triggered when authorized, and remain blocked in all other cases.
In practice, this logic can be implemented in two ways :
either manually in your site's code, by writing conditions (for example: "if the user has consented to this service, then load this script") ;
or via a visual interface like that of a tag manager, which allows you to define these rules without coding. The tag manager then takes care of translating these rules into executable logic on the browser side.
How are services called on your site?
How are services called on your site?
For each service you have listed, it is important to verify how it is loaded on your site. There are several ways to integrate a third-party service, but in most cases, there are two main approaches :
The script is integrated directly into the code of your pages ("hardcoded"), often copied from the documentation of the service in question.
The service is loaded via a Tag Manager (such as Google Tag Manager), either by pasting the code into a custom HTML tag, or by using a tag template provided by the service.
In some cases, you may also encounter :
CMS plugins (WordPress, Shopify…) that automatically integrate third-party services,
iframes (e.g.: YouTube, Google Maps),
or dynamic calls inserted via JavaScript frameworks.
Other cases may exist, such as services loaded via CMS plugins, iframes or dynamically injected scripts, but these two methods cover the majority of cases encountered.
Our recommendation: centralize your scripts in your Tag Manager
Our recommendation: centralize your scripts in your Tag Manager
If you already use Google Tag Manager (or another tag manager), we strongly advise you to centralize all your services within it. Here's why :
You will have a unified view of all third-party services you load,
You will be able to easily manage consent conditioning thanks to GTM's trigger system,
And most importantly, you will avoid having to modify your site's code, which can be complex if you are not comfortable with development.
👉 In practice, for each script you found hardcoded on your pages, create a tag in GTM to replace it, then remove the hardcoded code from the site. This will allow you to manage everything properly from GTM, including triggering based on Axeptio consent.
What if you don't use a Tag Manager?
What if you don't use a Tag Manager?
If you have integrated your services directly into your site's code and are not using a Tag Manager, you can still manage the conditioning logic manually. You will find code snippets to help you develop this logic in our dedicated article.
This involves :
listening to the Axeptio consent status,
and only executing third-party scripts once consent is given.
This is a more technical solution, which requires development resources, but which allows fine-grained control over site behavior.
Remember: simply displaying a consent banner is not enough. If you do not implement this conditioning logic, your visitors can refuse a service... which will still continue to load in the background.
To be compliant, services must be blocked until the user has given consent, and triggered only if they have.
🧪 Concrete example: conditioning the triggering of a Facebook Pixel
To illustrate this conditioning logic, let's take a concrete case you might encounter.
Identify the service and its status
You have scanned your site with Shake, and the PDF report tells you that a Facebook Pixel is present on certain pages.
➡️ This service is listed as collecting personal data. It must therefore be subject to consent.
Verify how the service is integrated
You now ask yourself the following question :
👉 How is the Facebook Pixel loaded on my site?
Upon verification, you notice that :
The Pixel is not integrated directly into the code of your pages,
It is loaded via Google Tag Manager, in the form of a custom HTML tag or using the Facebook tag template provided in GTM.
Condition the triggering in GTM
Since you are using GTM, you will be able to condition the triggering of the Facebook Pixel tag to the Axeptio consent status.
Result: the Facebook Pixel will only be triggered if the user has given consent to this service via the Axeptio banner.
If the user refuses, or does not respond, the Pixel will not be triggered.
💡 What if the script was integrated "hardcoded"?
In that case, you should have added a condition to your code to listen to the consent status and only trigger the Facebook script if explicitly agreed.