According to the IAB Tech Lab, ads.txt was supposed to be “a simple, flexible, and secure method that publishers and distributors can use to publicly declare the companies they authorize to sell their digital inventory.”
But, in practice, ads.txt has proven difficult for publishers to manage and maintain, leading to outdated and inaccurate entries and misrepresentations of reseller relationships.
The current model for ads.txt isn’t helping the industry understand how publishers are working with sellers and resellers. Instead, to improve transparency into these relationships, we need an ads.txt version 2.0 that uses the JSON notation instead.
Ads.txt introduces unnecessary complexity
When ads.txt was launched in 2017, our industry wasn’t as transparent as it is now. Instead of publishers declaring sellers, ads.txt required them to declare exchanges and seat IDs.
As a result, the ads.txt structure looks like this:
Advertising system, sellerID, relationship
For example, an ads.txt entry for PubMatic might look like this:
pubmatic.com, 123456, reseller
But it is challenging for publishers to understand what the IDs stand for and who they authorize to sell their inventory, which creates confusion.
According to Jounce Media, the average publisher in the top 10K cohort authorized 205 supply paths in early 2020. By late 2022, that average tripled to 622, and it continues to grow.
According to Primis’ Sellers.guide, the average publisher lists 69 sellers in ads.txt, while claiming to work with just 20 sellers. And publishers average about 26 companies in their ads.txt file that claim to be “direct” sellers. This lack of clarity leaves buyers at risk of uncertainty.
Looking to sellers.json
To improve transparency into reseller relationships, we need an ads.txt version 2.0 that uses the JSON notation instead.
In a post-sellers.json world, we can build better ads.txt protocols to improve efficiency and transparency. For example, a seller’s entry could look like this:
{
“seller_name” : “sellerX.com”,
“relationship” : “reseller”,
“paths” : [“google.com”, “openx.com”, “pubmatic.com”, “rubiconproject.com”, “triplelift.com”]
}
The IDs will be mapped by DSPs and ad tech platforms. A DSP will need to look up sellerX.com in the sellers.json files of those platforms, save the ID and know that when they get an ad request from OpenX via seat ID 12345678, it is coming from sellerX.com acting as a reseller.
Publishers would have a window into seeing who really has access to sell their inventory, which will help protect them from hidden sellers and misrepresented relationships.
With this proposed approach, publishers will no longer need to use 622 ads.txt lines to represent 69 sellers. They would only need to maintain an ads.txt file with 69 lines – one for each seller.
And there are other benefits as well. Having 69 lines with sellers’ names attached to them, instead of over 600, will make removing sellers easier for publishers.
Additionally, if a company wants to piggyback on another company’s lines, it will be easier for a publisher to notice and ask SellerX why they are sending ads.txt lines for SellerY.
Today, different exchanges often use different names for the same company. But a new ads.txt model that uses sellers.json’s naming method will eradicate this problem.
A better framework for all
Publishers often don’t have the tools or resources to effectively manage reseller relationships in a complex, highly technical setting. By allowing publishers to name companies instead of exchanges and seat IDs, we pass much of the technical responsibility of managing these relationships to ad tech companies that are more equipped to handle them.
Changing the infrastructure of ads.txt is extremely challenging and will require an industrywide commitment. But a big, one-time investment that results in better efficiency and trust for years may be worth it.
“The Sell Sider” is a column written by the sell side of the digital media community.
Follow Primis and AdExchanger on LinkedIn.
For more articles featuring Rotem Shaul, click here.
