Pourquoi des balises se déclenchent avant le chargement de la bannière de cookies

Tous les articles

Une autre balise partage le déclencheur que votre bannière de cookies était censée avoir pour elle seule. Placer la bannière sur Consent Initialization est nécessaire mais ne suffit pas. Ce déclencheur lâche tout ce qui y est attaché en même temps, pas dans l'ordre : une balise plus légère placée à côté peut donc atteindre le réseau la première pendant que la bannière récupère encore sa configuration.

Le déclencheur est un signal de départ, pas une file d'attente

Le déclencheur Consent Initialization existe pour que les valeurs de consentement par défaut soient enregistrées avant que quoi que ce soit d'autre ne s'évalue, et tous les guides qui vous disent d'y placer votre outil de consentement ont raison. Ce qu'ils omettent, c'est ce qui se passe quand une seconde balise est placée sur le même déclencheur. Le déclencheur ne devient pas une file d'attente. Il lâche tout ce qui y est attaché, et à partir de cet instant les balises font la course sur le réseau.

La priorité de déclenchement des balises ressemble à la réponse et n'en est pas une. La propre page d'aide sur la priorité de déclenchement des balises de Tag Manager indique que les balises ayant une valeur de priorité plus élevée se déclenchent avant celles qui ont une valeur plus faible, puis ajoute la phrase qui compte ici : les balises se déclenchent tout de même de manière asynchrone. La priorité décide de l'ordre dans lequel les requêtes démarrent. Elle ne fait pas attendre le conteneur jusqu'à ce que l'une d'elles se termine. Un outil de consentement qui doit récupérer sa configuration par le réseau peut donc partir premier et arriver deuxième, et c'est exactement le cas qui vous coûte.

Ce que nous avons mesuré sur un parc en production

Le symptôme signalé était une requête publicitaire quittant le navigateur avant qu'un quelconque état de consentement existe, sur un site dont le travail de consentement était par ailleurs en bon ordre. Valeurs refusées par défaut présentes, signal à denied sur la requête analytics sortante, et modèle de l'outil de consentement sur Consent Initialization, exactement comme le prévoit la documentation.

Une balise de remarketing se trouvait sur ce même déclencheur. Nous avons lu le panneau réseau dans l'ordre de démarrage des requêtes, pas en mode aperçu. La requête publicitaire partait avant le chargeur de l'outil de consentement à chaque chargement capturé, avec une avance d'environ deux millisecondes. Retenez l'ordre comme constat et l'écart comme illustration : le panneau réseau d'un navigateur n'est pas un instrument précis à la fraction de milliseconde, et le chiffre varierait selon la connexion et le cache. Ce qui ne varie pas, c'est quelle requête est partie en premier, et pourquoi. Ce n'est pas une bannière lente. Ce sont deux éléments lâchés ensemble, dont l'un avait moins de travail à faire.

Pourquoi chaque audit de l'outil de consentement était sans reproche

Parce que chaque audit portait sur l'outil de consentement, et que l'outil de consentement faisait son travail. Le vérifier comme nous le recommandons habituellement, en lisant le signal de consentement sur la requête sortante, donne un résultat positif, parce que la requête que vous lisez est celle qui s'est bien comportée.

Le mode aperçu ne tranche pas non plus. Il vous dit quelles balises se sont déclenchées et dans quel événement, ce qui n'est pas la même chose que savoir laquelle de deux requêtes lâchées au même instant a atteint le réseau en premier. Un conteneur qui semble correct en aperçu peut cohabiter avec une page qui ne l'est pas.

Il existe un cas symétrique qui passe lui aussi l'audit sans problème. L'outil de consentement fonctionne parfaitement, mais les balises qu'il est censé conditionner ne se déclenchent jamais, parce que les variables d'une ancienne plateforme sont toujours branchées dans leurs règles de blocage. Ce cas est traité dans ce qu'il faut vérifier quand vous changez de plateforme de gestion du consentement.

Quatre causes, un seul symptôme

Une balise qui se déclenche avant le chargement de la bannière a plus d'une cause possible, et il est facile de les distinguer une fois qu'on sait que ce sont des choses différentes.

1. Une autre balise partage le déclencheur

   Le cas ci-dessus. La configuration du consentement est correcte, la balise fautive est rapide, et la course est invisible partout sauf dans le panneau réseau. Constant plutôt qu'intermittent, parce que c'est la même balise qui gagne à chaque chargement.

2. L'outil de consentement est sur le mauvais déclencheur

   Sur All Pages, il est en concurrence avec tout le conteneur plutôt qu'avec une seule balise. C'est le cas que le conseil habituel corrige déjà : écartez-le en premier. Le bon emplacement est expliqué dans installer une bannière de cookies avec Google Tag Manager.

