Bloqueurs de publicités et suivi : ce que perd votre boutique

Les bloqueurs de publicités empêchent le suivi en bloquant le chargement, dans le navigateur de l’acheteur, du script de pixel de la plateforme publicitaire ou des requêtes qu’il envoie. Dans ce cas, la plateforme n’entend jamais parler de la vue de page, de l’ajout au panier ni de l’achat, même si la commande figure dans votre boutique. Les achats envoyés côté serveur à partir de vos données de commande ne sont pas touchés, car le navigateur de l’acheteur n’intervient pas dans leur envoi.

Ce guide explique comment fonctionnent les bloqueurs de publicités et les protections de confidentialité des navigateurs, quels événements votre boutique perd, ce que le suivi côté serveur récupère et ce qu’il ne peut pas récupérer. Il se termine par une méthode simple pour mesurer l’écart dans votre propre boutique.

Comment les bloqueurs de publicités arrêtent-ils les pixels de suivi ?

La plupart des bloqueurs de publicités fonctionnent avec des listes de filtres. Une liste de filtres est une longue liste de règles qui correspondent à des adresses web : domaines, chemins et noms de fichiers de scripts publicitaires et de suivi connus. Quand une page demande au navigateur de charger quelque chose qui correspond à une règle, le bloqueur annule la requête.

Les listes les plus connues sont EasyList, pour les publicités, et EasyPrivacy, pour le suivi. Elles fonctionnent avec des extensions comme Adblock Plus, AdBlock, uBlock Origin et AdGuard. Le pixel d’une grande plateforme publicitaire est une cible facile pour ces listes, car il charge le même script depuis le même domaine sur de nombreux sites différents.

Navigateurs avec protection intégrée

Certains navigateurs bloquent les traceurs sans extension. Brave active ses Shields sur tous les sites par défaut, et les Shields bloquent les publicités, les traceurs et les cookies intersites tiers. Firefox bloque le contenu provenant de domaines de suivi intersites connus dans les fenêtres de navigation privée, et les utilisateurs peuvent choisir des réglages plus stricts qui s’appliquent à toutes les fenêtres. L’Intelligent Tracking Prevention de Safari bloque tous les cookies tiers et raccourcit la durée de vie des cookies posés par des scripts. Notre guide sur Safari ITP et le suivi publicitaire explique ces limites.

Bloqueurs à l’échelle du réseau

Certaines personnes bloquent les traceurs pour tout un appareil ou tout un réseau domestique, avec un bloqueur basé sur le DNS ou un VPN doté d’un filtre anti-traceurs. Ces outils bloquent les requêtes vers les domaines de suivi dans tous les navigateurs et toutes les applications du réseau. Changer de navigateur ne change rien au résultat.

Quels événements votre boutique perd-elle ?

Quand le pixel est bloqué, tous les événements qu’il aurait envoyés depuis ce navigateur sont perdus. Les dégâts ne sont pas les mêmes selon l’événement.

Des événements de navigation perdus réduisent la taille de vos audiences de retargeting. Des achats perdus font plus de dégâts. La plateforme déclare moins de conversions, le ROAS du rapport publicitaire baisse et l’algorithme d’enchères apprend à partir de moins d’acheteurs. Une campagne rentable peut alors sembler non rentable, et vous risquez de la couper.

Pourquoi les événements côté serveur issus des données de commande ne sont pas bloqués

Un bloqueur de publicités s’exécute dans le navigateur de l’acheteur. Il ne peut arrêter que les requêtes que le navigateur envoie. Quand l’achat est envoyé à partir des données de commande de votre boutique, la requête part d’un serveur vers l’API de la plateforme publicitaire. Le navigateur de l’acheteur ne fait pas partie de ce trajet : le bloqueur n’a donc rien à annuler.

La plateforme associe ensuite l’achat à une personne grâce aux données de l’événement : l’e-mail et le téléphone hachés issus de la commande, l’adresse IP et le user agent, et l’identifiant de clic s’il a été enregistré. Rien de tout cela ne passe par le bloqueur. Pour le trajet complet des données, lisez ce qu’est le suivi côté serveur.

Que ne peut pas récupérer le suivi côté serveur ?

L’identifiant de clic a besoin du navigateur

La commande elle-même est à l’abri, mais le lien avec le clic publicitaire se fait dans le navigateur. Un script doit lire l’identifiant de clic dans l’URL d’arrivée et l’enregistrer. Si un bloqueur de publicités bloque aussi ce script, la commande arrive sans identifiant de clic. La plateforme peut quand même associer l’achat grâce aux données clients hachées, mais la correspondance est moins fiable.

Deux leviers réduisent cette perte. Premièrement, collectez les événements en first-party : servez le script de suivi et ses requêtes depuis votre propre domaine, par exemple via un proxy d’application Shopify ou un sous-domaine de votre site. Les listes de filtres ciblent des adresses de suivi tierces connues, donc un chemin first-party est beaucoup plus difficile à bloquer, sans être impossible. Deuxièmement, utilisez la landing page que certaines boutiques en ligne, comme Shopify, enregistrent avec chaque commande. Si cette URL contient encore l’identifiant de clic ou les UTM, la commande peut être attribuée sans aucun événement du navigateur.

Les événements de navigation sont toujours perdus

Les données de commande contiennent des commandes, pas des vues de page. Envoyer les achats à partir des commandes ne ramène pas les vues de page ni les ajouts au panier d’un visiteur dont le navigateur a tout bloqué. Un collecteur first-party peut transmettre ces événements depuis le serveur quand ses propres requêtes passent.

