Comment implémenter le consentement utilisateur en Server-Side ?

Le RGPD (Règlement Général sur la Protection des Données), instauré en mai 2018, a pour objectif de protéger la vie privée des citoyens, de garantir une utilisation éthique des données personnelles et de responsabiliser les entreprises face à ces enjeux. Il est essentiel pour préserver les droits des individus.

Ne vous y trompez pas : le Server-Side n’est pas un outil de contournement des obligations légales imposées par le RGPD. Avec une migration de votre tracking côté Serveur, vous devez toujours :

• Collecter le consentement utilisateur sur votre site via votre bannière CMP (Consent Management Platform).
• Respecter ce choix en déclenchant ou non les différents tags (Analytics et Média) selon la décision de l’utilisateur.

Mais comment gérer le consentement avec un tracking Server-Side ? Que faire du Google Consent Mode v2 ? Faut-il l’implémenter en mode basique ou avancé ? Comment transporter les informations de consentement vers votre conteneur serveur ? La question du consentement reste complexe, car il existe autant d’implémentations différentes que de bannières CMP (Axeptio, Didomi, OneTrust…).

Pour configurer le consentement utilisateur en serveur-side, il vous faut :

• Une CMP (Plateforme de gestion du consentement) comme Axeptio, Didomi, OneTrust, etc., implémentée soit directement sur votre site, soit via GTM Web.
• Un conteneur Google Tag Manager Web.
• Un conteneur GTM Serveur.

Enfin, et pour une meilleure compréhension du sujet, nous allons scinder nos explications sur le consentement avec:

• une première étape pour la gestion du consentement des tags liés aux produits Google (Google Ads, Google Analytics 4, Floodlight)
• puis nous verrons en étape 2 comment déclencher les autres tags (Facebook, Pinterest, LinkedIn…)

Première étape : paramétrer le consent mode V2 pour les tags Google

Le Consent Mode V2 vous permet de recueillir le consentement utilisateur, et de l’envoyer à Google pour qu’il puisse traiter les données sur ses différents outils (Google Analytics, Google Ads, Floodlight).

Le fonctionnement est simple :

• La bannière de consentement sur votre site web collecte les choix de consentement des utilisateurs et les transmet à la balise Google située dans votre conteneur WEB.

• Cette balise Google communique ensuite les préférences des utilisateurs au conteneur serveur en intégrant des paramètres de consentement dans la requête HTTP.

Les préférences des utilisateurs sont envoyés à Google via 4 paramètres clés :

• analytics_storage : permet le stockage des données nécessaires à l’analyse d’audience (sur un outil comme Google Analytics 4)
• ad_storage : permet le stockage des informations utilisées à des fins publicitaires.
• ad_personalization : définit le consentement de l’utilisateur pour la diffusion de publicités personnalisées.
• ad_user_data : définit le consentement de l’utilisateur pour le partage de données avec Google en vue du ciblage publicitaire.

Enfin, sachez que le Consent Mode v2 existe sous deux versions : Basic ou Advanced. Nous allons détailler ci-dessous les différences de ces 2 versions pour que vous puissiez implémenter celle qui vous convient le mieux.

Mode de consentement Basic

Dans cette version du Consent mode, les tags sont bloqués si l’utilisateur refuse le consentement. Dans ce cas, aucune donnée n’est envoyée aux plateformes partenaires. Seule la donnée consentie par l’utilisateur est donc envoyée. Pour bien comprendre l’impact sur les données envoyées, prenons l’exemple ci-dessous.

Dans ce cas, des restrictions doivent être ajoutées dans l’implémentation côté GTM SERVER sur le déclenchement des tags Google Ads et Google Analytics. Dans notre exemple, l’utilisateur n’a pas consenti aux publicités (le paramètre ad_storage a donc la valeur “denied”), mais il a donné son accord pour le suivi analytics. Grâce à la restriction, aucune donnée n’est envoyée à Google Ads.

Mode de consentement Advanced

Dans cette version du Consent Mode V2, les balises Google se déclenchent toujours côté Web et côté Serveur, que l’utilisateur ait consenti ou non. En cas de non-consentement, elles envoient donc toujours de la donnée, mais via des pings anonymisés et sans cookies.

Une fois le Consent Mode V2 implémenté, un paramètre supplémentaire (GSC) est envoyé dans vos requêtes, indiquant à Google si les données doivent être anonymisées ou non.

Ci-dessous un tableau qui vous permet de décoder ce paramètre GSC et de savoir si les cookies marketing et/ou analytics ont été consentis :

En mode Advanced, vous ne faites donc aucune configuration supplémentaire côté GTM Serveur. Vous ne bloquez plus aucun tag Google vous-même, puisque Google reçoit le paramètre GSC et gère en autonomie la façon dont il traite les données de son côté. S’il n’y a pas de consentement sur le marketing par exemple (ad_storage a pour valeur "denied"), les données sont toujours envoyées à Google Ads, mais elles sont anonymisées par Google avant d’être traitées.

