Validateur ads.txt
Collez le contenu de votre ads.txt pour vérifier instantanément sa syntaxe. Valide ligne par ligne les champs DOMAIN, PUBLISHER_ID et RELATIONSHIP (DIRECT/RESELLER), pour vous aider à configurer correctement ce fichier essentiel contre la revente non autorisée d'inventaire publicitaire (usurpation de domaine).
Astuces
- Le format de base comporte 3 champs — DOMAIN, PUBLISHER_ID et RELATIONSHIP —, avec un quatrième champ optionnel pour l'identifiant de l'autorité de certification. Comptez les virgules pour vérifier qu'il n'en manque ni n'en reste en trop.
- RELATIONSHIP n'accepte que
DIRECT(l'éditeur du site a un contrat direct) ouRESELLER(vente via un revendeur). La casse n'est pas prise en compte selon la spécification, mais l'usage veut que l'on écrive en majuscules. - Les lignes commençant par
#sont ignorées comme commentaires. Ajouter des directives de variables telles queCONTACT=ouOWNERDOMAIN=aide les systèmes publicitaires à vérifier votre compte. - ads.txt doit être hébergé à la racine du domaine (
https://example.com/ads.txt). Placé dans un sous-répertoire, il ne sera pas reconnu par les systèmes publicitaires ni les robots d'indexation. - Il existe une spécification complémentaire pour les applications mobiles nommée
app-ads.txt. Si vous vendez de l'inventaire publicitaire à la fois sur un site web et une application mobile, vous devez héberger les deux fichiers.
Questions fréquentes
DIRECT signifie que l'éditeur du site a un contrat direct avec le système publicitaire et détient l'autorité pour vendre cet inventaire. RESELLER s'utilise lorsqu'un revendeur (comme une régie publicitaire) vend l'inventaire pour le compte de l'éditeur, avec une autorité déléguée. Si un même emplacement publicitaire est vendu via plusieurs systèmes, chaque relation doit être indiquée séparément et correctement.SUBDOMAIN= qui permet d'indiquer qu'un sous-domaine particulier utilise un fichier distinct.
Anecdote — Pourquoi ads.txt existe : une norme du secteur contre l'usurpation d'inventaire publicitaire
ads.txt (Authorized Digital Sellers) est une spécification créée en 2017 par l'IAB Tech Lab. À l'époque, la publicité programmatique était minée par ce que l'on appelle le « domain spoofing » : des fraudeurs copiaient et revendaient sans autorisation l'inventaire publicitaire d'éditeurs légitimes. Les annonceurs pensaient enchérir sur un site premium, mais leurs publicités se retrouvaient sur des pages de piètre qualité sans aucun rapport, ce qui érodait la confiance des annonceurs comme des éditeurs.
Le mécanisme est simple : l'éditeur publie, à la racine de son domaine, un fichier texte listant les systèmes publicitaires qu'il a autorisés à vendre son inventaire. Les systèmes d'achat publicitaire consultent ce fichier pour vérifier si l'inventaire sur lequel ils enchérissent est effectivement vendu via un canal officiellement approuvé par ce domaine. Ce design simple ayant un faible coût d'adoption, la majorité des grands systèmes publicitaires et éditeurs l'ont adopté comme norme du secteur en quelques années à peine.
Google AdSense promeut également l'adoption de ads.txt depuis 2019, et les sites qui ne l'ont pas correctement configuré peuvent voir une partie de leur diffusion publicitaire restreinte. Pour un site dont le modèle économique repose sur les revenus publicitaires, ads.txt n'est pas une simple recommandation : c'est, dans les faits, un réglage indispensable pour protéger ces revenus.
Comme spécifications complémentaires, l'IAB Tech Lab a également créé app-ads.txt pour les applications mobiles ainsi que sellers.json, qui publie les informations sur les vendeurs du côté des systèmes publicitaires. Ensemble, elles permettent aux annonceurs de vérifier qui vend quel inventaire et selon quelle relation, sur l'ensemble de la chaîne d'approvisionnement.