**Updated March 2020 **
Since the release of Ads.txt in the Spring of 2017 we have continued to grow our Supply Chain Transparency portfolio. The mission of the collection of standards is simple: Increase transparency in the programmatic advertising ecosystem. The suite of specifications includes:
While each of the above specifications is meant for the specified implementation environment, together they help to allow transparency and validation from publisher listing a placement through to purchasing that placement.
Ads.txt is a simple, flexible, and secure method for publishers and distributors to declare who is authorized to sell their inventory, improving transparency for programmatic buyers.
Ads.txt supports transparent programmatic digital media transactions and can remove the financial incentive from selling counterfeit and misrepresented media. Similar to robots.txt, ads.txt can only be posted to a domain by a publisher’s webmaster, making it valid and authentic. As a text file, ads.txt is easy to update, making it flexible. The data required to populate the file is readily available in the OpenRTB protocol, making it simple to gather and target. And because publishers sell their inventory through a variety of sales channels, ads.txt supports the following types of supplier relationships:
Domain owners who sell on exchanges through their own accounts
Networks and sales houses who programmatically sell on behalf of domain owners
Content syndication partnerships where multiple authorized sellers represent the same inventory
The ads.txt project aims to prevent various types of counterfeit inventory across the ecosystem by improving transparency in the digital programmatic supply chain.
When a brand advertiser buys media programmatically, they rely on the fact that the URLs they purchase were legitimately sold by those publishers. The problem is, there is currently no way for a buyer to confirm who is responsible for selling those impressions across exchanges, and there are many different scenarios when the URL passed may not be an accurate representation of what the impression actually is or who is selling it. While every impression already includes publisher information from the OpenRTB protocol, including the page URL and Publisher.ID, there is no record or information confirming who owns each Publisher.ID, nor any way to confirm the validity of the information sent in the RTB bid request, leaving the door open to counterfeit inventory.
Counterfeit inventory – is defined here as a unit of inventory sourced from a domain, app or video that is intentionally mislabeled and offered for sale a different domain, app or video. The motivation to create counterfeit inventory comes in many forms including, to sell invalid traffic (automated non-human, or incentivised/mislead human traffic) by hiding it in real traffic, to attract higher prices by mislabeling inventory as brand inventory, to bypass content or domain blacklists, or to capture advertising spend restricted to whitelisted domains, among others.
Note that this form of “inventory fraud” in advertising is independent of how the traffic is generated. It can potentially include a mix of for example automated (non-human) bot traffic and real human user traffic. It can also exist as a small amount of authentic and valid inventory mixed with mislabeled inventory.
App-ads.txt is a simple, flexible, and secure method for app publishers and distributors to declare who is authorized to sell their in-app inventory, improving transparency for programmatic buyers. It solves the same problems as ads.txt but in for in-app inventory.
Sellers.json provides a mechanism to enable buyers to discover who the entities are that are either direct sellers of or intermediaries in the selling of digital advertising.
A published and accessible sellers.json file allows the identity of the final seller of a bid request to be discovered (assuming that they are ads.txt authorized). It also allows the identities of all nodes (entities that participated in the bid request) in the SupplyChain object to also be discovered. Currently, it is possible for the final seller to be identified via the Publisher.name and Publisher.domain attributes, but in practice, these properties are inconsistently populated by various selling systems. sellers.json enables smaller bid request object sizes by allowing this information to be looked up and cached “offline” rather than supplied with every bid request. sellers.json also allows the identification of any and all intermediaries that participated in the selling of a bid request.
The SupplyChain object enables buyers to see all parties who are selling or reselling a given bid request. This information can be important to buyers for any number of reasons including transparency of the supply chain, ensuring that all intermediaries are entities that the buyer wants to transact with and that inventory is purchased as directly as possible. The implementation should be as transparent as possible to buyers. It should enable them to easily understand who it is that is participating in the sale of any piece of inventory.
The SupplyChain object is composed primarily of a set of nodes where each node represents a specific entity that participates in the selling of a bid request. The entire chain of nodes from beginning to end would represent all sellers who were paid for an individual bid request.
With the four, above outlined specifications, a buyer may determine if the inventory they are buying is authorized to be sold by the seller or reseller, and indicates how many nodes or participants were engaged in the selling of that bid request. This details what it might look like for a DSP (a traditional buying platform) to use these specifications to buy safely. https://iabtechlab.com/blog/what-it-means-for-a-dsp-to-support-ads-txt/