Comment fonctionne un pixel de suivi et ce qu'il ne peut pas voir

Qu'est-ce qu'un pixel de suivi ?

Les marketeurs intègrent un pixel de suivi, une image 1x1 référencée par une URL qui identifie la campagne, pour que l'affichage de la page ou de l'e-mail force une requête vers un serveur qui la journalise. L'image est accessoire. La requête est le produit.

Meta livre ce motif dans son propre code de base documenté, comme solution de repli pour les visiteurs dont le navigateur n'exécute pas la version JavaScript :

<noscript>
  <img height="1" width="1" style="display:none"
       src="https://www.facebook.com/tr?id={your-pixel-id-goes-here}&ev=PageView&noscript=1"/>
</noscript>

Tout ce qu'un pixel rapporte se trouve dans cette URL ou dans les en-têtes que le client y attache. id nomme le compte, ev=PageView nomme l'événement, noscript=1 note que c'était le chemin de repli. Le corps de la réponse n'intéresse pas l'expéditeur, raison pour laquelle ces endpoints renvoient un GIF 1x1 transparent ou un 204 No Content vide, et raison pour laquelle l'élément est masqué avec display:none.

Que reçoit réellement le serveur ?

Cinq choses arrivent avec une requête de pixel, et une seule est choisie par celui qui a posé le pixel.

Remarquez ce qui manque. Pas de titre de page, pas de taille d'écran, pas de position de défilement et pas de temps passé, parce que rien de tout cela n'existe au moment où une image est demandée. Un hit de pixel est une ligne dans un journal d'accès, et chaque champ y a été soit attaché automatiquement par le client, soit écrit dans l'URL par l'expéditeur des semaines plus tôt. Les analystes prêtent régulièrement aux données de pixel un détail qu'elles ne peuvent pas contenir, puis expliquent les trous par le blocage de publicités.

La ligne Referer est celle que la plupart des gens comprennent encore de travers. Les navigateurs utilisent par défaut strict-origin-when-cross-origin, que MDN décrit comme envoyant "the origin, path, and query string when performing a same-origin request" mais, pour les requêtes cross-origin, envoyant "the origin (only) when the protocol security level stays same (HTTPS to HTTPS)." Un pixel tiers apprend donc le site, pas la page, sauf si le propriétaire de la page a délibérément passé le chemin dans la chaîne de requête.

Que ne peut pas faire un pixel qu'un script peut faire ?

Un pixel ne peut pas lire la page sur laquelle il se trouve. Il part une fois, ne transporte que ce que l'URL contenait déjà, et ensuite la requête est finie.

La documentation de Meta montre l'écart à l'intérieur d'un seul produit. Le pixel JavaScript, dit-elle, "will track URLs visited, domains visited, and the devices your visitors use." L'image noscript en dessous rapporte un unique PageView avec les paramètres déjà écrits dans le src. Même compte, même nom d'événement, une fraction du détail.

C'est aussi pourquoi le pixel est le mauvais outil et la mauvaise inquiétude dans la plupart des débats sur l'analytics web. La mesure par script est ce qui lit la page ; le pixel est le repli dégradé. Pour la question plus large de ce qu'une requête tierce peut recouper entre les sites, le suivi cross-site et la différence entre cookies first-party et third-party comptent bien plus que la taille de l'image.

Pourquoi les taux d'ouverture d'e-mail surestiment-ils les ouvertures ?

Le suivi des ouvertures d'e-mail est le cas d'usage classique du pixel, et c'est celui qui a cassé en premier. Il n'existe pas d'événement d'ouverture dans l'e-mail. Il n'existe qu'une image distante que le client de messagerie peut récupérer ou non, donc toute la métrique repose sur le fait que le client se comporte comme en 2010.

Protect Mail Activity d'Apple, le réglage derrière Mail Privacy Protection, casse l'inférence à deux endroits. Apple indique qu'il "helps protect your privacy by preventing email senders, including Apple, from learning information about your Mail activity", et décrit le mécanisme sans ambiguïté : il "downloads remote content in the background by default", que le destinataire interagisse ou non avec l'e-mail. Cette seule phrase convertit un taux d'ouverture en taux de livraison pour tout destinataire ayant le réglage actif. Côté réseau, Apple "routes all remote content downloaded by Mail through two separate relays operated by different entities", donc l'adresse IP qui atteint l'expéditeur n'est pas celle du destinataire, et "senders can't use your IP address as a unique identifier to connect your activity across websites or apps to build a profile about you."

Gmail attaque le même signal sous un autre angle, en analysant et en servant les images lui-même. La page d'aide de Google indique que "senders can't use image loading to get information about your computer or location" et que "senders can't use the image to set or read cookies in your browser." Elle concède aussi la limite de cette protection en une ligne : "sometimes, senders may know whether you've opened an email that has an image."

