Ads.txt : quelle est la fonction de ce fichier ?

Beaucoup de sites Web sont financés par le biais des campagnes publicitaires. Grâce à elles, les Webmasters génèrent des rentrées d’argent et mettent ainsi gratuitement à disposition des visiteurs du site Web du contenu médiatique. Ainsi, un grand marché s’est créé pour les achats programmatiques (l’achat et la vente automatique d’espace publicitaire en ligne) et parfois, des sommes considérables sont en jeu. Il n’est donc pas étonnant que quelques moutons noirs batifolent également dans ce domaine et essayent d’obtenir, sans réelle performance, une part du gâteau marketing. L’IAB (Interactive Advertising Bureau), une association créée en 1998 dont la mission est de structurer le marché de la communication sur Internet, favoriser son usage et optimiser son efficacité, souhaite lutter contre la fraude publicitaire au moyen de l’initiative ads.txt. La fraude publicitaire est la prétention d’un service publicitaire qui n’est pas du tout fourni ou seulement dans une mesure insuffisante.

L’IAB est une association internationale de la branche de l’online marketing. Son but est de renforcer la branche, développer des standards et améliorer continuellement l’offre publicitaire en ligne. Dans ce cadre, l’association s’efforce de détecter et éviter les arnaques au sein de la branche. Cela concerne particulièrement les fraudes publicitaires, responsables chaque année de pertes d’argent astronomiques. Aussi bien les exploitants publicitaires que les éditeurs sont concernés par ce type d’arnaque : alors que les agences publicitaires investissent leur argent dans des escroqueries, sans pouvoir obtenir une contrepartie, les Webmasters perdent quant-à-eux d’importantes rentrées d’argent au profit des cybercriminels.

Beaucoup de choses fonctionnent de manière automatique dans l’achat programmatique : les éditeurs offrent de l’espace publicitaire sur leurs pages (par exemple sur des magazines en ligne ou des blogs) et des annonceurs achètent ou enchérissent pour ces emplacements. La plupart du temps, l’achat ou la mise aux enchères se fait par le biais d’un intermédiaire, en règle générale via une plateforme sur laquelle se déroulent des ventes ou des ventes aux enchères. Dans cet environnement, les cybercriminels ont souvent recours à l’usurpation du nom de domaine : les annonceurs croient ainsi acheter un emplacement publicitaire d’un éditeur renommé (par exemple le site Internet d’un journal de renommée internationale) alors que les publicités seront en fait affichées plus tard sur une toute autre page.

La plateforme sur laquelle se trouve la fraude publicitaire ne doit pas être dénoncée comme escroc, car, souvent, les gérants ne savent pas du tout qu’il y a des arnaque en ligne sur leur site Web. Les cybercriminels feignent, via la fraude publicitaire, que le site Web sur lequel vous voulez faire de la publicité est un site différent, beaucoup plus renommée. En d’autres termes, ils cachent l’identité de leur présence sur le Web. On parle aussi dans ce cas d’occultation de site Web. Le site Web réellement utilisé a généralement peu de trafic et souvent une mauvaise réputation, ce qui pourrait porter atteinte à l’annonceur même. Le fichier ads.txt est destiné à prévenir de telles escroqueries.

IAB utilise « Ads » comme acronyme pour « Authorized Digital Sellers ». Cependant, « Ad » est aussi connu par beaucoup de personnes comme une abréviation d’ « Advertising » (publicité). Dans ce texte de fichier simple, les éditeurs doivent dresser la liste de tous les fournisseurs autorisés à vendre leur inventaire publicitaire (c’est-à-dire l’ensemble des espaces publicitaires disponibles à la vente à une moment donné, pour une période donnée et un support publicitaire donné). Le fichier permet aux éditeurs d’avoir davantage leur mot à dire dans le commerce de l’espace publicitaire. Parallèlement, le fichier garantit une plus grande transparence, car il précise exactement avec quels fournisseurs il faut coopérer.

Les éditeurs enregistrent le fichier ads dans le répertoire racine qui est le répertoire supérieur du site Web. Ici s’y trouve également le fichier robots.txt qui fournit les informations pour les crawlers des moteurs de recherche. L’ads.txt peut également être traité par des crawlers. Le fichier de texte est ouvertement accessible et peut être aussi bien lu par des machines que par des humains.

Puisque le fichier se trouve dans le répertoire racine et doit impérativement s’appeler ads.txt (example.com/ads.txt), il peut être trouvé facilement et rapidement. Les annonceurs et les plateformes peuvent ainsi vérifier si la vente par le commerçant correspondant est autorisée. Lorsqu’un éditeur est listé sur une place de marché publicitaire et que le fichier d’annonces correspondant peut être vérifié par toutes les parties concernées, alors les risques d’escroqueries diminuent fortement. Il devient en effet plus difficile aux arnaqueurs de simuler une fausse identité qui n’est pas listée par ads.txt.

