Faut-il bloquer les balises de Google tant que personne n'a consenti ?

Tous les articles

Pour une implémentation de Consent Mode avancé, non. En mode basique, oui : le mode basique signifie que les balises Google restent bloquées jusqu'à ce que le visiteur consente. En mode avancé, les balises de Google restent débloquées et appliquent elles-mêmes le choix du visiteur grâce à leurs vérifications intégrées. Une vérification Additional Consent par-dessus les bloque purement et simplement, ce qui fait discrètement passer le mode avancé en mode basique et supprime le signal de refus à partir duquel Google modélise. Le test : une visite refusée doit quand même envoyer gcs=G100.

Le conseil est juste. Il ne concerne simplement pas les balises de Google.

Presque tout ce qui s'écrit sur le consentement dans Google Tag Manager aboutit à la même consigne : conditionnez la balise. Ouvrez Advanced Settings, puis Consent Settings, exigez un consentement supplémentaire, nommez les types. Pour un script de fournisseur qui écrit son propre cookie dès son chargement, c'est exact, et notre propre guide sur le déplacement d'un script dans Google Tag Manager pour le conditionner dit exactement cela.

Une réserve d'abord, parce qu'elle tient à la juridiction plutôt qu'à la mécanique. Certains opérateurs, allemands en particulier, bloquent tout le conteneur jusqu'au consentement sur avis juridique. C'est le choix délibéré d'un comportement basique, avec le coût de mesure accepté, et c'est autre chose qu'une vérification de consentement oubliée sur une balise GA4. Cet article porte sur le second cas.

Les types de balises propres à Google sont l'exception, et ce n'est pas une affaire de goût. Google le dit clairement dans son guide sur le déblocage des balises Google. Ses balises intègrent des vérifications du consentement et adaptent leur comportement d'elles-mêmes : elles n'ont pas besoin de vérifications supplémentaires, et mettre en place les deux à la fois les empêche de fonctionner correctement. Une balise de configuration GA4 ou une balise de conversion Google Ads sait déjà sur quoi ad_storage et analytics_storage sont réglés. Une vérification Additional Consent se place devant ce mécanisme et ne le laisse jamais s'exécuter.

Nous l'avons appris au fil de cinq versions de conteneur lors d'une même remise en conformité du consentement. La bannière allait bien. Le conteneur avait une vérification de consentement sur tout, appliquée uniformément, et c'est pour cela que le compte ne modélisait plus rien.

Ce que coûte réellement la vérification supplémentaire

Une balise Google débloquée, sur une page où le visiteur a refusé, envoie quand même une requête. Elle part vers /g/collect sans cookies ni identifiant client, en portant gcs=G100 : Consent Mode est actif, les deux types de stockage sont refusés. C'est un refus enregistré, et c'est la donnée qu'utilise la modélisation de Google pour estimer les conversions qu'elle n'a pas le droit d'observer.

Une balise Google bloquée n'envoie rien du tout. Rien, ce n'est pas un refus. C'est une absence, et un modèle ne peut pas apprendre d'une absence. Vous n'avez pas non plus rendu la visite plus privée, car la requête débloquée était déjà sans cookies dans ce cas. Vous avez seulement effacé votre propre preuve que le visiteur était là.

Ce seul réglage décide donc, dans les faits, si le site tourne en Consent Mode avancé ou basique, quoi qu'en dise l'écran de la bannière. C'est la même question que Consent Mode basique ou avancé, vue du côté des balises. Ce ping de refus est la donnée à partir de laquelle Google modélise, et la modélisation ne s'active qu'une fois que votre site atteint les seuils de données indiqués dans la documentation de Google sur le mode de consentement. Ce qu'elle produit est une estimation, pas des conversions que quiconque a observées.

Comment vérifier ce que vous avez réellement mis en ligne

Cinq étapes, dans l'ordre.

1. Listez chaque balise portant une vérification Additional Consent

   Passez le conteneur en revue balise par balise plutôt que de vous fier au guide d'intégration qui l'a configuré. Dans chaque balise, sous Advanced Settings puis Consent Settings, le réglage indique soit qu'aucun consentement supplémentaire n'est requis, soit une liste nommée de types de consentement. Notez chaque balise de la liste nommée : dans un conteneur passé par deux migrations de CMP, elle est immanquablement plus longue que prévu.

2. Retirez la vérification de tous les types de balises Google

   Les balises de configuration et d'événement GA4, les balises de conversion et de remarketing Google Ads, Floodlight et la balise Google elle-même repassent toutes en aucun consentement supplémentaire requis. Laissez les vérifications sur les véritables balises tierces. La frontière tient à la propriété, pas à la sensibilité : une balise Google applique le consentement en interne, une balise Meta ou Hotjar ne le fait pas.

3. Passez l'option de déclenchement d'une fois par page à une fois par événement

   Une balise réglée pour se déclencher une fois par page compte une tentative bloquée comme son déclenchement unique. Le déclencheur s'active avant que le visiteur ne décide, la vérification du consentement arrête la balise, et le compteur considère malgré tout son tour comme utilisé. Quand le consentement arrive et que le déclencheur s'active à nouveau, le conteneur l'ignore. La balise semble correcte sur tous les écrans et ne produit rien. Une fois par événement est le bon réglage pour tout ce qui peut être tenté avant une décision.

4. Laissez la mise à jour du consentement arriver avant de juger un déclencheur

   Le conteneur évalue l'état de consentement d'une balise à l'instant où son déclencheur s'active, et une CMP applique une décision enregistrée de manière asynchrone, généralement quelques centaines de millisecondes après le début du chargement. Une balise déclenchée au chargement de la page peut donc être évaluée alors que le consentement indique encore refusé, lors de la visite de quelqu'un qui a accepté il y a plusieurs semaines. Le symptôme : une balise qui se déclenche sur un clic mais jamais sur une page vue. Les vérifications intégrées de Google gèrent elles-mêmes ce décalage, et c'est la deuxième raison de ne pas les envelopper.

5. Vérifiez sur la page en production, jamais dans Preview

   Le mode Preview fonctionne avec le câblage de débogage du conteneur et, très souvent, un état de consentement sur lequel vous avez vous-même cliqué. Chargez la page de production dans un navigateur vierge, refusez et lisez ce qui part. Tag Assistant vous dira que la balise s'est déclenchée. Seul le panneau réseau vous dit ce que Google a reçu.

Le diagnostic, en une ligne

Ouvrez le panneau réseau sur la page en production, filtrez sur collect et refusez. Une requête qui part en portant gcs=G100 signifie que vos balises Google sont débloquées et que le refus est bien transmis. Un panneau vide signifie que quelque chose les bloque, et il n'y a que deux candidats réalistes : une vérification Additional Consent sur la balise, ou une bannière qui bloque tout le conteneur avant même que la balise existe.

Acceptez ensuite et recommencez : gcs=G111 signifie que les deux signaux sont accordés. Faire parvenir la mise à jour au conteneur, c'est le câblage décrit dans le guide d'installation Google Tag Manager, qui mérite d'être relu en gardant cette exception en tête.

Velo fonctionne dans ce sens par défaut : il met à jour Consent Mode, laisse les balises de Google appliquer elles-mêmes le résultat et ne conditionne que les scripts qui en sont incapables. Ce qu'aucune bannière ne peut faire à votre place, c'est l'étape un, car les vérifications déjà présentes dans votre conteneur y ont été placées par l'outil qui l'a configuré avant.