Difference between revisions of "Ads.txt FAQ"

From IAB TechLab Wiki
Jump to: navigation, search
(Clarified and expanded)
Line 12: Line 12:
 
==='''Real time processing'''===
 
==='''Real time processing'''===
 
''Is ads.txt used in real time bidding?''
 
''Is ads.txt used in real time bidding?''
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. These aggregate files 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.
+
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'''===
 
==='''Security and Anti-Fraud'''===
''Can ads.txt be spoofed?''
+
''Can ads.txt be spoofed?''  
A beautiful feature of ads.txt is that if a fraudster attempts to spoof the ads.txt file by copying the file to a fake website, the seller account IDs still represent the legitimate business account, so the money is still directed to the legitimate business (and the media spend does not go to the fraudster). If the publisher’s website is hacked and ads.txt file is compromised, this is a problem outside of the scope of ads.txt efforts.
+
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'''===
 
==='''Mobile in-app inventory'''===
Line 25: Line 25:
 
==='''Media spend and brand strategy'''===
 
==='''Media spend and brand strategy'''===
 
''How can buyers take action?''
 
''How can buyers take action?''
Crawl, aggregate, and shift media budgets. Already some DSPs and buyers are shifting their strategies to authorized digital seller inventory only. ….
+
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'''===
 
==='''Blanket Inclusion of Resellers'''===
 
''As a publisher, how many advertising systems should I list in my ads.txt file?''
 
''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?''
 
''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.  
+
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.
  
  
Line 57: Line 57:
 
==='''Resources'''===
 
==='''Resources'''===
 
''What additional resources are available?''
 
''What additional resources are available?''
Tech Lab Partner Interaction Guide
+
 
 +
[Ads.txt Partner Interaction|Tech Lab Partner Interaction Guide]
 
Google (link)
 
Google (link)
 
AppNexus (link)
 
AppNexus (link)
 
others?
 
others?

Revision as of 19:33, 1 September 2017

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.

Geography

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? 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.


Aggregation

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.

Future Directions

What remains to be solved for ads.txt? Mobile, syndication, blind inventory, ...

Adoption

Who has adopted ads.txt? List to come


Resources

What additional resources are available?

[Ads.txt Partner Interaction|Tech Lab Partner Interaction Guide] Google (link) AppNexus (link) others?