Before the mass adoption of the IAB tech standards, domain spoofing had been one of the biggest headaches in the programmatic ecosystem. This common form of ad fraud had occurred when ad networks had been trying to make the inventory they sell more promising for ad buyers and simply substituted a fake URL at a bid time.
Since their implementation, the IAB’s tech tools such as ads.txt, sellers.json, and schain object have managed to decrease the amount of fraud and gained more transparency for the money trail. Let’s look closer at these standards and why there is a need for the next one, buyers.json, to be implemented.
Ads.txt and app-ads.txt: the first steps
Starting in 2017, ads.txt was the first safety standard implemented by IAB to eliminate domain spoofing; its name comes from the abbreviation ‘Authorized Digital Sellers’. App-ads.txt, a similar transparency tool for app publishers, has been introduced a few years later to protect against counterfeit of their inventory.
Both ads.txt and app-ads.txt are files that contain information about a publisher’s authorized sellers. The files have to be hosted in the root folder of the website’s domain or the app developer website. Only then this information becomes public and can be crawled by third-party vendors to authorize transactions.
The structure of the file looks like this:
Each line of the file corresponds to one authorized seller and contains three mandatory fields and one optional. These fields are:
- Ad exchange domain name
- Publisher’s ID in the seller’s advertising system
- Relationship type (direct or reseller relationship with the seller)
- Seller’s ID issued by a certification authority (optional)
As more and more buyers enforce the usage of ads.txt and app-ads.txt, failure to comply with this standard can result in revenue losses for a publisher. Precisely, Google pushed initial adoption by not only giving buyers the option of only buying ads with approved ads.txt files but also defaulting this option in Google’s DSP DV360. Then, other vendors such as Centro’s DSP and Trade Desk began to enforce ads.txt and app-ads.txt.
Sellers.json
While the first links of the supply chain had become visible with ads.txt and app-ads.txt implementation, buyers and intermediaries still had no visibility into the entire programmatic chain of inventory. Ads.txt and app-ads.txt did not provide details about who the sellers are and how many sellers are involved for a given transaction to occur.
Sellers.json was launched by IAB Tech Lab in 2019 and has become this sought-after tool to verify which exchanges and SSPs are authorized to sell a publisher’s inventory. If ads.txt was managed by a publisher, sellers.json would disclose the supply sources of ad inventory on account of ad systems.
Sellers.json is also the publicly accessible file that contains all valid seller information and posted in the root domain of ad exchanges and intermediaries. Basically, it lists all publishers and intermediaries that the current advertising system sends downstream in response to demand requests and also maps this list with their IDs and legal entities. By gaining access to this information, ad inventory buyers and DSPs can check sellers’ information and cross out suspicious vendors from their transactions.
The file itself is structured as follows: it contains the list of sellers that an ad exchange is associated with, the set of identifiers that disclose information about each partner, contact email and address, and the version of the standard.
Information disclosed about each seller partner also includes seller ID, type (publisher, intermediary, both), confidentiality, business name and domain name (for non-confidential sellers).
The OpenRTB SupplyChain object
The SupplyChain object was designed to complement sellers.json and represents the extension of the OpenRTB bid request, which is composed of the set of nodes — specific entities that participate in a programmatic transaction. The schain object is added within the extension of the source object of the bid request and has a few route attributes:
- complete (flag whether the schain contains all nodes of the programmatic transaction)
- version of the supply chain specification
- extension placeholder
- nodes array with the specified list of mandatory and optional fields
The first seller in the transaction flow is supposed to create the schain object and insert its node. From then on, all value extracting participants of the transaction will copy the object with the ‘complete’ attribute set to 1 and append their nodes. If a seller reselling inventory loses schain object, they have to create it and set ‘complete’ equal to 0.
After receiving the schain object, DSPs can check the ads.txt file and match the publisher’s ID with the first node, and then look up all other nodes in the transaction and match this information with the corresponding sellers.json files.
Sellers.json and schain allowed buyers to verify ad exchanges and SSPs, identify direct vs. reseller inventory, track and optimize the entire supply path, and meet their objectives with fewer intermediaries. Similar to ads.txt, these initiatives have gained mass adoption after DSPs began to demand their implementation.
Final thought
Ads.txt and sellers.json are both used for the same purpose; they enable media buyers to authorize the process of selling ad inventory and ensure their transactions are brand-safe and fraud-free. Both mechanisms have gained significant adoption since their release and became ubiquitous in the programmatic world. It is worth mentioning that MGID is fully compliant with the implemented standards and supports the new, upcoming moves towards marketplace transparency and openness, such as the buyers.json initiative.
While the previous standards enabled a better understanding of the supply path, the existing vulnerabilities of the buy side still remain unsolved. From the publisher’s perspective, that means that third parties – importantly undisclosed ones – are allowed to place advertising content and interact with their audiences. Also, by hiding their identity from all participants, malwaretisers can quickly reappear in programmatic auctions by registering through other DSPs after they got blocked on one of them. Buyers.json, in this regard, is expected to illuminate the final piece of the ad supply chain puzzle, prevent this type of advertisers’ misbehavior and gain more visibility into the chain of buyers’ demand requests.
