Filtrer le trafic invalide d'une plateforme publicitaire : ce que votre équipe peut construire et quand acheter un fournisseur de vérification

Construisez vous-même le filtrage du trafic invalide général, et achetez la détection du trafic sophistiqué à un fournisseur de vérification, sauf si vous pouvez vous offrir votre propre équipe antifraude. Le trafic invalide général, comme les adresses connues de centres de données, les bots déclarés et les publicités invisibles de 1x1, se repère avec des listes et des règles. Vos propres ingénieurs peuvent les appliquer à l'arrivée d'une requête, puis à nouveau dans les journaux. Le trafic invalide sophistiqué, comme les appareils détournés et les applis usurpées, demande des données issues de bien plus de trafic qu'une seule plateforme n'en voit, et des analystes qui l'étudient. Les programmes de certification comme celui de TAG attendent aussi un filtrage par un tiers qualifié.

Qu'est-ce qui compte comme trafic invalide ?

Le Media Rating Council (MRC) est l'organisme américain qui accrédite la mesure publicitaire. Son Invalid Traffic Detection and Filtration Standards Addendum (la mise à jour de juin 2020, consultée le 27 octobre 2026 comme les autres sources ici) répartit le trafic invalide en deux catégories. Le trafic invalide général, ou GIVT, est le « trafic identifié par des moyens de filtrage courants, exécutés par l'application de listes ou d'autres contrôles de paramètres normalisés ». Parmi les exemples du MRC :

• Le trafic invalide connu provenant de centres de données
• Les bots, les robots d'indexation et autres crawlers
• Les requêtes de user agents qui ne sont pas des navigateurs ou de navigateurs inconnus
• Les pages préchargées ou pré-rendues qu'aucun utilisateur réel n'a ensuite vues
• Les emplacements invisibles, comme les publicités de 0x0 ou 1x1 pixel

Le trafic invalide sophistiqué, ou SIVT, couvre « des situations plus difficiles à détecter, qui nécessitent des analyses avancées, une corroboration ou une coordination entre plusieurs points, une intervention humaine importante, etc., pour être analysées et identifiées ». Parmi les exemples du MRC :

• Les logiciels d'automatisation et les émulateurs
• Les appareils infectés et détournés
• L'activité humaine rémunérée et organisée, comme les fermes à clics
• Les clics et les redirections forcés
• Les événements de mesure falsifiés
• Les domaines et les applis usurpés

Quels filtres nos propres ingénieurs peuvent-ils construire ?

La catégorie générale est faite pour être partagée. Le MRC écrit que le filtrage du GIVT « est destiné à être cohérent d'un fournisseur à l'autre », c'est pourquoi il s'appuie sur des listes communes. Une équipe interne travaille avec deux d'entre elles :

• La IAB/ABC International Spiders & Bots List, que l'Alliance for Audited Media tient à jour pour le compte de l'IAB Tech Lab
• La Data Center IP List, que le Trustworthy Accountability Group (TAG) publie chaque mois

En plus des listes, l'équipe écrit des règles pour les user agents, les tailles de publicité et les requêtes de préchargement, appliquées à l'arrivée d'une requête puis à nouveau lors de la journalisation des événements. Elle garde aussi une trace de chaque requête filtrée et de son motif, pour pouvoir expliquer les chiffres aux partenaires.

Pour les sociétés de mesure qu'il audite, le MRC fixe un point de départ pour le trafic des centres de données. Elles doivent filtrer le trafic invalide provenant d'adresses IP « des trois plus grands hébergeurs connus : Amazon AWS, Google et Microsoft ». Des exceptions évitent de filtrer par erreur les vrais utilisateurs qui accèdent au web par ces réseaux.

Le filtrage peut intervenir à deux moments. En amont, la plateforme bloque une requête publicitaire ou renonce à enchérir dessus. En aval, elle supprime les événements invalides des journaux et des comptages. Le MRC écrit : « Chaque technique a certaines forces et certaines faiblesses, et les deux ont leur place dans une stratégie de protection du trafic bien menée. » Bloquer tôt économise en plus le coût de traitement d'une requête qui serait de toute façon écartée plus tard.

Les listes perdent de leur efficacité à mesure que les navigateurs et les applis partagent moins de données. Dans une mise à jour de 2024, le MRC l'a formulé ainsi : « Une adresse IP limitée ou absente et une chaîne User Agent (UA) moins détaillée peuvent affaiblir les approches fondées sur des listes. »

Quand un fournisseur de vérification vaut-il son prix ?

La détection du trafic sophistiqué repose sur la capacité à voir des schémas à travers de nombreux éditeurs, applis et appareils, et sur des analystes qui suivent les nouvelles fraudes à mesure qu'elles apparaissent. Une plateforme ne voit que son propre trafic, elle passe donc à côté des schémas qui n'apparaissent qu'à travers de nombreuses plateformes. Une équipe qui fait bien ce travail équivaut à une société antifraude au sein de votre société.

