Une bannière de cookies devant le tagging côté serveur : ce qui change, et ce qui ne change pas

Un nom d’hôte first-party est une propriété technique d’une requête. Ce n’est pas une permission. Si vous aviez besoin d’un consentement hier pour déposer un cookie d’analyse, vous en avez besoin aujourd’hui, et le fait que le cookie soit désormais déposé par metrics.votresite.com au lieu de google-analytics.com n’y change rien. La question du régulateur est ce que vous collectez et pourquoi, pas quel serveur le paquet a visité en chemin.

Ce qui change, c’est où va une requête bloquée. Les bloqueurs de publicité et les fonctions de confidentialité des navigateurs bloquent par nom d’hôte et par motif d’URL, et ils bloquent googletagmanager.com. Ils ne bloquent pas votre propre domaine. Un visiteur qui a consenti et qu’une liste de filtres aurait silencieusement écarté est donc désormais compté. C’est tout le bénéfice, et ce n’est un bénéfice que pour les visiteurs qui ont consenti.

Les balises Google lisent un état de consentement composé de quelques autorisations nommées — analytics_storage, ad_storage, ad_user_data, ad_personalization — et ajustent ce qu’elles envoient. Avant que le visiteur décide, un gestionnaire de consentement pousse une valeur par défaut denied ; quand il choisit, il pousse une mise à jour. À l’état denied, la balise Google se déclenche quand même mais envoie un ping sans cookie : pas d’identifiant client, pas de cookie, un signal qu’une page a été vue et rien de plus. Une fois analytics_storage passé à granted, elle envoie le hit complet. Le conteneur serveur reçoit ce qui a été envoyé, et les signaux de consentement voyagent avec le hit, donc la balise GA4 côté serveur se comporte de la même façon.

Le gestionnaire de consentement doit se charger avant la balise Google, pour que sa valeur par défaut soit en place quand la balise s’évalue pour la première fois. La plupart des gestionnaires fournissent une valeur wait_for_update exactement pour cela — quelques centaines de millisecondes pendant lesquelles la balise attend un état de consentement avant de supposer denied.

Les entités que SignalHost crée dans votre conteneur ne portent aucune condition de consentement. C’est délibéré. Les balises de Google elles-mêmes respectent Consent Mode ; une vérification de consentement ajoutée à la main sur la balise Google, sans rien sur les balises d’événement GA4 en dessous, est la première des deux erreurs ci-dessous.

La balise Google est ce qui fait passer la mesure par le conteneur serveur. Une balise d’événement GA4 — une balise d’achat, par exemple — peut envoyer par elle-même. Si la balise Google attend le consentement et que les balises d’événement ne l’attendent pas, celles-ci se déclenchent avant le consentement et envoient directement à Google, depuis une page dont la bannière est encore ouverte. La page du conteneur n’affiche rien d’anormal, parce que les hits ne sont jamais passés par le conteneur.

Soit vous ne conditionnez rien à la main et laissez Consent Mode s’en charger, soit vous conditionnez chaque balise capable d’envoyer. Il n’y a pas de juste milieu cohérent.

Certains gestionnaires de consentement fonctionnent en bloquant les scripts jusqu’au consentement — ils interceptent les balises script par URL et les retiennent. Leurs listes connaissent googletagmanager.com. Elles ne connaissent pas exxz2gdaz1jz.votresite.com, parce qu’aucune liste ne le pourrait : le nom d’hôte et le nom de fichier du chargeur sont uniques à votre conteneur. En mode blocage, le chargeur peut donc être laissé passer sans condition, et si vous comptez sur le blocage plutôt que sur Consent Mode, c’est une balise qui se déclenche avant consentement.

Deux issues. Ajoutez l’URL du chargeur à la main dans les règles de blocage du gestionnaire, dans la catégorie à laquelle appartient votre analyse. Ou — mieux, parce que cela gère aussi correctement le ping sans cookie — fiez-vous à Consent Mode pour les balises Google et n’utilisez le blocage que pour les scripts qui ne le prennent pas en charge. Notre propre site fait tourner un gestionnaire de consentement en mode blocage automatique avec Consent Mode à côté ; la balise Google est placée après le script du gestionnaire, et un test du dépôt échoue si quelqu’un inverse l’ordre.

L’état de consentement arrive au conteneur serveur à l’intérieur de chaque hit, et la balise GA4 côté serveur le lit comme le ferait celle du navigateur. Rien de notre côté n’accorde ni n’élargit un consentement ; un ping sans cookie reste un ping sans cookie.

Si vous connectez une destination Meta ou TikTok, les mêmes hits les alimentent. Que le refus de consentement marketing d’un visiteur doive arrêter ces transmissions est une décision qu’exprime votre gestionnaire de consentement — par la catégorie dans laquelle se trouve le chargeur, et selon que votre installation respecte l’ad_storage de Consent Mode. Vérifiez-le comme vous vérifieriez tout ici : ouvrez le site avec la bannière sans réponse, regardez l’onglet réseau, et voyez ce qui part.

• Le script du gestionnaire de consentement est au-dessus de la balise Google dans la page.
• Un état de consentement par défaut denied est poussé avant le chargement de la balise, avec un wait_for_update.
• Aucune balise du conteneur n’a de condition de consentement ajoutée à la main — ou chaque balise capable d’envoyer en a une.
• Bannière sans réponse, l’onglet réseau montre un ping sans cookie (gcs=G100 dans la requête) et aucun hit complet.
• Après acceptation, la même page montre un hit complet et la page du conteneur le compte.
• Si le gestionnaire bloque par URL, l’URL du chargeur figure dans ses règles.