Comment transmettre le signal de consentement à un conteneur de marquage côté serveur

Tous les articles

Configurez Consent Mode v2 dans votre conteneur GTM web pour que l'état soit défini avant le déclenchement de toute balise. Google l'attache ensuite à la requête qu'il envoie plus loin, sous la forme du paramètre gcs, si bien que rien n'a besoin d'être envoyé deux fois. Dans le conteneur serveur, lisez cet état, conditionnez chaque balise fournisseur dessus, et vérifiez que votre client GA4 ne restaure pas discrètement un identifiant.

Le signal n'emprunte pas un chemin séparé

L'erreur de conception habituelle consiste à traiter le consentement comme quelque chose dont il faut informer le conteneur serveur séparément, par une deuxième intégration. L'état choisi par le visiteur est attaché à la même requête que celle qui porte l'événement : si le côté web est correct, le côté serveur l'a déjà.

Cela a une conséquence qu'il vaut mieux énoncer clairement, parce qu'elle détermine où aller quand quelque chose casse : un conteneur serveur ne peut pas réparer un problème de consentement. Il n'a pas de bannière et personne à qui demander. Si l'état n'est jamais parti correctement du navigateur, chaque condition que vous construisez là-bas interroge un champ vide. Le volet obligation est traité dans faut-il encore une bannière de cookies avec le marquage côté serveur.

Comment transmettre le signal de consentement à un conteneur de marquage côté serveur

1. Définissez Consent Mode v2 dans le conteneur web, pas dans celui du serveur

   Le consentement se décide dans le navigateur et se configure dans votre conteneur GTM web : la CMP fixe une valeur par défaut denied pour chaque signal non essentiel avant l'initialisation de toute balise, puis la met à jour quand le visiteur choisit. Le conteneur serveur n'a ni bannière ni visiteur à qui demander : il n'est donc jamais l'endroit où corriger un problème de consentement.

2. Vérifiez que l'état est bien présent sur la requête sortante

   Dans une fenêtre de navigation privée, trouvez la requête que vos balises Google envoient au conteneur serveur. Elle doit déjà porter un paramètre gcs : G100 quand les deux types de stockage sont refusés, G111 quand les deux sont accordés, G101 et G110 pour les cas mixtes. G1-- signifie que la balise s'est déclenchée sans état de consentement attaché et que tout ce qui suit avance à l'aveugle.

3. Lisez l'état de consentement dans le conteneur serveur

   Ouvrez le preview du conteneur serveur et inspectez un événement entrant. L'état arrive avec la requête et s'y lit directement, ce qui permet à une balise de décider si elle doit se déclencher. Créez des variables nommées pour les signaux qui servent de condition, plutôt que de lire des champs bruts sur chaque balise.

4. Conditionnez chaque balise fournisseur au signal dont elle a réellement besoin

   Chaque balise reçoit une condition de déclenchement liée à la bonne catégorie, et les catégories ne sont pas interchangeables. Les balises analytics vérifient le signal analytics. Les destinations publicitaires, dont une conversions API, vérifient les signaux publicitaires, et la version 2 en a ajouté deux que les configurations plus anciennes ne contrôlent jamais. Une balise sans condition se déclenche sur tout, refus compris.

5. Vérifiez ce que votre client GA4 fait des cookies

   L'étape qu'aucun guide n'inclut, et celle qui défait discrètement les quatre autres. Le client GA4 a un paramètre de cookies. Laissé sur l'option server managed, il génère et restaure son propre identifiant propriétaire : il peut donc attacher un id persistant à un ping censé être anonyme. Réglez-le sur javascript managed pour que le client utilise l'identifiant envoyé par le navigateur, et rien de plus.

6. Vérifiez avec un refus, pas avec une acceptation

   Tout le monde teste en acceptant, parce que c'est le chemin où les données apparaissent. Refusez plutôt, dans une fenêtre de navigation privée propre, puis suivez cet unique événement : l'état sur la requête, l'état dans le conteneur, les balises qui se sont déclenchées, et l'identifiant parti vers chaque fournisseur.

La défaillance qui survit à une configuration correcte

Les étapes une à quatre sont celles que tous les guides couvrent, et une configuration qui les passe a l'air terminée. L'étape cinq est celle que nous continuons de trouver dans des conteneurs soigneusement construits, et elle ne ressemble en rien à un bug de consentement.

Le schéma est le suivant : la bannière est correcte, la valeur par défaut est denied, l'état arrive intact dans le conteneur, et les balises fournisseurs sont conditionnées correctement, si bien qu'un événement refusé ne déclenche aucune balise publicitaire. Tout ce que vous testeriez passe. Pendant ce temps, le client GA4 gère ses propres cookies : à chaque requête, il génère ou restaure un identifiant propriétaire (first party) et l'inscrit sur l'événement. Un ping censé partir anonyme s'en va avec un id stable.

Le symptôme ne pointe jamais vers le consentement. Il se lit comme des volumes légèrement trop élevés, et des sessions qui auraient dû rester non attribuées qui arrivent attribuées. Nous avons tracé exactement cela lors d'une session de debug en direct sur un conteneur serveur, et le correctif tenait à un seul paramètre. Rien n'a changé du côté des conditions de déclenchement, parce qu'elles n'avaient jamais été fausses.

La leçon se généralise. Conditionner les balises et contrôler l'identifiant sont deux travaux différents. Une condition décide si une requête atteint un fournisseur. Un identifiant décide si ce fournisseur peut savoir de qui il s'agissait. La documentation couvre le premier point et reste muette sur le second : un conteneur peut suivre les recommandations à la lettre et distribuer quand même de l'identité.

Ce que vaut le câblage quand il tient

Sur l'ensemble des implémentations clients d'Amplio Data, la référence mesurée tourne autour de 34% des sessions bloquées derrière la bannière, avec 20 à 40% des conversions perdues récupérables une fois que le consentement est réglé comme Google l'attend et que l'identifiant est traité honnêtement. Ces chiffres sont des fourchettes mesurées sur les implémentations clients d'Amplio Data, pas une garantie. La récupération dépend de votre mix de trafic, de vos régions et de la configuration de vos balises.

Cette récupération vient de la modélisation et du trafic autorisé correctement attribué, jamais d'une réidentification silencieuse des personnes qui ont refusé. Un conteneur qui laisse fuir un identifiant ne récupère pas des données, il collecte des données qu'on lui a refusées, et le fait que cela flatte le tableau de bord est précisément ce qui le dissimule.

La version courte

Le consentement se décide dans le navigateur et se configure dans le conteneur web. Il atteint le serveur sur la requête elle-même, dans gcs, sans deuxième intégration. Lisez-le là, conditionnez chaque balise fournisseur à la catégorie dont elle a besoin, et réglez le client GA4 pour qu'il utilise l'identifiant envoyé par le navigateur au lieu d'en générer un. Puis vérifiez-le sur un événement refusé. La procédure côté navigateur est dans comment vérifier que votre bannière envoie bien le signal, et le mode que vous faites tourner est traité dans Consent Mode basique ou avancé.

Velo définit les quatre signaux depuis un seul extrait de code avant l'initialisation de vos balises, ce qui constitue la moitié amont de ce qui précède. Le mécanisme est décrit sur la page produit.

Si vous construisez le conteneur lui-même, et pas seulement le câblage du consentement, l'équipe derrière Velo tient une checklist complète de ce qu'exige une configuration côté serveur en production dans les bonnes pratiques du marquage côté serveur pour 2026 sur le blog d'Amplio Data.