Thought Leadership

Ads.txt and Sellers.json 101

February 24, 2020
By Rubicon Project

Ads.txt and sellers.json are two standards that help marketers make safer, more informed buying decisions and bring greater transparency to programmatic transactions. We sat down with John Clyman, VP of Engineering for Marketplace Quality and Security, to discuss these two standards and the questions they raise.

What are the benefits of ads.txt?


Ads.txt is a great tool for protecting against abuse, and we’ve been strong supporters from the start. It was introduced by the IAB Tech Lab in 2018, and is a simple text file that site publishers can post to indicate who is authorized to sell their inventory, which in turn helps ad buyers avoid illegitimate sellers who misrepresent inventory, resell without permission, or even spoof domains. Ads.txt is widely supported across the industry, and we have almost universal coverage of it on web sites in our exchange. 

How does ads.txt work?


Publishers post a text file on each web site that lists all of the companies that are authorized to sell that site’s programmatic inventory. Platforms like Rubicon Project then consult ads.txt files to confirm that inventory they receive is from an authorized seller or reseller before allowing its sale. Buyers can also do their own check that an exchange they receive bids from is authorized to sell that inventory.

For a concrete example, let’s say a buyer has an opportunity to buy an ad on The buyer (or more typically, its DSP), can reference to confirm that Rubicon Project, and indeed a particular publisher integrated with Rubicon Project, is authorized to sell that inventory — but that some other entity claiming to offer that same inventory is not.

Who is it designed to serve?


Ads.txt is primarily designed for programmatic ad buyers to help them ensure their spend is going to a legitimate inventory supplier for a site. Sellers benefit too because they can keep imposters from siphoning off their revenue.

How can ads.txt be misinterpreted?


Ads.txt is a one-way street: It shows which sellers a site would allow to monetize its inventory. But the reverse isn’t true: It doesn’t tell you which platforms are actually monetizing a given site. The file is totally under the publisher’s control. 

So while ads.txt mitigates the risk of working with bad resellers, there are also occasional sites that use the tool to misrepresent themselves. Sometimes that’s due to a genuine mistake, or just out-of-date information — but sometimes it’s because a site is trying to create an aura of legitimacy even if it doesn’t have relationships with the exchanges it claims. Again, the fact that a particular seller or exchange is listed in an ads.txt file doesn’t mean that seller or exchange actually works with the site. And this isn’t a flaw in the spec; it’s just not the purpose it was designed for. So trying to use it to infer who is monetizing on a site can lead to misinterpretations.

By comparison, how does sellers.json work?


Sellers.json helps provide transparency about the specific business entities involved in selling inventory. It’s really intended to work in conjunction with a second spec for something called Supply Chain Object, or schain in Open RTB lingo. Essentially, these two specs enable a buyer to determine everybody that has touched an ad request or bid request as it winds through the programmatic ecosystem. You could say it captures the provenance of an ad impression: It’s a bit like determining the path a diamond took on its way to becoming part of a ring you purchase. Perhaps you see it at a retailer, and can learn that retailer got it from a wholesale supplier, who got it from a distributor somewhere in Africa, who sourced it from some mine that you can verify is aboveboard. By inspecting who the various intermediaries are and what they ultimately lead back to, a buyer — whether of a diamond or of ad inventory — can make a more informed decision about the purchase.

How can sellers.json be misinterpreted?


It’s worth emphasizing that sellers.json tells you who an exchange or SSP has relationships with and is paying for inventory, but it doesn’t tell you what specific inventory they’re paying for, how much of it there is, or what the actual fees are. For example, you might find that half of the entries in a platform’s sellers.json are for publishers, and half are for other intermediaries, which can include everything from video tech platforms to app aggregators to publishers using Google’s Open Bidding or the like. But having business relationships split half and half doesn’t mean that the inventory on the exchange is equally split — sellers.json alone doesn’t provide enough information to say. So, while sellers.json provides a crucial degree of transparency, it doesn’t provide real insight into how a company’s business works from the outside. Buyers who have access to bid stream data that includes Supply Chain Object (schain) get more complete visibility into those factors.

What does the adoption of ads.txt and sellers.json reflect about the programmatic industry? 


Rubicon Project and other companies in the industry are continuing to push for more transparency and better ways to communicate about our business relationships. And this push for transparency standards is ongoing. For example, there’s already a version of ads.txt that supports mobile apps called app-ads.txt where we’ve seen tremendous adoption. We expect to see app-ads.txt extended to support Connected TV before too long, and that’s a critical step toward increasing confidence in the inventory available in that growing market.

Looking forward, Rubicon Project will continue to ensure all parties across the programmatic supply chain have the information they need to make informed decisions and be confident that their money’s well spent.

For more info about Rubicon Project’s products and services, reach out to us at

Tags: , , , , , , , , , ,