Grâce au fichier ads.txt, il est maintenant possible de vérifier s’il s’agit d’une offre véridique ou non. Quelques places de marché publicitaires, comme par exemple Google, ont déjà mis en œuvre cette norme sur leur propre plateforme. Si un éditeur vient à mettre son inventaire à disposition, alors l’ads.txt est automatiquement crawlé. Si l’éditeur n’a pas mentionné sa place de marché publicitaire dans son fichier ads.txt, aucune transaction ne pourra alors avoir lieu.

Puisque l’ads.txt n’est qu’un simple fichier de texte, il peut être aussi créé avec un simple éditeur de texte. Seules trois indications sont nécessaires par vendeur autorisé, la quatrième est optionnelle.

• Le nom de domaine du vendeur : sous quel domaine est enregistré l’entreprise qui est autorisée à vendre l’inventaire publicitaire. Le nom correct peut souvent être vérifié directement ou bien il faut contacter le fournisseur pour connaître le nom de domaine exact. Pour des offres Google, par exemple, le nom correct est toujours google.com.
• L’identifiant du compte : si quelqu’un est enregistré comme éditeur auprès d’un fournisseur, alors il dispose d’une identification de compte. Le même identifiant est également spécifié lors d’une transaction.
• Relation avec le fournisseur : il est possible d’y entrer deux valeurs différentes. En entrant DIRECT, cela signifie que l’éditeur prend lui-même la gestion de son inventaire sur la plateforme (sous l’ID qui a été entrée dans le second champ). L’entrée RESELLER indique que l’éditeur a légué la gestion à un tiers.
• ID auprès d’un organisme de certification (optionnel) : lorsque le système publicitaire est répertorié auprès d’un organisme de certification, l’ID correspondant peut être donné. L’un de ces organismes est par exemple le Truthworthy Accountability Group (TAG). TAGID serait alors entré lors d’une inscription.

