Propagation de Consent Mode vers GTM server-side

GTM server-side ne dispose pas de Consent Mode natif. Le conteneur web gère le consentement nativement. Le conteneur serveur reçoit l’état du consentement sous forme de paramètres HTTP encodés et doit être configuré pour les respecter — automatique pour les tags Google, manuel pour tous les autres fournisseurs.

Comment le consentement voyage vers le conteneur serveur

Lorsque le conteneur web envoie une requête à votre endpoint GTM server-side, il encode l’état actuel du consentement dans les paramètres de requête HTTP. Deux paramètres portent cette information :

gcs (Google Consent State) encode les paramètres de consentement v1. Le format est G1xy où :

• x = consentement ad_storage (1 = accordé, 0 = refusé)
• y = consentement analytics_storage (1 = accordé, 0 = refusé)

Ainsi, gcs=G111 signifie que ad_storage et analytics_storage sont tous deux accordés. gcs=G100 signifie que les deux sont refusés.

gcd (Google Consent Default) encode les quatre paramètres v2 ainsi que leur trajectoire de consentement. Chaque position de paramètre reçoit une lettre indiquant comment l’état du consentement a été atteint :

• l = refusé par défaut, aucune mise à jour reçue (l’utilisateur n’a pas interagi avec la bannière)
• q = refusé par défaut, puis mis à jour vers accordé (l’utilisateur a accepté)
• t = accordé par défaut, aucune mise à jour reçue (région où le consentement n’est pas requis, ou valeurs par défaut mal configurées)
• p et r = états intermédiaires

Ces paramètres font partie de la charge utile de la requête HTTP — ils voyagent avec les données d’événement dans la requête /g/collect du navigateur vers votre endpoint de conteneur serveur.

Tags Google : gestion automatique

Le Client GA4 dans votre conteneur serveur lit les paramètres gcs et gcd automatiquement depuis les requêtes entrantes. Il décode l’état du consentement et le rend disponible aux tags server-side.

Les tags de produits Google (GA4, Google Ads, Floodlight) dans le conteneur serveur ajustent ensuite leur comportement en fonction de l’état de consentement décodé. Si ad_user_data est refusé, le tag de suivi des conversions Google Ads n’inclura pas de données personnelles dans la requête qu’il transmet à Google. Si analytics_storage est refusé, le tag GA4 ajuste son comportement en matière de cookies.

Cette chaîne automatique fonctionne sans configuration supplémentaire, à condition que :

1. Le conteneur web définisse correctement les valeurs par défaut de consentement et traite les mises à jour CMP (voir Mécaniques d’implémentation de Consent Mode)
2. Les requêtes HTTP du conteneur web vers le conteneur serveur ne soient pas modifiées par des proxies intermédiaires, CDN ou équilibreurs de charge qui suppriment les paramètres de requête
3. Le Client GA4 dans le conteneur serveur soit celui qui revendique les requêtes entrantes

Tags non-Google : le vide manuel

C’est là que la plupart des implémentations de consentement server-side se brisent. Les tags de fournisseurs non-Google dans le conteneur serveur — Meta Conversions API, TikTok Events API, LinkedIn CAPI, Pinterest API, et tous les tags de requêtes HTTP personnalisées — ont zéro conscience des paramètres de consentement de Google. Ils ne lisent pas gcs ou gcd. Ils se déclenchent inconditionnellement sauf si vous construisez des vérifications de consentement explicites.

Cela crée une lacune de conformité. Un utilisateur en France refuse le consentement. Le conteneur web le respecte : il envoie des pings sans cookies avec gcs=G100. Le Client GA4 reçoit la requête et marque correctement le consentement comme refusé. Le tag GA4 server-side ajuste son comportement. Mais le tag Meta CAPI, assis dans le même conteneur serveur, déclenche son événement vers les serveurs de Meta avec toutes les données disponibles — potentiellement incluant l’adresse IP de l’utilisateur, l’agent utilisateur, et toutes les autres données d’événement arrivées dans la requête.