Deuxième étape : gestion du consentement pour les tags hors produits Google

Pour les tags hors Google (Facebook, Pinterest, LinkedIn ou autres), il vous faut toujours :

• Collecter le consentement utilisateur pour les produits hors Google sur votre site via votre bannière CMP. La collecte du consentement s’effectue donc côté Web.
• Envoyer les paramètres de consentement à votre GTM Serveur via votre balise Google.
• Respecter le choix en déclenchant ou non les différents tags côté Serveur selon la décision de l’utilisateur.

1. Collecter le choix utilisateur côté GTM WEB

Pour cela, plusieurs méthodes existent et diffèrent. Selon le paramétrage de votre bannière CMP, vous pouvez soit choisir :

• de collecter un consentement utilisateur pour chaque prestataire présent dans votre setup de tracking (un consentement pour Meta, un autre pour Pinterest Ads…).
• de collecter le consentement de manière plus globale et ne demander à vos utilisateurs de consentir de manière groupée pour chaque type de cookies (marketing, analytics…).

Une fois le consentement utilisateur récupéré, une CMP stocke en général la liste des prestataires acceptés ou refusés soit:

• via un cookie first-party déposé par la CMP (Par exemple Axeptio stocke la liste des partenaires qui ont été consentis par l’utilisateur dans le cookie axeptio_authorized_vendors)
• via un événement datalayer (Sur Didomi par exemple, l’événement “didomi-consent” est envoyé avec une variable Didomi Vendors Enabled contenant la liste des partenaires pour lequel l’utilisateur a donné son consentement).

Dans notre exemple, notre bannière CMP est Axeptio. Elle stocke dont un cookie axeptio_authorized_vendors contenant la liste des cookies acceptés par l’internaute. Dans notre cas, la valeur du cookie contient “facebook” puisque le consentement est bien donné par l’utilisateur pour Meta. Mais il ne contient pas “pinterest” car l’internaute a refusé les cookies pour ce prestataire. (ceci est donné purement à titre d’exemple, il vous faut vérifier le fonctionnement de votre bannière CMP).

Nous pouvons donc, côté GTM WEB, créer une variable “1st Party Cookie”, pour récupérer l'ensemble des prestataires pour lesquels l'utilisateur a donné son consentement :

2. Envoi du statut de consentement vers votre GTM SERVEUR

Une fois la collecte de données de consentement effectuée côté WEB, il faut vous assurer d’envoyer le statut du consentement pour chaque prestataire (ou pour chaque type de cookies) à votre conteneur Serveur.

C’est via votre tag Google de configuration GA4 côté WEB que vous pouvez transmettre ces informations à votre serveur.

Il suffit d’ajouter un paramètre additionnel (par exemple : consent_status) sur votre balise Google pour envoyer le statut du consentement à votre serveur:

Dans notre exemple, nous envoyons sur ce paramètre consent_status la liste de tous les prestataires qui ont été acceptés par l’utilisateur. La variable 1st Party précédemment créé est donc utilisée ici. Elle contient (toujours dans notre exemple) “facebook”, mais pas “pinterest” qui n’a pas été accepté par l’utilisateur.

3. Paramétrer les déclencheurs des tags côté GTM SERVEUR en fonction du consentement

Enfin, côté Serveur, vous pouvez récupérer le paramètre de consentement (consent_status dans notre cas) dans les Event Data, et ne choisir de déclencher un évènement que si l’utilisateur a bien consenti en amont.

Pour poursuivre sur notre exemple, les déclencheurs des tags Meta et Pinterest doivent être modifiés, pour ne se déclencher que si l’utilisateur a consenti en amont.

Il faut tout d'abord créer une variable Event Data pour récupérer le paramètre consent_status envoyé au conteneur sGTM et la valeur associée:

Dans notre cas, la variable consent_status ne contient “facebook” que si l’utilisateur a donné son consentement pour Meta, et ne contient pas “facebook” dans le cas contraire...

Il faut donc ensuite modifier le déclencheur de votre tag Meta, pour ajouter une condition de déclenchement supplémentaire. Si la variable Event Data créé précédemment contient “facebook”, alors le tag Meta se déclenchera, mais pas dans le cas contraire :

Idem pour Pinterest, il faut ajouter dans votre déclencheur une condition via la variable Event Data, mais cette fois-ci y intégrer la valeur “pinterest” (qui est envoyée par notre CMP en cas de consentement utilisateur pour Pinterest).

Ainsi vos tags “Meta CAPI” et “Pinterest CAPI” ne se déclenchent que si l’utilisateur a bien accepté les cookies pour chacun d’entre eux ! N'oubliez pas d'apporter les mêmes restrictions à tous vos tags coté serveur !

Si vous rencontrez une difficulté durant ces étapes, n'hésitez pas à contacter notre équipe support.