Pourquoi le pixel Facebook se charge encore quand vos balises sont bloquées

Tous les articles

Le pixel Facebook se charge généralement pour l'une de trois raisons : son code de base s'exécute dans le head de votre page avant la bannière, sa balise se déclenche avant que vos valeurs de consentement par défaut ne soient posées, ou la balise n'a jamais exigé le consentement publicitaire. Si ces trois points sont propres, le script d’un autre fournisseur injecte probablement le pixel à l'exécution, et votre conteneur ne peut pas filtrer une requête qu'il n'a jamais faite.

Écartez d'abord les causes ordinaires

La plupart du temps, c'est l'une de ces causes.

• Le code de base du pixel se trouve dans le head de votre page sans fbq('consent', 'revoke') au-dessus, il s'initialise donc avant l'affichage de votre bannière.
• La balise se déclenche sur un déclencheur qui s'exécute avant que vos valeurs de consentement par défaut ne soient posées : elle ne lit donc aucun choix.
• La balise n'a jamais été configurée pour exiger le consentement publicitaire : elle se déclenche quoi qu'il arrive autour d'elle.
• Un contenu social intégré, un bouton J'aime ou un widget de commentaires dépose ses propres cookies.

Vérifiez chacune sur une page en production, pas dans le conteneur : comment savoir si une balise dépose vraiment des cookies avant le consentement donne la méthode. Si ces points sont propres et que les requêtes persistent, la cause se trouve hors de votre conteneur.

Un outil de consentement filtre ce que votre conteneur contrôle

Un pixel publicitaire arrive sur une page par l'une de trois voies courantes, et un outil de consentement agit différemment sur chacune. La plupart des réponses publiées ne pensent qu'aux deux premières.

La première est une balise de votre conteneur, qui se déclenche quand l'état du consentement l'y autorise. La deuxième est un script dans le code source de votre page, qu'un outil de consentement peut généralement retenir aussi, en le reconnaissant avant que le navigateur ne l'exécute.

La troisième est celle que la plupart des guides passent sous silence. Un script déjà en cours d'exécution, et que vous avez légitimement autorisé, charge son propre module publicitaire à l'exécution et injecte le pixel. Votre conteneur n'a jamais fait cette requête, donc rien de ce que vous y modifierez ne l'arrêtera.

Voici à quoi ressemblait la troisième voie sur un parc en production que nous avons audité en août. Des cookies Meta et LinkedIn étaient écrits avant le consentement, et le diagnostic interne accusait les balises du conteneur. Sur une session vierge, bannière affichée et sans aucun clic, les deux balises portaient une condition de stockage publicitaire et aucune ne s'est déclenchée. Les cookies sont apparus quand même, avec les mêmes identifiants de pixel, parce qu'une balise de plateforme marketing autorisée chargeait son propre fichier de pixel publicitaire, qui chargeait à son tour les bibliothèques Meta et LinkedIn. Rien n'était mal configuré ; la frontière n'était simplement pas là où tout le monde la supposait.

Comment savoir lequel vous avez

Quelques minutes, sans ouvrir le conteneur.

1. Ouvrez le site dans un profil vierge et refusez tout

   Aucun consentement enregistré, le panneau réseau ouvert avant le premier affichage, et un refus délibéré.

2. Filtrez sur les hôtes propres au pixel

   Pour Meta, c'est connect.facebook.net pour la bibliothèque et facebook.com/tr pour l'événement. Regardez aussi le panneau Application : un cookie _fbp qui apparaît sur votre propre domaine dans cette session vierge signifie généralement que la bibliothèque s'est chargée. Aucune requête et aucun cookie : vous n'avez pas ce problème.

3. Dépliez la chaîne d'initiateurs, ne lisez pas que la première ligne

   C'est l'étape où l'on se trompe le plus facilement. Votre gestionnaire de balises apparaît souvent dans la chaîne parce qu'il a chargé le script du fournisseur bien plus tôt, ce qui ne prouve pas qu'une balise du gestionnaire a fait cette requête. Ce qu'il vous faut, c'est l'entrée située juste au-dessus de l'appel au pixel : elle désigne le script qui en est à l'origine.