La certification peut trancher la question. Le programme Certified Against Fraud de TAG cite parmi ses exigences clés que « 100% de leurs transactions monétisables soient filtrées pour la détection et la suppression de l'IVT par un tiers qualifié ». TAG permet aux éditeurs de la remplir via une supply-side platform qui détient un sceau de certification valide. Si vos acheteurs ou partenaires demandent la certification TAG, des filtres construits par vos soins ne suffiront pas à eux seuls à remplir cette exigence.

Le MRC publie la liste des services qu'il accrédite. Sa liste numérique comprend des sociétés de vérification comme DoubleVerify, HUMAN, Integral Ad Science, Pixalate et Protected Media. L'accréditation porte sur des services et des métriques précis, demandez donc à un fournisseur lesquels de ses services sont accrédités et si cela inclut le trafic invalide sophistiqué.

Construire, acheter ou les deux : que couvre chaque voie ?

• En interne seulement : vous repérez le trafic invalide général pour le prix du temps de vos ingénieurs et d'éventuels abonnements à des listes, et les règles comme les données vous appartiennent. Les fraudes sophistiquées passent à travers, et les exigences de filtrage par un tiers restent non remplies.
• Un fournisseur seulement : les deux catégories sont détectées, mais chaque décision dépend des systèmes et des tarifs du fournisseur, et un contrôle du fournisseur dans le chemin d'enchère allonge chaque requête.
• Les deux : vos propres filtres écartent tôt et à faible coût le trafic évident, et le fournisseur ne voit que le trafic qui les a passés.

Que doit journaliser la plateforme, quelle que soit la voie ?

Celui qui se charge de la détection a besoin du détail de chaque transaction publicitaire. Le MRC énumère les champs qu'une société de mesure doit collecter lorsque c'est possible, dont :

• Le type d'événement, un identifiant de transaction et un horodatage
• L'adresse IP, y compris l'en-tête X-Forwarded-For quand le trafic passe par des proxys
• La chaîne user agent complète et le type d'appareil
• L'identifiant de l'appli, ou l'URL complète de la page où la publicité a été diffusée
• Les identifiants de l'éditeur, du site et de l'emplacement, ainsi que les informations ads.txt ou app-ads.txt de l'éditeur
• Les attributs OpenRTB de la requête d'enchère

Les rapports doivent séparer les chiffres bruts et les chiffres filtrés. Pour les rapports de campagne, la norme du MRC énumère « Gross Metrics (Completely Unfiltered) » et « Net Metrics (Filtered for GIVT Requirements) ». Lorsqu'ils s'appliquent, les chiffres filtrés du trafic invalide sophistiqué apparaissent comme une étape distincte. Si votre pipeline d'événements perd déjà des événements ou les compte deux fois, corrigez cela d'abord : le filtrage ne peut pas réparer des chiffres qui étaient faux avant lui.

Que demander à une société qui intègre le filtrage à notre plateforme ?

• À quel endroit du chemin d'enchère tourne chaque filtre, et combien de temps ajoute-t-il à une requête ?
• Si le contrôle du fournisseur ne répond pas à temps, la requête passe-t-elle ou est-elle écartée ?
• Comment les listes sont-elles mises à jour, et qui vérifie que de vrais utilisateurs ne sont pas filtrés par erreur ?
• Comment les chiffres bruts et filtrés apparaîtront-ils dans nos rapports et dans ceux de nos partenaires ?
• Quels champs de chaque requête sont stockés, pendant combien de temps et selon quelles règles de confidentialité ?

La dernière question compte aussi pour le MRC. Sa mise à jour de 2024 dit que « les réglementations sur la vie privée ne sont pas un obstacle à contourner par l'ingénierie, mais des exigences strictes qui doivent être respectées ».

Où se situe amBrain ?

amBrain, qui publie ce blog, construit les systèmes auxquels le filtrage se raccorde. L'une de ses lignes dit : « amBrain construit des ad servers : ciblage, capping de fréquence et reporting. » Une autre dit : « amBrain construit des pipelines d'analytique d'événements pour l'ad tech : collecte, traitement et reporting des événements d'impression et de clic. » Ses travaux en AdTech comprennent RTBBidder, une demand-side platform qu'elle a construite pour un client.

amBrain développe des logiciels depuis 2019 et travaille en trois formats : la prestation complète, une équipe dédiée ou des ingénieurs intégrés à votre équipe. Sur la propriété, sa formule est : « Le client conserve la pleine propriété du produit et du code, à l'exception de nos composants réutilisables. »

Cet article n'est pas une étude de cas. Il ne dit pas qu'amBrain a construit de la détection de fraude pour un client ni qu'elle propose de la vérification. Si amBrain figure sur votre liste restreinte, posez-lui les mêmes questions qu'à n'importe quelle autre société.