First-party vs third-party : pourquoi une analytique est bloquée

« First-party » et « third-party » ont des airs de jargon, mais cette distinction est la seule chose qui décide si les bloqueurs de pub peuvent cacher votre trafic. Voici ce que signifient ces termes et pourquoi ils comptent pour l'exactitude.

La distinction tient à la destination de la requête

Quand une page charge un script d'analytique, le navigateur fait une requête réseau pour le récupérer, puis pour envoyer les données. La question clé est : cette requête va-t-elle vers votre domaine ou vers celui de quelqu'un d'autre ?

• L'analytique third-party charge son script depuis — et envoie les données vers — un domaine qui n'est pas le vôtre : google-analytics.com, googletagmanager.com ou un domaine de fournisseur d'analytique partagé utilisé sur des milliers de sites.
• L'analytique first-party charge et envoie vers votre propre domaine (ou un sous-domaine). Pour le navigateur, cela ressemble à n'importe quelle autre requête que votre site fait pour son propre contenu.

Pourquoi les requêtes third-party sont bloquées

Les bloqueurs de pub et de traqueurs fonctionnent à partir de listes de domaines de suivi third-party connus. google-analytics.com figure sur toutes. Quand uBlock Origin, Brave Shields ou le mode strict de Firefox voit une requête vers un domaine de la liste, il l'annule avant qu'elle ne quitte le navigateur. Le script ne se charge jamais ; les données ne partent jamais. Aucune visite enregistrée, aucun avertissement dans votre tableau de bord.

C'est voulu, et cela ne va pas disparaître. Les listes de blocage sont maintenues par des communautés précisément pour stopper le suivi inter-sites, et les domaines d'analytique third-party en sont la cible classique.

« Mais Plausible et Fathom sont privacy-first — ce sont les bons, non ? »

Privacy-first concerne les données qu'un outil collecte. Le blocage concerne la destination de la requête. Ce sont des axes différents. Plausible et Fathom collectent très peu et n'utilisent pas de cookies, ce qui est excellent — mais leur configuration par défaut charge tout de même le script depuis un domaine de fournisseur partagé, donc les listes de blocage les plus agressives captent une partie de leur trafic aussi.

Toutes proposent un contournement : un proxy first-party qui fait passer la requête d'analytique par votre propre domaine. Ça marche — mais c'est une configuration que vous devez mettre en place et maintenir, et beaucoup d'utilisateurs ne le font jamais, restant ainsi sur le réglage par défaut blocable. Voyez les détails en face à face sur Logly face à Plausible et Logly face à Fathom.

Ce que first-party ne résout pas

First-party règle le problème du blocage, mais ce n'est pas magique. Cela ne vous exonère pas du droit de la vie privée — un outil first-party qui pose un cookie de suivi a toujours besoin du consentement. Si un outil comme Logly se passe du bandeau, c'est parce qu'il est first-party et sans cookie et ne stocke aucune donnée personnelle ; first-party seul ne suffit pas. Et first-party ne corrige pas les problèmes de qualité de métrique comme le temps de session au temps horloge — c'est un choix de conception distinct.

À retenir

Si l'exactitude des comptages de visiteurs compte, la livraison first-party est la partie non négociable : c'est le seul moyen d'enregistrer les visiteurs avec bloqueurs, qui représentent 25 à 45 % de nombreuses audiences. Le sans-cookie et le respect de la vie privée suppriment ensuite le bandeau de consentement par-dessus. Logly est conçu first-party et sans cookie dès la base, précisément pour cette raison.