4. Confrontez le conteneur à ce que vous venez de voir

   Ouvrez l'aperçu et vérifiez si les balises publicitaires se sont déclenchées. Une balise dans la liste des balises non déclenchées alors que la requête apparaît toujours n'a rien de contradictoire : les deux outils décrivent deux couches différentes.

5. Remontez du script responsable jusqu'à sa plateforme

   Trouvez le fournisseur qui se cache derrière, puis son réglage d'intégration publicitaire. C'est ce réglage, et non votre configuration de consentement, qui place le pixel sur la page.

Pourquoi filtrer plus fort dans le conteneur ne peut pas marcher

On a l'impression d'avancer, et c'est pour cela que ça coûte cher. L'équipe ajoute une condition de consentement aux balises publicitaires, puis un déclencheur de blocage, puis une exception, et conclut que l'outil de consentement est cassé, alors que chaque modification portait sur une balise qui ne se déclenchait déjà pas.

Distinguez ce cas de la panne avec laquelle on le confond. Vos propres balises qui se déclenchent avant que la bannière n'enregistre ses valeurs par défaut, c'est un problème de timing, qui se corrige réellement dans le conteneur, et nous l'avons traité dans pourquoi des balises se déclenchent avant le chargement de la bannière de cookies. Ici, c'est une question de périmètre et non de timing : vos balises se sont comportées correctement, et quelque chose en dehors de leur périmètre a fait ce que vous cherchiez à empêcher.

Là où se trouve vraiment la correction

Quatre leviers. Le bon dépend de ce que fait le script du fournisseur avant le consentement, et de la catégorie dans laquelle le script aurait dû se trouver dès le départ : dans quelle catégorie de consentement classer chaque script tiers traite cette décision.

• Le portail du fournisseur. La plupart des plateformes qui injectent des pixels publicitaires proposent un réglage pour cela. Désactiver cette intégration est la solution la plus propre : le script continue son travail légitime et cesse de transporter le pixel de quelqu'un d'autre.
• Un appel consent revoke précoce. fbq('consent', 'revoke'), exécuté avant que quoi que ce soit ne puisse initialiser le pixel, demande à la bibliothèque Meta de retenir ses événements, quel que soit celui qui l'a chargée. La documentation de Meta sur le consentement décrit les appels revoke et grant. C’est un filet de sécurité plutôt qu’une réponse complète : la bibliothèque se charge quand même, et cela n'aide que si votre appel s'exécute vraiment en premier.
• La balise du fournisseur dans votre conteneur. Si une balise qui vous appartient charge le script du fournisseur, conditionnez cette balise au consentement publicitaire. Méthode radicale : vous perdez aussi tout ce que ce script fait d'autre pour les visiteurs qui refusent, comme des formulaires ou un chat.
• Le blocage par catégorie dans l'outil de consentement. Si le script du fournisseur se charge hors de votre conteneur, classez le script lui-même dans la catégorie publicité pour que l'outil le retienne avant son exécution. Même compromis.

Relancez ensuite le même test : profil vierge, refus, filtre, et vérification que rien n'atteint les hôtes du pixel. Une limite : ce test ne lit que le navigateur, donc tout ce que vos serveurs envoient via une API de conversions doit être vérifié à la source. Vérifier à la destination plutôt que sur la bannière est une habitude générale, décrite dans comment vérifier que votre bannière envoie vraiment le signal de consentement.

Si vous utilisez aussi Signals Gateway de Meta, filtrez également sur le sous-domaine de votre passerelle : son pixel est un code distinct qui a besoin de sa propre vérification du consentement, expliquée dans comment faire respecter le consentement aux cookies par Meta Signals Gateway.

Velo retient les scripts que vous marquez d'une catégorie de consentement jusqu'à ce que cette catégorie soit accordée ; un pixel qu'un autre fournisseur injecte sans ce marquage doit encore être remonté jusqu'au fournisseur.