CookiePass et Google Consent Mode : ce qu’une bannière de consentement fait à votre trafic

Consent Mode n’est pas un interrupteur pour vos balises. Avec lui, la balise Google continue de se déclencher sur chaque page ; ce qui change, c’est un indicateur sur chaque hit, et ce que Google en fait. Quand analytics_storage est refusé, la balise ne pose aucun cookie, ne conserve aucun client id entre les pages et envoie ce que Google appelle un ping sans cookie — un hit que GA4 utilise pour la modélisation, pas pour les rapports que vous lisez.

L’indicateur est un paramètre de requête nommé gcs : deux lettres et deux chiffres. Le premier chiffre est ad_storage, le second analytics_storage ; 1 pour accordé, 0 pour refusé.

gcs=G100   ad_storage denied,  analytics_storage denied
gcs=G101   ad_storage denied,  analytics_storage granted
gcs=G110   ad_storage granted, analytics_storage denied
gcs=G111   both granted
(no gcs)   no Consent Mode on the page — treated as granted

La dernière ligne est celle qu’on oublie. Une page sans Consent Mode n’envoie pas de gcs, et Google traite chacun de ses hits comme consenti. Ajouter une bannière qui implémente Consent Mode ne réduit donc pas ce qui est envoyé : cela commence à dire la vérité à son sujet.

Consent Mode v2 exige une séquence, pas un réglage. L’état par défaut doit être déclaré avant le chargement de la balise Google — refusé pour quiconque n’a pas encore choisi —, une mise à jour doit suivre dès que le visiteur décide, et cet état doit être restauré à chaque visite suivante. Si l’ordre est faux, la première page vue de chaque session part comme consentie avant même que la bannière soit affichée.

Voici la séquence que CookiePass produit depuis son propre script, si bien que rien de tout cela n’atterrit dans votre conteneur Tag Manager :

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});

// …the visitor accepts…
gtag('consent', 'update', {
  ad_storage: 'granted',
  analytics_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

C’est toute l’intégration. Les balises de Google respectent l’état de consentement automatiquement, y compris celles que SignalHost publie dans votre conteneur web. Rien dans votre conteneur serveur n’a besoin d’une condition de consentement ; en ajouter une à la main, c’est ainsi qu’une balise Google bloquée se retrouve à côté de balises d’événement non bloquées qui envoient les données directement à Google.

Chaque hit suit toujours le même chemin : le navigateur l’envoie à votre propre nom d’hôte, l’edge le transmet à votre conteneur serveur, et le conteneur l’envoie à GA4. La différence est entièrement dans la charge utile.

• Avant le choix : gcs=G100 sur chaque hit, pas de cookie _ga, et un nouveau client id à chaque page. GA4 reçoit un ping sans cookie ; votre conteneur compte une requête.
• Après acceptation : gcs=G111, les cookies sont posés et la session se reconstitue. À partir de là, ce sont les hits dont vos rapports sont faits.
• Après refus : gcs=G100 sur chaque page tant que le choix tient. Les événements de la mesure améliorée — scroll, file_download et les autres — suivent la même règle que page_view.

C’est pourquoi la page conteneur affiche deux nombres par événement dès qu’une bannière est en place : les hits envoyés avec consentement analytics — ce qu’Analytics affichera comme utilisateurs et sessions — et, après la barre, tout ce que le conteneur a transmis. session_start et first_visit n’apparaissent dans aucune colonne : Analytics les déduit d’indicateurs sur le premier page_view plutôt que de les recevoir comme événements.

Attendez-vous à ce que les deux colonnes divergent, et à ce que l’écart soit le chiffre le plus utile de la page.

• Analytics rapporte moins d’utilisateurs et de sessions que votre conteneur ne compte de requêtes. La différence est la part des visiteurs qui ont refusé ou jamais répondu : votre taux de consentement, mesuré plutôt qu’estimé.
• GA4 peut combler une partie de cet écart par modélisation comportementale, une fois la propriété au-dessus des seuils de Google. Les données modélisées apparaissent dans les rapports ; jamais dans votre conteneur, puisqu’elles ne sont jamais envoyées.
• Avec ad_storage refusé, le suivi des conversions Google Ads n’a rien à attribuer et le conversion linker rien à relier. Un conteneur serveur ne change pas cela, et ne le devrait pas : first-party ne veut pas dire sans consentement.
• Le design de la bannière est désormais une décision de mesure. Un taux de 60 % et un taux de 85 % sont le même site avec d’autres boutons, et l’écart entre les colonnes vous dira lequel vous avez.

• Chargez le script de consentement avant la balise Google. L’état par défaut doit exister avant le premier hit.
• Ouvrez une page avec la bannière sans réponse et lisez gcs sur une requête /g/collect dans le panneau réseau du navigateur. Il doit indiquer G100.
• Acceptez, puis relisez-le sur la page suivante. Il doit indiquer G111.
• N’ajoutez aucun déclencheur de consentement dans le conteneur serveur. La balise web porte déjà l’état.
• Revenez sur la page conteneur un jour plus tard et lisez la paire de nombres sur page_view. Le premier divisé par le second est votre taux de consentement.

Nous avons choisi CookiePass parce qu’il fait exactement la séquence ci-dessus, qu’il était en production sur ce site en un après-midi, et qu’il laisse la bannière prendre les couleurs du site. Les chiffres de la section précédente sont la preuve que cela fonctionne.