Utiliser ads.txt & sellers.json pour l'intelligence publicitaire (Guide pratique)

ads.txt et sellers.json sont deux petits fichiers texte hébergés publiquement qui, lus ensemble, indiquent qui est autorisé à vendre l’inventaire publicitaire d’un éditeur et qui possède réellement un ID vendeur donné dans la chaîne. Pour la recherche concurrentielle et la chaîne d’approvisionnement, ils constituent l’une des rares sources de données réellement factuelles et vérifiables dans un secteur où la plupart des affirmations (dépenses, portée, "inventaire premium") ne peuvent pas être contrôlées. Voici comment les utiliser réellement.

Ce que chaque fichier contient, en pratique#

ads.txt se trouve à domain.com/ads.txt sur la racine de n’importe quel domaine d’éditeur, et c’est une liste texte brut de chaque entreprise autorisée à vendre l’inventaire de cet éditeur, une ligne par relation. Une ligne typique ressemble à :

google.com, pub-1234567890123456, DIRECT, f08c47fec0942fa0

Il s’agit du domaine de l’échange ou du SSP, de l’ID de compte de l’éditeur auprès de cet échange, du type de relation DIRECT (l’éditeur traite directement avec eux) ou RESELLER (un intermédiaire est impliqué), et d’un ID d’autorité de certification optionnel. sellers.json est l’image miroir, hébergé par l’échange ou le SSP à exchange.com/sellers.json, répertoriant chaque compte vendeur avec lequel l’échange travaille, leur nom (parfois), et s’ils sont un PUBLISHER, un INTERMEDIARY ou BOTH. En croisant les deux, vous pouvez confirmer si le vendeur revendiqué d’un emplacement publicitaire possède réellement une relation autorisée, ou si quelque chose ne concorde pas.

Pourquoi cela importe pour la recherche concurrentielle et la sécurité de marque#

La chaîne d’approvisionnement publicitaire entre le budget d’un annonceur et la page d’un éditeur est rarement un simple saut. Les publicités passent fréquemment par une ou plusieurs relations de inventaire revendu avant d’atterrir, et chaque saut constitue une opportunité de mauvaise représentation, d’usurpation de domaine ou de simple confusion sur qui gère réellement la publicité. ads.txt et sellers.json existent précisément pour rendre cette chaîne auditable :

• Vérifier la revendication d’un réseau. Si un réseau natif ou un DSP affirme un accès direct à l’inventaire d’un éditeur, le fichier ads.txt de cet éditeur le répertorie comme DIRECT. S’il apparaît seulement comme revendeur plusieurs sauts plus loin, ou n’apparaît pas du tout, c’est une information utile avant d’acheter.
• Détecter l’usurpation de domaine. Les opérations frauduleuses prétendent parfois représenter l’inventaire d’un éditeur premium sans aucune autorisation. Vérifier ads.txt par rapport au domaine réel de la requête d’enchère est une méthode standard, gratuite, pour le repérer.
• Comprendre pourquoi une publicité a tel aspect. Lorsque vous suivez comment les outils d’espionnage publicitaire capturent les publicités natives, le couplage ads.txt/sellers.json est souvent le moyen le plus rapide de confirmer quel réseau a réellement servi un placement donné, plutôt que de deviner à partir du style visuel du widget.
• Auditer vos propres chemins d’approvisionnement. Si vous êtes éditeur, votre propre fichier ads.txt est aussi le moyen le plus rapide de vérifier si un partenaire que vous avez coupé (ou jamais autorisé) apparaît toujours, ou si une intégration a ajouté des lignes inattendues.

Un workflow pratique en cinq étapes#

1. Récupérez le ads.txt de l’éditeur. Chargez https://[publisher-domain]/ads.txt directement dans un navigateur ou avec un script simple. C’est du texte brut, aucune authentification requise.
2. Trouvez la ligne correspondant à l’échange ou au réseau que vous enquêtez. Recherchez le domaine (par ex., taboola.com, outbrain.com ou le SSP concerné) et notez l’ID de compte éditeur ainsi que le marquage DIRECT ou RESELLER.
3. Récupérez le sellers.json de cet échange. Chargez https://[exchange-domain]/sellers.json et cherchez l’ID vendeur trouvé à l’étape 2.
4. Comparez le nom et le type du vendeur. L’entrée sellers.json correspond‑t‑elle à l’éditeur de départ ? Est‑elle listée comme PUBLISHER (comme attendu pour une relation directe) ou INTERMEDIARY (attendu pour une chaîne de revendeur) ?
5. Suivez la chaîne si c’est une relation RESELLER. Une ligne RESELLER signifie qu’une autre entité se situe entre l’éditeur et l’échange. Idéalement, cet intermédiaire devrait fournir son propre objet SupplyChain (schain) dans la requête d’enchère, qui enregistre chaque saut pour une auditabilité complète, bien que les données schain ne soient pas visibles depuis les fichiers ads.txt/sellers.json seuls ; elles nécessitent l’accès au flux d’enchères réel ou à un outil qui les capture.

