Configuring 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 react differently depending on the user's consent status:

✅ If the user gives consent for a service:

→ You can load the service and execute associated scripts. - ❌ If the user explicitly refuses the service:

→ The service must not be loaded, and no data should be transmitted to that service. - 🕓 If the user has not yet interacted with the banner (consent not expressed):

→ By default, the service must be blocked until a choice has been made.

This conditional behavior is called consent conditioning logic. It ensures that services subject to consent only trigger when authorized, and remain blocked in all other cases.

Concretely, this logic can be implemented in two ways:

either manually in your site's code, by writing conditions (for example: "if the user 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?

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, you will find 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 in 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 (ex: 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

If you already use Google Tag Manager (or another tag manager), we strongly advise you to centralize all your services in 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.

👉 Concretely, 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?

If you have integrated your services directly into your site's code and are not using a Tag Manager, you can still manage consent conditioning logic manually. You will find code snippets to help you develop this logic in our dedicated article.

This involves:

listening to Axeptio's 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 control over your site's behavior.

Remember: simply displaying a consent banner is not enough. If you do not implement this consent conditioning logic, your visitors can refuse a service... which will continue to load anyway under the hood. To be compliant, services must be blocked until the user has given permission, and triggered only if they have.

🧪 Concrete example: conditioning the triggering of a Facebook Pixel

To illustrate this consent 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 indicates that a Facebook Pixel is present on certain pages.

➡️ This service is not strictly necessary for the site to function and deposits information on the visitor's device. 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 checking, you find 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 via the Facebook tag template offered in GTM.

Condition the triggering in GTM

Since you use GTM, you will be able to condition the triggering of the Facebook Pixel tag to Axeptio's 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 trigger.

💡 What if the script was hardcoded?

In that case, you would have had to add a condition in your code to listen to the consent status and only trigger the Facebook script with explicit agreement.

Manage the logic of consent conditioning