Tous les champs sont listés les uns après les autres à l’intérieur d’une ligne, les champs individuels sont séparés par une virgule. Si vous voulez inclure des explications dans le fichier que les robots ne devraient pas prendre en compte, vous devez les exclure avec le signe dièse (#). Tout ce qui se trouve après le dièse sera ignoré. Si le signe se trouve au tout début d’une ligne, alors la ligne complète ne sera pas prise en compte.

En plus des entrées des vendeurs et les commentaires, la norme permet d’indiquer deux autres informations : CONTACT et SOUS-DOMAINE. Ces deux valeurs seront entrées dans le fichier sous le format Variable=Valeur. Par exemple : CONTACT=example.com/notre_histoire. Alors que la première indication spécifie une seule option de contact, la deuxième indication se réfère à un fichier ads.txt dans un sous-domaine. Sans la mention sur ce deuxième fichier texte, les bots l’ignoreraient parce que, fondamentalement, seul le répertoire racine du domaine principal est crawlé.

Que vous souhaitiez créer vous-même un fichier ads ou le faire créer par un tiers, vous devez travailler en collaboration avec beaucoup d’autres plateformes. L’effort n’est pas particulièrement important. Si vous êtes vous-même éditeur et voulez à l’avenir protéger votre inventaire publicitaire d’arnaques, vous pourrez créer le fichier de texte nécessaire en seulement quelques étapes. Pour cela, ouvrez un éditeur de texte (par exemple un éditeur sous Windows ou TextEdit sous Mac) et entrez les paramètres requis pour les vendeurs avec lesquels vous travaillez. Dans notre exemple, il s’agit d’un partenariat commercial entre Google et notre blog fictif sur lequel nous proposons des espaces publicitaires.

Par la présente, nous attestons avoir deux comptes différents sur Google. Les identifiants de compte Google suivent toujours le même schéma : pub- (pour Publisher donc éditeur en français) est suivi d’une séquence de 16 numéros. Quelques éditeurs ont plusieurs comptes sur les plateformes, même lorsque vous êtes, comme dans notre exemple, connecté à AdSense et Ad Exchange. Nous gérons nous-même notre inventaire dans les deux comptes et puisque Google dispose d’un TAGID unique, nous l’incluons également.

Pour améliorer la clarté et fournir plus d’informations aux intéressés, nous précisions sous forme de commentaires de quel type de comptes il s’agit exactement. Enfin, nous fournissons également une adresse e-mail, sous laquelle nous pouvons être contacté.

Alors que l’ordre des paramètres individuels est solidement défini, vous pouvez choisir librement l’ordre des plateformes de vente autorisées. Quelques éditeurs divisent, par exemple, votre liste de cette manière, de telle sorte que toutes les entrées DIRECT viennent en premier, puis toutes les entrées RESELLER. Cependant, il ne doit y avoir aucun espace vide, aucune tabulation ou virgule dans les paramètres individuels. Si cela est nécessaire, parce qu’un espace vide peut appartenir à un ID par exemple, il faut utiliser l’encodage URL : cette méthode, également connue sous le nom de codage en pourcentage, utilise le code hexadécimal du caractère dans le jeu de caractères ASCII et le place directement après un signe en pourcentage. Par exemple, un espace est représenté par la chaîne de caractères %20.

Lors de la sauvegarde de votre fichier, veillez à ce que celui-ci soit vraiment sauvegardé comme fichier .txt avec le nom ads. Téléchargez maintenant l’ads.txt dans le répertoire racine de votre serveur. Cela est par exemple possible avec un programme FTP. Le répertoire racine est le répertoire le plus élevé hiérarchiquement parlant. Maintenant, vous pouvez appeler le fichier via example.com/ads.txt.

Lorsque l’on travaille avec beaucoup de plateformes, l’utilisation d’un générateur en ligne peut valoir la peine.  Quelques-uns d’entre eux proposent le service en échange de votre adresse e-mail. D’autres, comme par exemple le générateur dans le réseau DFP Google n’ajoutent que les entrées de votre propre place de marché dans le fichier de texte.

Avec un validateur ads.txt, vous pouvez vérifier si votre fichier d’autorisation a été créé correctement qu’aucune erreur ne s’y est glissée. En règle générale, pour la plupart des validateurs, il suffit d’entrer l’URL dans le masque de saisie. Quelques services Web offrent aussi la possibilité de télécharger directement le fichier et de le vérifier sur votre propre espace Web avant de le rendre public. Le validateur ads.txt d’AppNexus, un fournisseur de la plateforme de publicité programmatique permet même aux utilisateurs d’exécuter des modifications du fichier directement dans la boîte à outils, de le faire vérifier immédiatement et de télécharger le nouveau fichier. Bien entendu, vous devez vous-même transférer le fichier ads.txt modifié sur votre serveur.

En effet, un validateur ads.txt vérifie seulement que la syntaxe des entrées est correcte. Les outils en ligne ne vérifient pas si les indications correspondent à la réalité. Cela est surtout important pour les annonceurs : avec un validateur, vous ne pouvez pas encore vérifier si l’éditeur travaille réellement avec ladite plateforme.

Comme beaucoup de normes, le fichier ads.txt n’a pas pu s’imposer dès le début. Une raison pour cette utilisation en demi-teinte dans la branche concernait certainement l’incertitude : comment le fichier pourrait-il influer sur le propre business ? Ce n’est que lorsque le poids lourd Google a soutenu l’initiative et a annoncé d’insister dès à présent sur l’utilisation du fichier qu’ads.txt a progressivement prévalu.

Un point qui a créé de l’incertitude au sein de l’industrie est qu’il est difficile de revendre les inventaires.  Les fournisseurs achètent l’espace publicitaire à partir d’une plateforme et le revendent par leurs propres moyens. Il ne se cache pas toujours derrière cela une action criminelle, mais ads.txt empêche un tel comportement. Les éditeurs n’ont aucun lien direct avec ces revendeurs et ne savent souvent rien de ces processus. C’est pourquoi les fournisseurs n’apparaissent pas dans le fichier ads.txt. Quelques-uns de ces revendeurs ont donc ciblé les éditeurs, ce qui a suscité beaucoup de discussions au sein de l’industrie et a été perçu par beaucoup comme une tentative de fraude.

Un point critique que rencontre beaucoup de vendeurs concerne la création manuelle du fichier : il n’est pas garanti qu’il n’y ait pas d’erreurs de frappe. Une erreur a vite fait de se glisser dans le nom de domaine et l’inventaire de l’éditeur ne peut donc plus être négocié sur la plateforme. Aussi bien les fournisseurs que les éditeurs peuvent perdre de fortes sommes d’argent. Cependant, l’utilisation d’un validateur ads.txt diminue sensiblement le risque d’erreurs typographiques : un tel validateur vérifie également s’il y a un marché publicitaire programmatique derrière le domaine. Enfin, les erreurs de frappe peuvent également être évitées grâce à une procédure minutieuse.

Un autre désavantage du fichier ads.txt concerne l’absence d’identification du type d’inventaire convenu : les éditeurs ne peuvent pas signaler via le fichier texte si le commerçant peut vendre des publicités d’affichage, des publicités vidéo ou les deux. Les plateformes peuvent ainsi continuer à prétendre que les publicités d’affichage sont en fait des espaces publicitaires pour les publicités vidéos et obtenir ainsi des commissions supplémentaires. Le fait qu’un commerçant apparaisse dans l’ads.txt ne suffit pas à affirmer avec sûreté que celui-ci ne fait pas partie des moutons noirs. La responsabilité de ne conclure aucune affaire avec des arnaqueurs repose encore sur les éditeurs.

Il faut aussi savoir que le fichier ads.txt n’est pas une solution multifonction : certes, il est possible d‘être mieux protégé contre les usurpations de domaine mais les autres formes de fraudes publicitaires restent cependant inchangées. Cette louable initiative ne peut mettre un terme à l’escroquerie de fraude à l’impression publicitaire et fraude au clic qui représentent encore une grosse perte du budget publicitaire des annonceurs.

Malgré ses points faibles, l’initiative a largement été acceptée dans la branche et influencera encore à l‘avenir le marché publicitaire. Grâce au soutien de puissants acteurs du marché comme Google ou des éditeurs bien connus, il est possible de mettre un terme à la fraude publicitaire. Les autres concurrents doivent faire de même avec l’implémentation du fichier ads.txt ou ils auront de mauvaises cartes lorsqu’ils feront du commerce avec des emplacements publicitaires en ligne.