Ads.txt, which stands for “Authorized Digital Sellers,” is an IAB (Interactive Advertising Bureau) initiative aimed at improving transparency and combating ad fraud in programmatic advertising. It is a text file that publishers and website owners can create and upload to their web servers. The purpose of ads.txt is to declare which companies or entities are authorized to sell the publisher’s or app developer’s digital ad inventory. 

 

By referencing ads.txt files, ad buyers can verify that they are purchasing ad inventory from legitimate and authorized sellers. This helps reduce the risk of ad fraud, domain spoofing, and unauthorized reselling of inventory. If a publisher does not have an ads.txt file or if the file is inaccurate, it can lead to issues with ad delivery, reduced demand for their inventory, and potential revenue loss.

 

Here’s how ads.txt works:

 

1. Publisher’s Declaration: Publishers (website owners or app developers) create a text file named “ads.txt” and upload it to their web server. This file is typically placed in the root directory of the website.

 

2. List of Authorized Sellers: Within the ads.txt file, publishers list the authorized sellers, such as ad networks, exchanges, and supply-side platforms (SSPs), that are permitted to sell their ad inventory. Each authorized seller is identified by their “exchange domain” and a unique publisher identifier.

 

3. Format: The ads.txt file format consists of lines with fields separated by commas. Each line includes four fields: the domain of the advertising system, the publisher’s ID on that system, a tag indicating the relationship between the publisher and the seller (such as “DIRECT” or “RESELLER”), and an ID specific to the seller.

 

Example Line in ads.txt:

“`

example.com, 12345, DIRECT, abcde

“`

 

In this example:

– “example.com” is the domain of the advertising system.

– “12345” is the publisher’s identifier.

– “DIRECT” indicates a direct relationship with the seller.

– “abcde” is a unique ID for the seller.

 

4. Crawling and Verification: Ad exchanges and buyers’ demand-side platforms (DSPs) crawl websites to find and read the ads.txt files. They verify that the sellers listed in the ads.txt files match the actual domains and IDs of authorized sellers.

 

While Ads.txt (Authorized Digital Sellers) is a valuable tool for increasing transparency and combating ad fraud in programmatic advertising, it does have some limitations and challenges:

 

Manual Implementation: Ads.txt requires publishers to manually create and maintain the text file on their web servers. This can be time-consuming and prone to errors, especially for large websites with dynamic inventory. Also, files are static and do not support real-time updates. This means that changes, such as adding or removing authorized sellers, may not be immediately reflected in the ads.txt file.

 

Limited Enforcement: Ads.txt is a self-regulatory initiative, and its effectiveness depends on industry-wide adoption and compliance. Not all publishers and advertising platforms adhere to Ads.txt, which means some fraudulent activity can still occur.

 

Variability in Implementation: The way publishers and advertising platforms interpret and implement Ads.txt can vary. This variability can make it more complex for DSPs and ad exchanges to consistently enforce it.

 

Non-Human Traffic: Ads.txt is effective at reducing domain spoofing, but it may be less effective at detecting non-human (bot) traffic, which can still generate invalid impressions and ad fraud.

 

Adoption Challenges: Ads.txt was primarily designed for websites, and its application in mobile apps is less straightforward. While solutions for mobile apps exist, they are not as widely adopted or standardized. Also, small publishers or those with limited technical resources may face challenges in implementing and maintaining Ads.txt files. As a result, they may be more vulnerable to fraud.

 

Limited Effect on Header Bidding: Ads.txt may not have a significant impact on header bidding environments, where auctions occur outside the publisher’s ad server. Header bidding relies on other methods, such as app-ads.txt, to achieve transparency.

 

Despite these limitations, Ads.txt remains a valuable tool for enhancing transparency and reducing some forms of ad fraud in programmatic advertising. However, relying solely on Ads.txt for verification can lead to a false sense of security. Additional fraud prevention measures, such as ads.cert, supply path optimization, and third-party verification, are often necessary to address various types of ad fraud.  Looking for more tips on DSP buying, check out our best practices: https://populationscience.com/mastering-demand-side-platform-dsp-buying-best-practices-for-success/