Ads.txt : une première étape vers plus de transparence dans l’univers du programmatique

Qu’est-ce qui se cache derrière le protocole ads.txt ?

Ads.txt est un fichier au format texte placé à la racine du site web de l’éditeur. Ce fichier répertorie l’ensemble des vendeurs tiers autorisés à vendre de l’espace publicitaire sur le site en question.

Un fichier ads.txt requiert trois informations obligatoires et une quatrième optionnelle :

• Nom de domaine du SSP ou de l’ ad exchange
• ID compte de l’éditeur
• Business modèle du vendeur
• ID de l’autorité de certification de l’éditeur (optionnel)

La forme que prend une ligne ads.txt est par exemple la suivante : « editeur123.com, 9876, DIRECT, f088dbbfd73d86c8 ». Le fichier ads.txt contient donc autant de lignes que de vendeurs tiers autorisés à vendre de l’espace publicitaire pour le site de l’éditeur. Ce système implique donc un suivi rigoureux de la part des éditeurs afin de tenir le fichier à jour et de s’assurer que des bid requests (demandes d’enchères) ne seront pas perdues inutilement. En effet, en l’absence de la ligne correspondant à un vendeur tiers donné dans le fichier ads.txt, sa bid request sera considérée comme invalide (car potentiellement frauduleuse), et sera donc rejetée.

Comment ads.txt permet-il de lutter contre la fraude publicitaire ?

Ads.txt vise à éliminer l’usurpation du nom de domaine (domain spoofing). En effet, lors d’une bid request en OpenRTB, l’annonce peut être diffusée sur une myriade de sites web. Mais certains sites sont contrefaits, se faisant passer pour des sites (premium ou reconnus au choix). Ads.txt garantit ainsi aux annonceurs qu’un vendeur tiers est bien agréé à vendre de l’espace publicitaire pour le compte d’un site.   

Les DSP vont, dans un premier temps, indexer les sites sur lesquels des bid requests sont effectuées, afin de s’assurer qu’un fichier ads.txt est bien présent. Plusieurs cas de figures peuvent alors se présenter :  

• L’absence d’un fichier ads.txt : la DSP ne poursuivra pas le processus d’achat car elle n’est pas en mesure de vérifier si le revendeur est certifié ou non.
• Le fichier ads.txt est présent mais le vendeur tiers ne figure pas dans le fichier : la DSP ne poursuivra pas le processus d’achat car il s’agit très probablement d’un fraudeur.
• Le fichier ads.txt est présent et le vendeur tiers est référencé : la DSP poursuit le processus d’achat car le vendeur tiers est bien identifié comme revendeur certifié.

Vous avez tout suivi ? Prenons un exemple simple pour vérifier ! Un annonceur qui pensait acheter un inventaire publicitaire sur domainepremium.com est victime d’usurpation du nom de domaine et achète en réalité sur factice-domainepremium.com. Pour remporter les enchères de l’annonceur, factice-domainepremium.com proposait des CPM bien moins élevés que domainepremium.com, ce qui avait pour tendance de tirer les CPM vers le bas.

L’arrivée d’ads.txt peut donc avoir un impact sur les CPM auprès de certains annonceurs, du moins ceux ayant été victimes de sites frauduleux ! Toutefois, aujourd’hui, ads.txt permet aux annonceurs de gagner en transparence et de s’assurer que les vendeurs auprès desquels ils achètent des inventaires sont bien autorisés à vendre de l’espace publicitaire pour l’éditeur en question. Mais attention, cela ne garanti pas la qualité de l’inventaire pour autant !  

Le passage à l’OpenRTB 3.0, ou le futur du programmatique

Malgré l’arrivée d’ads.txt, un vendeur d’inventaire identifié comme certifié pour revendre de l’espace publicitaire peut très bien faire passer des inventaires display pour des inventaires vidéo par exemple, afin de revendre l’espace publicitaire à un CPM plus élevé.

Dans l’objectif de garantir davantage de transparence entre éditeurs et annonceurs, l’IAB lancera donc ads.cert, une initiative complémentaire aux fichiers ads.txt, qui fera son apparition avec l’arrivée de l’OpenRTB 3.0. Cette mise à jour majeure du protocole OpenRTB initiée par l’IAB vise en effet à améliorer la transparence des deals en RTB grâce à une signature authentifiée des impressions (ads.cert) et à réduire la structure du code afin d’accélérer le processus d’enchères en temps réel. Alors qu’ads.txt vise à éviter la fraude en contrôlant l’identité des revendeurs, ads.cert a donc pour vocation de garantir à l’annonceur la bonne qualité de l’inventaire acheté auprès des revendeurs.

Ads.cert s’appuie sur un mécanisme de double vérification initié en 2004, le DKIM (DomainKeys Identified Mail) visant à stopper l’email spoofing (usurpation d’identité par email). Le principe est simple : l’éditeur publiera une clé publique au sein d’un fichier ads.cert disponible sur son site. Lorsque des bid requests seront effectuées, l’éditeur encryptera les informations liées à l’inventaire avec une clé privée. Ainsi, seule la clé publique mise à disposition des annonceurs via le fichier ads.cert sera en mesure de décrypter les informations envoyées lors de la bid request et de garantir l’authenticité de l’inventaire proposé par le revendeur.

Avec un système de double vérification combinant ads.txt et ads.cert, les éditeurs seront donc en mesure de garantir aux annonceurs une chaîne de traçabilité des bid requests du début à la fin du processus d’achat en « temps réel ». En combinant les deux protocoles de sécurité ads.txt et ads.cert, l’IAB souhaite mettre un terme à cet eldorado qu’a longtemps été l’OpenRTB pour tous les acteurs frauduleux, qui ont su profiter des failles d’un système automatisé et peu transparent. Ces initiatives ont été initiées dans le but d’offrir plus de transparence aux annonceurs et de protéger davantage les éditeurs, pour un écosystème publicitaire plus vertueux.

Néanmoins, il ne serait pas étonnant de voir apparaître de nouvelles initiatives de lutte contre la fraude basées sur des technologies plus récentes (la blockchain pour ne citer qu’elle) au cours des prochaines années. Affaire à suivre !