Ads.txt Files and the Emergence of sellers.json & Supply Chain

In July last year, the Interactive Advertising Bureau (IAB) launched a new initiative as part of its policy to combat ad fraud. Sellers.json is supposed to work in tandem with ads.txt (Ads from Authorized Digital Sellers) and is an extension of this concept. The ads.txt itself is a very simple mechanism; and although at the beginning of its adaptation in 2017 it looked as if it would be effective when it came to curbing illegal practices, after a longer period of use, its shortcomings emerged. It no longer provided enough information to Advertisers, whose needs are constantly evolving.

In order to better understand the need of Sellers.json, let’s first look at ads.txt.

What is ads.txt and how does it work?

The purpose of ads.txt is to make it easier for buyers to purchase advertising through authorized sellers, and also to help in the fight against ad fraud, like domain spoofing etc.

Domain spoofing – a type of ad fraud which consists in stating that an advertisement is displayed on a legitimate domain when in fact it has been displayed on another one that often contains pirated or other inappropriate content.
Publishers place the ads.txt file on the root domain of their sites and provide information on all Programmatic partners (SSP) in this file. This allows Advertisers to distinguish and select vendors.

Publishers place the ads.txt file on the root domain of their sites and provide information on all Programmatic partners (SSP) in this file. This allows Advertisers to distinguish and select vendors.

When Publishers start cooperation with a new SSP or network, they add new lines to their ads.txt files. Sometimes, especially in the case of companies with comprehensive Programmatic monetization solutions, it can be hundreds of lines at a time. The problems start to emerge when Publishers do not delete the lines of platforms that they are no longer cooperating with.

Over the course of several years, the Publishers’ ads.txt files have grown to enormous sizes, often exceeding a thousand lines. Advertisers also do not force Publishers to clean their ads.txt files, whether because of not wanting to narrow down the potentially available inventory or simply due to a lack of knowledge. As a result, we end up with overgrown ads.txt from which it is difficult to read real sellers.

By looking at the file you can find platforms with the label “DIRECT“, meaning Direct Sellers and hundreds of them labelled “RESELLER“. The latter can theoretically sell traffic to other platforms; the problem is that we don’t know which ones. This does not improve the situation and adds another layer of uncertainty to the already overloaded ads.txt files.

Some Publishers even fake their ads.txt, which means they engage in “Direct Inventory Mislabelling” fraud. Ads.txt never discloses which other DSPs these players are reselling that same traffic to. Advertisers want to be confident that they are maximizing the value of their media spends. That’s why they need to understand the supply chain and to be able to distinguish legit intermediaries.

This is where not one, but two new IAB initiatives come into play: Sellers.json, accompanying the Supply Chain Object. But where ads.txt focuses on account ownership sellers.json + s-chain are all about money flow. With their help, Advertisers will be able to trace the path taken by the ad, identify intermediaries and determine whether they are authorized.

Sellers.json is the equivalent of ads.txt but for sellers

Sellers.json is a JSON (JavaScript Object Notation) file hosted in the seller’s domain (e.g. yieldbird.com/sellers.json). Simply put, it is the equivalent of ads.txt but for sellers. It contains a list of Publishers and intermediaries who the seller works with, along with a number of attributes that define the Publisher’s name, domain, etc. One of them is the “seller type” parameter, dividing entries into 3 categories:

PUBLISHER – Publishers, website owners. Final recipients of ad revenues.

INTERMEDIARY – intermediaries representing the Publisher, networks or monetization companies (such as Yieldbird). They participate in the chain, they transfer ad-revenue to Publishers or other intermediaries.

BOTH – entities that can simultaneously have their own inventory and represent other Publishers.

All sellers and intermediaries (including SSP) should have sellers.json files.

Publishers don’t need them (ads.txt is enough). 

What is the Supply Chain Object (schain)?

The Supply Chain Object (schain) – is what sets sellers.json “in motion”. By definition it is an object attached to a bid request. It’s composed of a set of nodes. Each node represents a specific entity/participant involved in the transacting of inventory. Each reseller copies the Supply Chain Object from the previous seller to their request for that inventory and inserts their node into the chain.

When the request finds its way to an Advertiser it has information on all participants and their order. Then the Advertiser can cross-check this information with the sellers.json files of participants and the Publisher’s ads.txt file, giving them confidence that the request has come from the right source via an authorized path. This verification is a key part of the process. In order for both sellers and Publishers to be successful, they must ensure that sellers.json + schain and ads.txt are correct, respectively.

By adapting new standards on both sides, sellers and Advertisers, the ecosystem will increase its transparency. Increasing trust and combating fraud in Programmatic should be in everyone’s interest (aside from shady pirate businesses). More trust, less money allocated to fighting fraud (or recovery from it) should equal more revenue for Publishers.

As for today, more and more buyers are enforcing the IAB quality specifications: sellers.json, Supply Chain Object. This means that they are not buying from / bidding on supply partners who refuse to adapt to the new standards.