If you don't find an answer, please click here to post your question.
Note: The detailed Ads.txt specification can be found at https://iabtechlab.com/ads-txt/.
Ads.txt stands for Authorized Digital Sellers and provides a simple and secure way for content owners to publicly declare which companies (advertising systems and resellers) are authorized to sell their digital inventory programmatically, and under which terms. The main purpose of this IAB initiative, first released in June 2017, is to restrict fraudulent activity and increase transparency in the programmatic ecosystem.
In accordance with the OpenRTB protocol, every impression already includes publisher information, including the page URL and Publisher ID. However, there was previously no way for programmatic buyers to validate the data coming in the bid requests and confirm if the impression is coming from a legitimate source, or screen for fake and misrepresented ad inventory that is offered during the real-time bidding process.
Keep in mind:
The ads.txt file should contain one line per authorized seller with the following fields:
|<FIELD #1>, <FIELD #2>, <FIELD #3>, <FIELD #4>|
The following table defines the content within each 4 fields:
|Field #1||Domain name of the advertising system||Required. The canonical domain name of the SSP, Exchange, or other system that bidders connect to. If you are using Pulse, the domain name is ooyala.com.|
|Field #2||Publisher’s Account ID||Required. The identifier associated with the seller or reseller account within the advertising system in field #1. It corresponds to the Publisher ID sent in OpenRTB bid requests to DSPs. If you are using Pulse, this corresponds to the Pulse Account ID.|
|Field #3||Type of Account/ Relationship||
|Field #4||Certification Authority ID||Optional. An ID that uniquely identifies the advertising system within a certification authority (this ID maps to the entity listed in field #1). A current certification authority is the Trustworthy Accountability Group (aka TAG), and the TAGID would be included here.|
The following table defines the supported variables:
|Contact||Contact information||Optional. Human readable contact information for the owner of the file. This may be an email address, phone number, link to a contact form, or other suitable means of communication.|
|Subdomain||Pointer to a subdomain file||Optional. A machine readable subdomain pointer to a subdomain within the root domain, on which an ads.txt can be found. The crawler should fetch and consume the data associated to the subdomain, not the current domain. Only root domains should refer crawlers to subdomains. Subdomains should not refer to other subdomains.|
Example.com publishes ads.txt on their web server listing three exchanges as authorized to sell their inventory, including Example.com’s seller account IDs within each of those exchanges, and multiple contact records.
# Ads.txt file for example.com:
greenadexchange.com, 12345, DIRECT, d75815a79
blueadexchange.com, XF436, DIRECT
silverssp.com, 9675, RESELLER
|ooyala.com, [pulse account ID], DIRECT|
|ooyala.com, [pulse account ID], RESELLER|
Note: To get the Pulse Account ID, go to Pulse, open the Settings menu, and check the Integration Information section of your Account Settings.
Contact Technical Support if you have any questions.