Ads.txt, or Authorized Digital Sellers, is an IAB project designed to improve transparency in the advertising ecosystem, allowing publishers to declare who is authorized to sell their inventory. Ads.txt is a text file publishers post on their root domain to identify the Authorized Digital Sellers for a participating publisher, allowing brands to have confidence they are buying authentic publisher inventory.
TAG (Trustworthy Accountability Group) requires that a publisher who is integrating with AerServ on a mobile web or desktop site, to monetize on the AerServ Exchange, MUST add AerServ's ads.txt information to their ads.txt file before they are able to go live in the United States.
Table of Contents
1. Basics of Ads.txt
Benefits for Publishers:
Publishers can be certain that only sellers they have authorized are selling their inventory. Some buyers are now requiring the implementation of Ads.txt in order to buy the publisher's inventory, so without it they will lose buyers.
Benefits for Advertisers:
Buyers have confidence they are buying authentic publisher inventory. Reduces fraudulent or resold inventory.
Ads.txt is currently only applicable to mobile web and desktop inventory. The IAB is working on support for in-app inventory, but that has not been released yet.
A publisher must create an ads.txt file listing their authorized sellers and place it in the root domain of their website (i.e. http://www.aerserv.com/ads.txt). Publishers must have the ability to create and update an ads.txt file on their domain listing all of their authorized sellers.
2. Integration Guide
If you don't already have one, create a .txt file and name it ads.txt.
Add an entry in the Ads.txt for AerServ which would be similar to the following information: 'aerserv.com,1234,DIRECT,2ce496b9f80eb9fa’
Contact your Aerserv Account Manager to find the exact entry to add to your ads.txt file.
|IAB Field Name||Description||Example||Required|
|Domain Name of the Advertising System||The domain name of the system to which bidders connect.||aerserv.com||Yes|
|Seller Account ID||AerServ Publisher Account ID||123456||Yes|
|TYPE OF ACCOUNT/RELATIONSHIP||
The type of account, either:
|Certification Authority ID||
An ID that uniquely identifies the system in Field 1 within a certification authority.
|2ce496b9f80eb9fa||Optional, but highly recommended|
Add an entry in your Ads.txt file for each ad network that is authorized to sell or resell your inventory. For each partner, you need the ad serving domain (aerserv.com), the partner ID, and your relationship with the partner (DIRECT or RESELLER).
Post the ads.txt file to the root directory of your domain's server for the appropriate website. The file can be accessible via HTTP or HTTPS but must be located under a standard relative path: "ads.txt". The HTTP request header must contain "Content-Type: text/plain".
Why is the ads.txt file needed?
Many buyers have learned that they are buying inventory that is being sold fraudulently, meaning sellers are falsely presenting it as inventory that it is not (i.e. selling it as NY Times inventory but it is really some Fake News Site). The ads.txt method allows buyers to confirm the authenticity of the inventory so they can be confident that what they are buying is genuine. This should increase the price of CPMs for the premium content in the long run.
Publishers have learned that some sellers they have not authorized are selling their inventory or are fraudulently selling their inventory at cheap prices which hurts their brand and their ability to demand higher CPMs. Ads.txt allows them to protect their inventory and demand premium prices for it.
Does ads.txt apply to both banner and video ad buys?
Yes, it can be used for all ad buy types (banner, video, native, etc.) on mobile web and desktop.
Can ads.txt be used for in app buys?
No, since ads.txt resides on the domain of the website, there is no similar location in app. Many apps have a website, but all of them do not so the same solution will not work in app. The IAB is working on a solution for in app.
What values are contained within the ads.txt file?
Ads.txt is a text file with one entry per line for each authorized seller. Each authorized seller entry contains 4 pieces of information: (domain name, publisher account ID, relationship type and TAG certification ID).
Domain Name: the domain name of the authorized seller such as 'aerserv.com'
Publisher Account ID: the internal publisher ID within the authorized seller's system. This is the value that is sent for 'publisher.id' in the RTB bid request. This value is different for every publisher so make sure to contact your Aerserv Account Manager to receive the correct one.
Relationship Type: 'Direct' or 'Reseller' - a value of 'direct' means that the publisher directly controls the account. A value of 'reseller' means that the publisher has authorized another entity to control the account.
TAG Certification ID: ID that is provided when the seller becomes TAG certified.
What does an ads.txt entry look like?
An ads.txt entry for Aerserv would look like the following:
What if the authorized seller has no TAG Certification ID?
The TAG Certification ID field is optional and can be omitted if the seller does not have one.
Where should the ads.txt file be placed?
The file should be placed in the root level of the publisher's domain (i.e. http://www.aerserv.com/ads.txt)
How many sellers should the publisher list in the file?
The publisher should list all sellers authorized to sell their inventory. If a seller is not listed then a buyer may not buy from that seller because they are unable to confirm that the inventory is authentic.
How often should the publisher update their ads.txt file?
The file should be updated whenever an authorized seller of the publisher's inventory is added or removed. No other maintenance of the file is required.
How do buyers use the ads.txt file?
When a buyer receives a programmatic (RTB) ad request for a mobile web or desktop page, then they will compare the 'publisher.id' in the RTB bid request against the entries in the ads.txt file. The buyer knows the seller based on where they are buying it from. If the 'publisher.id' in the RTB bid request matches the entry for the seller in the ads.txt file, then they know they are authorized to sell it and that it is authentic inventory so they can bid on it. If they do not find a match, then the buyer cannot confirm that the inventory is authentic and can decide whether to buy it or not. Some buyers have stated that if they cannot confirm the inventory is authentic then they will not buy it.
What happens if publishers do not add an ads.txt file?
If publishers don’t add the ads.txt file, buyers that have adopted this into their buying process may exclude their inventory and no longer bid on it, resulting in less demand for the publisher.
Will the ads.txt file support be expanded in the future?
Yes, the IAB is researching how to expand support for mobile apps, and it may also be expanded in the future to specify what type of inventory the seller is authorized to sell (i.e. Banner or Video or both, etc.). If a seller is only authorized to sell banner, and they attempt to sell the publisher's inventory as video (i.e. trying to push video into a banner ad slot) then the buyer could detect that the banner inventory is falsely being presented as video inventory and decide if they want to buy it or not.