Un consentement refusé n’est pas un blocage

Un visiteur qui refuse les cookies marketing dans votre bandeau de cookies n’est pas la même chose qu’un visiteur avec un bloqueur de publicités. Le premier a fait un choix que votre suivi doit respecter. Avec Respect visitor consent activé, ROASaurus ne définit aucun identifiant visiteur pour ce visiteur : ses clics publicitaires et ses visites ne lui sont donc pas rattachés. Ses événements navigateur sont conservés sans identifiant visiteur, adresse IP ni détails du navigateur, et ne sont pas envoyés aux plateformes publicitaires. La commande payée est quand même envoyée côté serveur, avec les données clients hachées de la commande ainsi que l’adresse IP et le user agent de la commande. Séparez les deux groupes quand vous mesurez votre perte, et consultez consentement et confidentialité pour les détails.

Comment estimer votre propre perte

Vous n’avez pas besoin de moyennes sectorielles, qui dépendent de l’audience, de l’appareil et du pays. Vous pouvez mesurer votre propre écart en comparant les commandes de votre boutique aux achats déclarés par le pixel du navigateur sur la même période.

1. Choisissez une période et une plateforme

   Prenez 14 ou 30 jours et une seule plateforme, par exemple Meta. Utilisez le même fuseau horaire dans les deux systèmes.

2. Comptez les commandes web de votre boutique

   Partez de toutes les commandes. Retirez celles qui ne passent jamais par votre checkout en ligne : ventes en point de vente, commandes manuelles et brouillons, renouvellements d’abonnement et commandes de test.

3. Comptez les événements Purchase du navigateur

   Dans l’outil d’événements de la plateforme, comptez les événements Purchase envoyés par le pixel du navigateur. C’est plus simple avant d’ajouter des événements serveur. Si des événements serveur tournent déjà, utilisez la vue par méthode de connexion de la plateforme quand elle en propose une. Meta Events Manager indique la méthode de connexion de chaque événement et y compte les événements avant déduplication. N’utilisez pas les achats attribués du rapport publicitaire.

4. Divisez

   Achats du navigateur ÷ commandes web = la part que le pixel a vue. Le reste est votre écart.

5. Séparez le consentement du blocage

   Estimez les commandes de visiteurs qui ont refusé les cookies marketing, à partir du taux de refus de votre outil de consentement. Ce qui reste correspond surtout aux bloqueurs de publicités, aux réglages de confidentialité et aux pages qui ne se sont pas chargées.

L’écart modifie aussi le ROAS. Supposons que Meta déclare un ROAS de 2.0 pour cette boutique et que son ROAS d’équilibre soit de 2.3. D’après les données du pixel, les campagnes perdent de l’argent. Si les commandes issues des publicités étaient manquées au même taux de 24% que l’ensemble des commandes web, le pixel n’aurait vu que 76% du chiffre d’affaires publicitaire. Le vrai ROAS serait alors d’environ 2.0 ÷ 0.76 = 2.6, au-dessus du seuil d’équilibre. C’est une estimation haute, car toutes les commandes manquantes ne viennent pas d’une publicité. Notre guide sur le ROAS d’équilibre explique comment fixer ce seuil.

Comment réduire ce que vous perdez

Les solutions sont les mêmes pour toutes les plateformes de boutiques en ligne. Elles fonctionnent mieux combinées.

1. Envoyez les achats à partir des données de commande. Cela comble l’écart d’achats pour chaque plateforme connectée, quoi que bloque le navigateur du visiteur.
2. Gardez le pixel, avec un identifiant d’événement partagé. Les visiteurs sans bloqueur envoient toujours des événements navigateur avec cookies et contexte de page. Le même identifiant d’événement sur les deux copies permet à la plateforme d’en garder une seule. Voir éviter le double comptage.
3. Collectez en first-party. Servez le script de suivi et ses événements depuis votre propre domaine, afin que les identifiants de clic soient enregistrés pour davantage de visiteurs.
4. Envoyez des données clients hachées. L’e-mail et le téléphone de la commande permettent à la plateforme d’associer les achats sans identifiant de clic.
5. Mesurez à nouveau. Refaites la comparaison un mois plus tard. Les événements Purchase reçus par la plateforme devraient maintenant correspondre à vos commandes web.

Comment ROASaurus gère les bloqueurs de publicités

ROASaurus envoie chaque commande payée côté serveur aux plateformes publicitaires que vous ajoutez sous Tracking & platforms : un bloqueur de publicités dans le navigateur de l’acheteur n’empêche donc pas l’achat. Sur Shopify, les événements de la vitrine passent par le proxy d’application de Shopify sur le domaine de votre boutique. Vous pouvez aussi servir le script et ses événements depuis un sous-domaine CNAME de votre site. Quand un visiteur n’a aucun contact navigateur, l’attribution de ROASaurus se rabat sur les identifiants de clic et les UTM de l’URL de landing page de la commande, quand la boutique en enregistre une, comme le fait Shopify.

Chaque envoi et la réponse de la plateforme sont listés dans l’Event log, ce qui vous permet de vérifier que chaque commande est arrivée sur chaque plateforme. Consultez le suivi côté serveur et l’intégration Shopify pour la configuration.

Sources

1. EasyList: Overview
2. Brave: Brave Shields
3. MDN Web Docs: Firefox tracking protection
4. WebKit: Tracking Prevention in WebKit
5. Meta for Developers: Verifying Your Setup

Dans ROASaurus

• Le suivi côté serveur dans ROASaurus
• Éviter le double comptage
• Consentement et confidentialité

À lire aussi