What is ads.txt?
April 3, 2019 | By Alan Reed
Ads.txt stands for Authorized Digital Sellers.
Ads.txt is a new standard built to fight fraud in the programmatic advertising ecosystem. The initiative is led by the IAB (Interactive Advertising Bureau) a trade group whose members include Google, Facebook, Twitter and over 600 others. The specification was finalized in June 2017.
BREAKING DOWN ads.txt
Publishers put a text file on the root of their domain, e.g. http://www.example.com/ads.txt. This file contains records indicating which companies are authorized to sell ad inventory on that website (example.com in this case).
By publishing a list of Authorized Digital Sellers, publishers increase transparency in the digital ad inventory supply chain. Ads.txt files are publicly available to can be crawled by advertisers, exchanges, and third-parties.
How Does it Work?
Here's an example scenario:
Say an advertiser bought ad space on nytimes.com but was skeptical of the exchange that sold the inventory. The nytimes.com has an ads.txt file so the advertiser can check to see if the dubious exchange is listed as an authorized seller of nytimes inventory.
An ads.txt file contains a list of comma-separated records. There are four fields in an ads.txt file:
<field #1>,<field #2>,<field #3>,<field #4>
- #1: Canonical Domain of Advertising System
- This is the domain name of the company being authorized. Companies include SSPs, Exchanges, Header Wrappers and other systems to which bidders connect. E.g. google.com, openx.com, appnexus.com, pubmatic.com
- #2: Publisher's Account ID
- The unique identifier associated with the publisher within the company listed in the first field. This is the same value used to make OpenRTB bid requests. Publisher IDs for google.com are easily recognizable because they start with 'pub-'.
- #3: Account Relationship
- This field describes the type of relationship between the publisher and the company listed in the first field. The two options are DIRECT and RESELLER. Direct indicates the publisher has an account directly with the adversing system. No third-party or middleman involved. Reseller indicates the publisher has given another company access to the account listed in field #2 in order to resell the publisher's ad space on their behalf.
- #4: Certification Authority ID
- Optional. The ID identifies a company within the certification authority TAG. This field maps one-to-one with the domain in the first field. For example, the Cert ID for Google is f08c47fec0942fa0.
An ads.txt file may also indicate subdomains, points of contact and comments. Read the complete specification for more details.
How to Implement ads.txt with Subdomains?
The adstxt specification details how to implement different lists of authorized sellers on different subdomains. The root domain, defined by the Public Suffix List, must list all subdomains.
To indicate that subdomain.example.co.uk has its own ads.txt, exmaple.co.uk/ads.txt must contain:
Other Fields: Comments, Contacts and Extensions
Ads.txt files may contain points of contact, comments, or extensions. Contacts can be specified as follows:
Anything follow a
# is considered a comment and is ignored.
Extension fields may be added to accommodate unforeseen use cases.
Any field following a semi-colon (
;) is treated as an extension.
Reseller vs Direct: Explained
There are two ways publishers can sell their ad inventory though programmatic bidding systems. First, publishers can create an account directly with an ad exchange, like adsense.com, and sell their inventory directly. Second, publishers can authorize a third-party company to sell their ad inventory. The third-party can then sell the ad inventory to through multiple ad exchanges on the publisher's behalf.
If a publisher works with the ad exchange directly then the publisher should put "DIRECT" in their ads.txt file. If a publisher sells their ad inventory through a third-party, then the publisher should put "RESELLER" in their ads.txt. In the case of reseller accounts, the third-party reseller should provide the publisher with the required ads.txt records.
Right now, DIRECT and RESELLER are the only allowable options for the "relationship" field. Others may be added in the future.
Importance of ads.txt Certificate Authority ID
Right now, the Certificate Authority ID field is not widely used. This may change in the future as TAG becomes more mainstream. You can look up companies by name or TAG ID on tagtoday.net.
For now, the certificate ID remains optional.
Objections to ads.txt
Some Supply-Side Platform (SSPs) have objected due to fears the ads.txt initiative will cut into their bottom line. These objections are mostly from unscrupulous SSPs. Any above-board SSP should not worry about ads.txt negatively impacting their business.
Some exchanges and publishers have worried about the added work required to implement ads.txt. For publishers it is very easy to publish a simple text file to their website.
For exchanges it can be more work. Exchanges need to crawl many ads.txt files. Adstxt.com provides a number ads.txt tools including free aggregate ads.txt records (IAB charges $10,000 / year for the same data).
Other's have been critical about the effectiveness of ads.txt. The ads.txt initiative can only work if publishers decide to adopt the standard.
Publishers: Protect your ads.txt file
Only put records you trust in your ads.txt file. If you have a directly relationship with an ad exchange obviously you need to list them in your ads.txt. If you go through an SSP to sell you inventory the company you work directly with should give you a list of records to add to your ads.txt.
If someone you don't know emails you and tells you to add records to your ads.txt do not do it! Contact your ad exchange or SSP directly to confirm before adding records to your ads.txt file.
WRAP UP: Will ads.txt actually work?
The ads.txt initiative is already working to curb ad fraud. Publisher adoption is growing. Check out our ads.txt adoption statistics. Google has announced that they already enforce ads.txt files when present and may require for all publishers in the future.
Questions, comments, corrections? Let us know.