Since the advent of ads.txt in 2017, digital advertising on open platforms has become significantly more transparent. This transparency has allowed buyers to be more selective about what they buy, preserve inventory value for publishers by limiting spoofing or unauthorized resale, and reduced the amount of fraud in the ecosystem. In the following years, supporting initiatives sellers.json and SupplyChain Object (SChain) were released to allow buyers to become even more purposeful in how they buy, leading to better outcomes. Collectively known as the Supply Chain Transparency standards, ads.txt, sellers.json, and SChain have become integral standards in the fight against ad fraud.
But, these specifications used alone aren’t perfect.
IAB Tech Lab’s Programmatic Supply Chain working group decided last year that it was time to implement new features into the ads.txt specification to continue increasing transparency. Particularly with the adoption of sellers.json and SChain, more data is now available for buyers to verify their supply chain back to ads.txt. This allows stronger ties between the specifications, a key goal of these proposed enhancements.
Two challenges came to light as the sellers.json specification became more widely adopted. The first was difficulty differentiating between owned-and-operated properties vs represented properties for entities declared as BOTH. The second challenge was the difficulty of verifying an individual seller’s relationship back to the underlying media property domains they are selling.
The latest ads.txt specification updates address both of these challenges with a new ads.txt directive, “OwnerDomain.” OwnerDomain entries should appear once in each ads.txt file and should list the business domain of the owner of the site that is being monetized. The OwnerDomain should also match the seller.domain represented in sellers.json entries, which will help to more clearly show the seller that owns the underlying media property. This allows a tight link between ads.txt files and sellers.json. We recommend that even publishers with a single domain use this new directive (listing the same domain as where their ads.txt file is found).
Once these changes have market adoption, buyers will be able to distinguish, and factor into their buying process, when a seller owns-and-operates or represents the property they are selling on any given domain, app, or channel.
Example ads.txt entry:
OwnerDomain=mediaowner.com
| Bid Request | Publisher’s Authorized Sellers (Ads.txt) | Sellers.json | Validation | Answer |
| DSP receives a bid request for a placement on site.com sold by exchange.com (sid 1234) “site.domain” : “site.com””publisher.id” : “1234“”schain” : { “nodes”: [ { “sid” : “1234“, “asi” : “exchange.com” }]} | site.com/ads.txt OWNERDOMAIN = publisher.com exchange.com, 1234, DIRECT | exchange.com/sellers.json { “seller_id” : “1234“, “name” : “Publisher”, “domain” : “publisher.com“, “seller_type” : “Publisher”} | IF seller.domain = OWNERDOMAIN THEN seller is owner of publisher.com IF seller.domain = MANAGERDOMAIN THEN seller is manager of publisher.com IF seller.domain = MANAGERDOMAIN + GEO THEN seller is manager of publisher.com for GEO IF seller.domain != OWNERDOMAIN or MANAGERDOMAIN THEN seller is reseller of inventory | Seller 1234 is owner of site.com and DIRECT path to inventory |
Another set of challenges with the Supply Chain Transparency Specifications is related to the increasing number of small and mid-sized properties being represented by ad management firms and sales houses. With sellers.json and SChain analysis, it’s difficult for buyers to tell which paths to a given publisher are the most direct, because sales houses and ad management firms are an additional node in the SChain. This means that buyers may perceive the ad management company as an additional intermediary, even though it is the most direct path to that media property.
The latest specification updates propose mitigating this issue with a new directive, “ManagerDomain.” With this update, each ads.txt file, when appropriate, can have one ManagerDomain entry, per country represented (or a single entry for global representation). Managers are expected to exclusively represent a majority of the supply of the underlying publisher for the specified geography. This shows that although the monetization manager is not the publisher themselves, they are the most direct path to buy the publisher’s inventory.
ManagerDomain gives buyers transparency into the most direct paths to buy inventory from a given publisher. Similar to OwnerDomain, the ManagerDomain should match managers seller.domain in seller.json entries to clearly show they are the monetization manager of the underlying media property.
Example ads.txt entries:
ManagerDomain=globalrepresentative.com
ManagerDomain=germanrepresentative.com, DE
| Bid Request | Publisher’s Authorized Sellers (Ads.txt) | Sellers.json | Validation | Answer |
| DSP receives a bid request for a placement on site.com sold by manager.com (sid 5678) through exchange.com (sid 1235) “site.domain” : “site.com””publisher.id” : “1235“”schain” : { “nodes”: [ { “sid” : “5678”, “asi” : “manager.com” }, { “sid” : “1235“, “asi” : “ecxhange.com” }]} | site.com/ads.txt OWNERDOMAIN = publisher.comMANAGERDOMAIN = manager.com manager.com, 5678, DIRECTexchange.com, 1235, RESELLER | manager.com/sellers.json { “seller_id” : “5678”, “name” : “Publisher”, “domain” : “publisher.com”, “seller_type” : “Publisher”} exchange.com/sellers.json { “seller_id” : “1235“, “name” : “Manager”, “domain” : “manager.com“, “seller_type” : “Intermediary”} | IF seller.domain = OWNERDOMAIN THEN seller is owner of publisher.com IF seller.domain = MANAGERDOMAIN THEN seller is manager of publisher.com IF seller.domain = MANAGERDOMAIN + GEO THEN seller is manager of publisher.com for GEO IF seller.domain != OWNERDOMAIN or MANAGERDOMAIN THEN seller is reseller of inventory | Seller 1235 is the monetization Manager of site.com and is the most DIRECT path to inventory. Seller 5678 is the owner of site.com which has a DIRECT relationship with Manager |
Publishers will need to make changes to their ads.txt files to become compliant with these new additions. But in the same way that earlier moves toward transparency have benefited quality publishers, we believe that these additional levels of transparency will benefit publishers who bring strong value to their audience; and will equip buyers with better tools to find the best publishers, and the best buying paths to those publishers.
Providing transparency is only one piece of the puzzle though; once this specification is widely adopted, it is on the buyers to use this transparency to their benefit. To do so, we recommend that buyers require full compliance with these specifications from their downstream partners, to give them a full view of their supply chain and to make better informed buying decisions. While these standards increase transparency, they cannot reduce fraud without buyers using them effectively.
Advertisers, in particular, should question their DSP or buying platforms about how they use ads.txt, sellers.json and SChain to minimize fraud, and maximize their dollars being spent on high-quality apps, CTV channels, and websites.
The ads.txt 1.1 specification is in public comment until 31 May. Please review the ads.txt 1.1 specification and implementation guide. We want feedback from the entire industry on the proposed specifications, as well as your ideas and suggestions for any future enhancements of the Supply Chain Transparency Standards. All thoughts, comments and feedback should be sent to support@dev.iabtechlab.com.
The fight for a cleaner and more transparent ecosystem is never finished, and we need your help to keep pushing forward!
About the Authors
Paul Bannister
Chief Strategy Officer
CafeMedia
Jeremy Grant
Sr. Product Manager
Index Exchange
Jud Spencer
Distinguished Engineer
The Trade Desk