Ads.txt Frequently Asked Questions and Best Practices
Living document August 2017 Guidance
Note to the reader: This information is compiled based on the Ads.txt specification version 1, and the current common best practices in place in the industry. The intention of this document is to provide additional clarity or examples of implementation strategies. The following information has not yet been standardized and should be evaluated by each implementing party before adhering to these best practices. For readers who would like to participate in the development of the standards for ads.txt - IAB Tech Lab members are invited to join the OpenRTB working group to collaborate on future directions.
Is ads.txt US only?
This anti-fraud solution is globally available and globally impactful.
Real time processing
Is ads.txt used in real time bidding?
The expectation is that buyers, ad tech vendors, or third parties will aggregate ads.txt files. The expected frequency is to crawl the web two to three times a week (minimum every 7 days), and aggregate in a non real time cadence. Bidders may then consult this data before deciding to bid, or (as a post-buy process) the aggregate ads.txt data can be compared to actual RTB media spend, and buyers will reconcile the inventory purchased against the record of authorized digital sellers. This can inform targeting strategies for real time bidding.
Security and Anti-Fraud
Can ads.txt be spoofed?
If a fraudster copies a legitimate publisher's ads.txt file to a fake website and is able to convince an exchange to send out bid requests with a falsified domain, the seller account IDs still represent the legitimate business account. The seller account ID (publisher ID) listed in bid requests is solely under the control of the exchange; it has internal accounting significance. Thus, the fraudster's bid requests will reflect a different ID. Bidders should not bid on an unauthorized source, which they determine by fetching the ads.txt file directly from the publisher's domain. As a result, bidders will avoid the impressions associated with the fraudster's publisher ID. Successfully circumventing this would require the publisher’s DNS or web server to be hacked so that it returns a false ads.txt file. This is a problem outside of the scope of ads.txt efforts and is a matter of standard security practices to prevent unauthorized parties from accessing a server.
Mobile in-app inventory
Does ads.txt work for mobile in-app inventory?
This is a known needed future direction for the ads.txt standard. Please join the OpenRTB working group to help solve this area. In the meantime, some in-app publishers who represent their inventory with a domain are able to host an ads.txt file on the web domain associated with their app.
Media spend and brand strategy
How can buyers take action?
Take advantage of targeting options that may be available in your DSP to only buy authorized sellers. DSPs may automatically only buy authorized sellers. Buyers can also crawl, aggregate, and shift media budgets based on analysis of reporting data from DSPs
Blanket Inclusion of Resellers
As a publisher, how many advertising systems should I list in my ads.txt file? Which vendors should be included in the ads.txt file?
Publishers should only include advertising systems in their ads.txt file of whom there is a known and authorized partnership established for selling or reselling. Publishers should not include unknown, untrusted, or any vendor that they do not have a business relationship with in the ads.txt file that represents the publisher inventory. The intention of the ads.txt file is to list advertising systems where payment to the publisher is expected. This may be an indirect relationship; for example, the publisher may work with an intermediary who sources demand through one or more other exchanges. In such a case, the intermediary's accounts on those exchanges should be listed as a reseller in the ads.txt file. The general principle, however, is that a publisher should understand exactly how money from a reseller is flowing back to them. Publishers should not list an entity if they (or one of their direct partners) do not have a relationship with that entity.
As a buyer, can I aggregate the ads.txt files from all the publisher inventory that I buy? As a publisher, how can I help buyers understand comments I include on my ads.txt files?
Ads.txt is specifically designed to allow publishers and other sellers to communicate to buyers of various forms the list of parties allowed to resell their inventory.
There’s ambiguity as to whether third parties can aggregate the published ads.txt content and offer the aggregation to buyers.
It is proposed that the aggregation of ads.txt files be considered, by default, permitted use. In order to support this, an additional field is recommended to contain an opt-out of aggregation. Options:
- On the first line, as a comment, the ads.txt file may include: “#no-aggregate”.
- On the last line, as a comment, the ads.txt file may include: “#no-aggregate”.
- The first line may be updated to be a “flags” line to declare things like no-aggregate and other global preferences.
Which field in bid requests should I use to crawl for ads.txt files?
Use the site.domain field (or the domain from site.page if an exchange does not pass the domain field).
Which field in bid requests contains the seller account ID?
Usually, this is the publisher.id field. It may differ at the direction of the exchange.
What is my canonical domain?
Your canonical domain is whatever you'd like it to be, so long as it is consistent, clearly communicated, and unambiguously identifies your exchange. Often, the domain representing the website of the exchange or its operational ad serving domain is used.
What remains to be solved for ads.txt?
Mobile, syndication, blind inventory, ...
Who has adopted ads.txt?
List to come
What additional resources are available?