Written by:
Sellers.guide team
Ads.txt is a great initiative. But, it's not living to its full potential.
Since the introduction of ads.txt in 2017, it has seen increasing adoption rates throughout the digital publishing and advertising communities. The main challenge of ads.txt is that once implemented, most publishers don't maintain it or validate new sellers' lines before adding them to the file, practically exposing themselves to fraud and malpractice.
This blog will go over what ads.txt is, how it works, and what best practices we've learned since it was created (If you are already familiar with ads.txt, skip to the end for the best practices for managing your ads.txt file).
The Ads.txt initiative from the IAB Tech Lab aims to increase brand confidence in buying authentic publisher inventory and preventing internet ad fraud.
Ads.txt stands for Authorized Digital Sellers and is a simple, flexible, and secure way for publishers to publicly declare which companies they allow to sell their digital inventory. Its first version became available on June 27, 2017, and over 1.2M domains show the file.
When publishers implement ads.txt and advertisers require it, they help protect the industry from alleged domain spoofing attacks by fraudsters pretending to be the publisher's domain.
Domain spoofing is a technique used to trick buyers into purchasing masked sites instead of those the seller declares. In this case, an impostor site offers its inventory as if it was the actual site, leading programmatic buyers to purchase it instead of the legitimate inventory.
Ads.txt overcomes this problem by restricting the site to authorized sellers. Many buyers will blocklist publishers who do not implement ads.txt, as they want to make sure they are only purchasing authorized traffic.
As a result, the publisher controls its inventory in the market, ensuring that its impressions are not diluted by millions of spoofed impressions. As a side effect, the programmatic industry is being cleaned up.
The ads.txt mechanism represents a text (.txt) file that companies host on their web servers, listing the companies authorized to sell their ad inventory. As this text file is publicly accessible, programmatic buyers can index and reference it by crawling the web for ads.txt files before purchasing inventory on open markets. Buyers can match the retrieved data against the bid request and make their purchasing decisions accordingly, filtering out unauthorized sellers.
The buyer receiving a bid request claiming to be example.com can check to see if the seller account id and exchange match the listing in example.com/ads.txt.
These are the definitions of the fields in an ads.txt line:
| Field #1 | Domain name of the advertising system | (Required) The canonical domain name of the SSP, Exchange, Header Wrapper, etc system that bidders connect to. This may be the operational domain of the system, if that is different than the parent corporate domain, to facilitate WHOIS and reverse IP lookups to establish clear ownership of the delegate system. Ideally the SSP or Exchange publishes a document detailing what domain name to use. |
| Field #2 | Publisher’s Account ID | (Required) The identifer associated with the seller or reseller account within the advertising system in feld #1. This must contain the same value used in transactions (i.e. OpenRTB bid requests) in the feld specifed by the SSP/exchange. Typically, in OpenRTB, this is publisher.id. For OpenDirect it is typically the publisher’s organization ID. |
| Field #3 | Type of Account/Relationship | (Required) An enumeration of the type of account. A value of ‘DIRECT’ indicates that the Publisher(content owner) directly controls the account indicated in feld #2 on the system in feld #1. This tends to mean a direct business contract between the Publisher and the advertising system. A value of ‘RESELLER’ indicates that the Publisher has authorized another entity to control the account indicated in feld #2 and resell their ad space via the system in feld #1. Other types may be added in the future. Note that this feld should be treated as case insensitive when interpreting the data. |
| Field #4 | Certifcation Authority ID | (Optional) An ID that uniquely identifes the advertising system within a certifcation authority(this ID maps to the entity listed in feld #1). A current certifcation authority is the Trustworthy Accountability Group (aka TAG), and the TAGID would be included here. |
To improve app inventory transparency, the IAB Tech Lab released an extension to the ads.txt initiative customized for apps, called App-ads.txt, released in 2018. The app version of ads.txt also supports OTT and CTV, allowing publishers to list the vendors authorized to sell their ad inventory. CTV growth is booming; however, the high CPMs attract ad fraud, and complexities of monetization relationships such as "inventory sharing" make it harder for current ads.txt and app-ads.txt specifications to provide enough transparency. So, the IAB Tech Lab has recently been working on enhancing CTV standards that offer improvements.
The IAB publishes the most updated specifications of how to implement ads.txt files. We recommend checking their website before implementing your ads.txt file.
Once the file is set up, you'll add the ads.txt lines from your sellers. The ads.txt file directly impacts your monetization, so you must validate the lines before adding them to your file.
1. Invalid lines are useless. Stick to the exact IAB format. Make sure to use the precise number of spaces and commas.
2. Cross-reference ads.txt and sellers.json to discover the sellers behind the lines. You can use Sellers.guide's "Validate Ads.txt" feature for that.
3. Own your domain. You are the only seller that needs to be listed as DIRECT in your file.
4. Clean up. Remove lines of partners you are no longer working with.
5. Run overall quarterly checks. Make sure there are no loopholes.
If you have any questions or suggestions for more best practices, feel free to contact us.