Résultats courants et leur signification#

Où cela s’insère dans l’identification des réseaux publicitaires de façon plus large#

ads.txt et sellers.json sont les plus efficaces pour vérifier les relations côté offre, pas pour identifier quel réseau a réellement diffusé une publicité précise que vous examinez en tant qu’acheteur. Pour cela, on travaille généralement à partir de la chaîne de redirection du créatif, de la signature visuelle du widget, et des domaines de pixel de suivi impliqués, approche couverte dans comment identifier le réseau publicitaire derrière n’importe quelle publicité. Considérez ads.txt et sellers.json comme la trace d’audit des relations d’offre, et l’analyse créatif/redirection comme la trace d’audit de ce que l’annonceur diffuse réellement.

Notes sur les outils#

Les deux formats de fichiers sont régis par les spécifications IAB Tech Lab, et les spécifications sources constituent la référence définitive si vous rencontrez un cas limite que ces fichiers ne couvrent pas proprement, comme les configurations multi‑compte ou les champs OWNERDOMAIN. Pour des vérifications ponctuelles, un navigateur et une recherche texte suffisent réellement ; vous n’avez pas besoin d’outils payants pour une vérification occasionnelle. Ce qui devient fastidieux, c’est de le faire à grande échelle sur des dizaines d’éditeurs ou de suivre les changements dans le temps, ce qui est le rôle d’une plateforme qui indexe déjà la chaîne d’approvisionnement à travers les réseaux, évitant le travail répétitif de récupération et de comparaison. L’index d’intelligence publicitaire d’OpenAdLibrary associe ce contexte de chaîne d’offre aux créatifs en direct et aux pages d’atterrissage tracées, de sorte que vous n’avez pas à croiser manuellement trois sources distinctes pour chaque placement que vous souhaitez vérifier.

Pourquoi cela importe davantage pour le natif que cela n’y paraît au premier abord#

Les réseaux natifs revendent constamment de l’inventaire. Un seul emplacement de widget de recommandation de contenu sur la page d’un éditeur peut passer directement par le réseau, par un revendeur régional, ou par un wrapper d’enchères en-tête qui négocie plusieurs sources de demande simultanément. Parce que les publicités natives affichent rarement le type de marque visible qu’une bannière display possède, et que le widget lui‑même ressemble souvent identique quel que soit le réseau derrière, ads.txt et sellers.json sont parfois le seul moyen fiable de confirmer quel réseau détient légitimement une relation donnée avec l’éditeur, surtout lorsqu’un site éditeur exécute plusieurs widgets natifs côte à côte provenant de fournisseurs différents. C’est également la raison pour laquelle les configurations d’enchères en-tête, où plusieurs échanges concourent pour le même emplacement en temps réel, bénéficient de la même vérification : chaque échange participant doit avoir sa propre ligne autorisée dans le ads.txt de l’éditeur, et sa propre entrée correspondante dans sellers.json.

Faire cela à grande échelle vs le faire une fois#

Vérifier le fichier d’un éditeur à la main prend quelques minutes. Le vérifier pour une liste de surveillance de cinquante éditeurs, de façon récurrente, afin de repérer de nouvelles relations ou des ruptures, est un problème différent, et c’est le type de tâche qui cesse discrètement une fois la curiosité initiale dissipée, même si la valeur réside dans la répétition. Si vous intégrez cela dans un processus de recherche continu plutôt que dans une vérification ponctuelle, il est judicieux de le coupler avec le suivi de chaîne d’approvisionnement publicitaire que vous effectuez déjà pour les créatifs et les changements de pages d’atterrissage, afin que les vues côté offre et côté créatif se mettent à jour conjointement au lieu de diverger.

Note sur les limites#

Ces fichiers sont auto‑déclarés par les éditeurs et les échanges. Rien n’oblige un éditeur à maintenir son ads.txt à jour, et un fichier obsolète ou incomplet est fréquent, surtout sur les petits sites. Considérez une entrée manquante ou incohérente comme une incitation à approfondir l’enquête, pas comme une preuve automatique de fraude ; de nombreux petits éditeurs légitimes n’ont simplement pas mis à jour leur fichier récemment. La valeur d’ads.txt et de sellers.json réside dans le fait qu’ils rendent la chaîne d’approvisionnement vérifiable, pas qu’ils la rendent infaillible.