Lisez bien la conséquence avant de faire un rapport de campagne. Le taux d'ouverture est désormais une borne haute composée surtout de récupérations automatiques, et les comptes gonflent pour les segments qui comptent le plus d'utilisateurs d'Apple Mail, ce qui veut dire que comparer des taux d'ouverture entre segments revient à comparer des clients de messagerie. Les clics exigent encore un humain, ce qui explique pourquoi le taux de clic, et le revenu attribué au clic, survivent au changement. Le même raisonnement vaut pour le suivi côté serveur sur le web : plus la mesure est proche d'une action qu'une personne a dû accomplir, moins elle dépend d'une bizarrerie d'affichage.

Un pixel de suivi est-il la même chose qu'un web beacon ou un spy pixel ?

Oui, ce sont trois noms pour un seul mécanisme avec des connotations différentes. "Web beacon" est l'ancien terme neutre, "tracking pixel" est le terme des fournisseurs, et "spy pixel" est celui qui s'est imposé quand les journalistes ont commencé à compter combien d'e-mails marketing en contiennent un. Le HTML est identique dans les trois cas.

En repérer un demande un panneau réseau et rien d'autre. Filtrez les requêtes par type image, triez par taille, et cherchez les réponses de quelques centaines d'octets ou moins dont l'URL porte un identifiant et un nom d'événement. Dans un e-mail, afficher le message brut et chercher dans le HTML les balises img avec un width ou un height de 1 trouve la même chose avant que le client n'affiche quoi que ce soit.

Ce qui varie, c'est la transparence et la juridiction, pas la technologie. Un pixel qui rapporte un achat à une plateforme publicitaire, un autre qui mesure si une newsletter a été livrée, et un troisième qui empreinte un lecteur d'un site à l'autre se ressemblent tous dans le balisage et sont traités très différemment par le droit de la vie privée. L'élément ne dit rien de l'intention ; le domaine de destination et les paramètres de l'URL, si.

Questions fréquentes

Pourquoi un pixel de suivi fait-il 1x1 ?

Parce qu'il doit être demandé sans être vu. Un pixel est la plus petite image valide, et il est en général masqué avec display:none ou accordé au fond pour que rien ne bouge dans la mise en page.

Un pixel de suivi peut-il lire mon adresse e-mail ?

Seulement celle déjà encodée dans son URL. Les expéditeurs ajoutent un identifiant de destinataire à la chaîne de requête avant l'envoi, donc le pixel renvoie l'identité qu'ils avaient déjà, pas une qu'il aurait découverte.

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

Les listes de blocage comparent l'URL de la requête, donc un pixel pointant vers un domaine publicitaire connu est bloqué comme toute autre requête vers ce domaine. Un pixel servi depuis le domaine du site lui-même est plus difficile à classer pour une liste.

Mail Privacy Protection d'Apple bloque-t-il les pixels ?

Il ne bloque pas la récupération. Apple télécharge le contenu distant en arrière-plan par défaut, que le message soit consulté ou non, et le fait passer par deux relais, donc la requête arrive quand même mais l'ouverture, l'horodatage et l'adresse IP cessent de vouloir dire ce que l'expéditeur suppose.

Un pixel peut-il poser un cookie ?

Sa réponse peut envoyer Set-Cookie pour son propre domaine, ce qui en fait un cookie third-party quand le pixel se trouve sur la page de quelqu'un d'autre. Que le navigateur le stocke et le renvoie ensuite dépend de ses règles sur les cookies third-party.

Un pixel de suivi est-il une donnée personnelle au sens du RGPD ?

L'image non, les données qu'elle collecte peuvent l'être. Une adresse IP plus un identifiant de destinataire dans une chaîne de requête identifient une personne, et c'est ce test qui compte, pas le format de fichier.

Un pixel de suivi fonctionne-t-il si JavaScript est désactivé ?

Un pixel n'a besoin d'aucun JavaScript pour fonctionner. Le code de base de Meta inclut justement un repli <noscript> construit avec une simple balise <img>, car charger n'importe quelle image force le navigateur à faire la requête, script ou non. C'est tout le mécanisme : demander l'URL et enregistrer le passage.

Pourquoi les pixels de suivi renvoient-ils une image vide ou une réponse 204 ?

L'expéditeur ne lit jamais ce qui revient. Seul compte le fait que la requête atteigne le serveur et soit enregistrée, donc les points de terminaison répondent par un GIF transparent de 1x1 ou un 204 No Content vide plutôt que par un contenu réel. Le display:none appliqué à l'élément suit la même logique, rien dans l'image n'est censé se voir.

Un pixel de suivi peut-il compter combien de fois un e-mail a été ouvert ?

Pas de façon fiable. Protect Mail Activity d'Apple se déclenche à chaque téléchargement en arrière-plan, que le message soit lu ou non, si bien que les ouvertures répétées ne se distinguent pas de la première. Gmail met l'image proxied en cache, ce qui peut faire disparaître complètement une seconde ouverture.

Un pixel de suivi sait-il sur quelle page se trouve quelqu'un ?

Presque jamais au-delà du domaine. Les navigateurs utilisent par défaut strict-origin-when-cross-origin, qui envoie le chemin complet uniquement pour les requêtes de même origine et le réduit à l'origine pour les requêtes intersites. Un pixel tiers connaît donc le domaine qui l'a intégré, pas la page précise, sauf si le propriétaire du site a lui-même écrit le chemin dans la chaîne de requête.