3. L'outil de consentement se charge hors du conteneur

   Si la bannière est dans le code source de la page et que le conteneur se charge séparément, la requête qui l'emporte dépend de la page, pas d'un réglage de balise. Cela varie selon le modèle de page et l'état du cache. Un comportement intermittent désigne cette cause. Sur WordPress, placer le script tout au début du head est expliqué dans comment ajouter une bannière de cookies à WordPress sans plugin. Activer Google tag gateway peut aussi déplacer la balise Google dans cet ordre, ce que traite Google tag gateway exige-t-il le consentement aux cookies.

4. La balise n'a aucune vérification du consentement

   Pas une course. Une balise sans vérification du consentement ne consulte jamais l'état du consentement : les valeurs refusées par défaut ne la retiennent pas, et aucun ordre ne le fera. Elle se déclenche en premier parce qu'elle n'a jamais attendu.

Comment voir l'ordre par vous-même

Il suffit d'un chargement de page, sans mode débogage. Toute l'astuce consiste à arrêter de lire le conteneur pour lire ce qui a quitté le navigateur.

1. Chargez le site dans un profil vierge et ne cliquez sur rien

   Une session qui a déjà accepté ne vous apprend rien : l'état est restauré à partir d'un choix enregistré avant que la course n'ait lieu.

2. Triez le panneau réseau par heure de démarrage des requêtes

   La vue par défaut regroupe les requêtes d'une manière qui masque cela. Il vous faut la chronologie, pas la liste.

3. Trouvez la requête de l'outil de consentement, puis remontez

   Tout ce qui figure au-dessus et provient d'un fournisseur de publicité ou d'analyse est parti avant que le consentement existe. Cela vous désigne la balise.

4. Ouvrez le conteneur et listez chaque balise sur Consent Initialization

   Il ne devrait y en avoir que deux au maximum : l'outil de consentement et la balise qui enregistre vos valeurs refusées par défaut. Tout le reste est suspect. Tout ce qui, dans cette liste, mesure ou fait de la publicité est aussi ce que les autorités sanctionnent réellement, comme nous l'expliquons dans pouvez-vous être sanctionné pour l'absence de bannière de cookies.

5. Rechargez encore deux fois avant de conclure quoi que ce soit

   Un ordre constant signale un déclencheur partagé. Un ordre qui change d'un chargement à l'autre signale un outil de consentement chargé hors du conteneur, et la correction est différente.

La correction, et pourquoi ce n'est pas la priorité

Retirez la balise fautive de Consent Initialization et donnez-lui All Pages ou son propre événement. La course s'arrête parce qu'il n'y a plus de course, et la modification prend deux minutes. Si une balise doit vraiment s'exécuter tôt, le séquençage des balises est un outil plus précis que la priorité, car il indique quelle balise se déclenche avant laquelle au lieu d'exprimer une préférence.

Résistez aux deux fausses solutions tentantes. Augmenter la priorité laisse les deux balises sur le déclencheur et demande à un système asynchrone une garantie synchrone qu'il n'offre pas. Ajouter une seconde balise de valeurs par défaut vous donne deux éléments qui émettent des valeurs de consentement par défaut, ce qui est un nouveau problème et non une solution. Pour une vraie double sécurité, placez un petit extrait de code inline qui pose les valeurs refusées par défaut dans le head de la page, au-dessus de l'extrait du conteneur, pour qu'un état refusé existe avant même que le conteneur soit analysé. Sur une plateforme hébergée où le head se résume à une zone d'injection, cet ordre représente l'essentiel de l'installation : ce que Squarespace vous permet de faire et ce qu'il ne permet pas.

Mesurez ensuite de nouveau, de la même façon que vous avez trouvé le problème. Une vraie correction montre la requête de l'outil de consentement arrivant en premier à chaque chargement propre, la requête publicitaire attendant ou portant un signal de refus. Si les chiffres ont bougé mais pas l'ordre, vous avez corrigé autre chose. Des conversions qui ont bougé à la même date méritent la même lecture : pourquoi les conversions GA4 chutent d'un coup.

Une vérification avant de conclure que l'ordre est bien votre problème. Si la requête publicitaire est toujours là une fois l'ordre corrigé, regardez ce qui l'a produite. Un pixel injecté à l'exécution par le script d'un autre fournisseur n'est jamais passé par le conteneur, et aucune modification de déclencheur ne peut donc l'atteindre. Ce cas est traité dans pourquoi le pixel Facebook se charge encore quand vos balises sont bloquées.

Velo sort la récupération de configuration de cette course. Son script fixe les valeurs refusées par défaut dès qu'il s'exécute, avant toute requête de configuration : avec le script placé au-dessus du conteneur, elles existent donc avant que le conteneur ne soit atteint. L'emplacement compte toujours, tout comme le fait de tenir les autres balises à l'écart de ce déclencheur. Le mécanisme est décrit sur la page produit.