L’utilisateur a refusé le consentement. Vos tags Google l’ont respecté. Votre tag Meta l’a ignoré.

Construire des vérifications de consentement pour les tags non-Google

Pour appliquer le consentement aux tags de fournisseurs non-Google, vous devez créer des conditions de déclencheur qui évaluent l’état du consentement avant que le tag se déclenche.

Utiliser la variable d’état de consentement

Dans GTM server-side, vous pouvez accéder à l’état de consentement décodé via les données d’événement. Le Client GA4 analyse gcs et gcd et expose les informations de consentement. Créez une variable de type “Event Data” qui lit l’état du consentement, puis utilisez-la comme condition de déclencheur :

Déclencheur : Custom Event
Condition : x-ga-gcs matches RegEx G1[1][1]

Cela garantit que le tag ne se déclenche que lorsque ad_storage et analytics_storage sont tous deux accordés. Pour les paramètres v2, vous devrez analyser le paramètre gcd pour les positions de paramètre spécifiques.

Une approche plus robuste

Un pattern plus propre consiste à créer un template de variable personnalisé ou à utiliser un template de la communauté qui analyse l’état complet du consentement et retourne des valeurs de paramètres individuels. Vos conditions de déclencheur deviennent alors explicites :

Tag : Meta CAPI - Événement Purchase
Conditions de déclencheur :
  - Event Name égal à "purchase"
  - ad_user_data égal à "granted"
  - ad_storage égal à "granted"

Cela rend l’application du consentement visible et auditable. Chaque tag non-Google a des conditions de déclencheur explicites documentant quels signaux de consentement il requiert.

Configuration du consentement au niveau du tag

Certains templates de tags server-side (en particulier les plus récents construits avec une conscience du consentement) acceptent l’état du consentement comme paramètres d’entrée. Si votre template Meta CAPI le supporte, passez l’état du consentement depuis les données d’événement analysées directement dans la configuration du tag. Le tag peut alors prendre ses propres décisions sur les données à inclure ou à supprimer.

Échecs courants de consentement server-side

Paramètres supprimés. Si votre conteneur serveur est derrière un CDN ou un proxy inverse qui modifie les chaînes de requête, gcs et gcd pourraient être supprimés ou tronqués. Vérifiez en inspectant la requête entrante dans le mode Preview de GTM server-side — cherchez les deux paramètres dans les données d’événement.

Mauvais Client revendiquant la requête. Si vous avez plusieurs Clients dans votre conteneur serveur et que le mauvais revendique la requête entrante, les paramètres de consentement pourraient ne pas être correctement analysés. Le Client GA4 sait spécifiquement comment décoder l’encodage de consentement de Google. Un Client HTTP générique ne le sait pas.

Supposer que server-side signifie que le consentement est géré. Certaines équipes implémentent GTM server-side partiellement pour des raisons de confidentialité et supposent que le conteneur serveur gère le consentement de manière inhérente. Ce n’est pas le cas. Déplacer les tags côté serveur change l’endroit où ils s’exécutent, pas s’ils respectent le consentement. Sans configuration explicite, les tags server-side sont moins conscients du consentement que les tags côté client, pas plus.

Sensibilité à la casse dans les conditions de déclencheur. Les conditions de déclencheur GTM server-side sont sensibles à la casse. Si votre Client GA4 est nommé ga4 mais qu’une condition de déclencheur vérifie GA4 dans le champ Client Name, rien ne se déclenche. Cela casse l’intégralité de votre configuration server-side, consentement compris.

La position de conformité

Pour une infrastructure de conformité complète, chaque tag server-side doit avoir des exigences de consentement documentées. Construisez un mappage :

Ce mappage devient votre artefact d’audit. Quand un examen de confidentialité demande “comment appliquez-vous le consentement pour les événements Meta server-side ?”, la réponse est documentée dans la configuration de votre conteneur serveur, pas dans un document de politique qui peut ne pas refléter la réalité.