There was a lot of noise over the summer around needing a ‘new and improved’ ads.txt standard. I understand the desire to blame ads.txt for failing to address the complex nature of supply paths. While the Tech Lab is always entertaining new ways to improve ads.txt and the supply chain object, (in fact, we have just closed public comment in a change. You can see what we’re currently debating here) a new, unverified and unverifiable “standard” doesn’t make sense operationally or for the millions of businesses that rely on actual Tech Lab standards adopted by almost every company across the programmatic ecosystem.
The argument makes a lot of claims about what ads.txt is, a good amount of which are factually inaccurate, like saying ads.txt doesn’t have information about the property, that it doesn’t support authorization by country, and that paths can’t be marked as direct. Moreover, to pull a straw man to say some feature isn’t supported in ads.txt, which is meant to be used with sellers.json and the Supply Chain Object, is looking at only a third of the picture, at best.
I’m going to assume ignorance or agent hallucination instead of blatant manipulation here, so let’s break it down by the specific comparison from the chart on adagents.json’s documentation:
Is this seller declared? Yep! Ads.txt allows web and app publishers to state who can sell their inventory.
Which property is covered? The table says no, but (app)ads.txt must start with the site or app listed in the bid request (in site.domain or app.bundleid). To argue that ads.txt doesn’t name the property when ads.txt files are literally hosted on domain.com/ads.txt is Seussical. But just for good measure, it also has a field for OWNERDOMAIN, which…you guessed it, lists the owner of the site or app in question.
Which placement is covered? The global placement id (gpid) is available as an extension in OpenRTB. The reason it didn’t get codified in the official OpenRTB spec is that publishers were very uncomfortable giving that level of detail in the bidstream. Their argument is that it’s their AdTechGod-given right to package their inventory in the way they see fit. The way adagents.json is written actually removes the ability for publishers to package in practice. That said, there has been talk about a new spec that would map all of the ad units on a site or app happening within the Programmatic Supply Chain Working Group that I’m really excited about. I really like the idea of building on top of that in a way that allows content owners to package their inventory more securely.
Can the publisher group inventory into governed buckets? Took me some reading to figure out what this was in reference to, and I’m still confused by the list: programmatic, direct only, publisher managed, and managedby_COMPANY. The first three are absolutely supported, they just live in OpenRTB, not ads.txt. Adding validation based on the kind of auction seems super complex and risky. The only one that actually could be used in future versions of ads.txt is the managedby_COMPANY field, which is essentially proprietary placements (e.g. a video player on a page that’s not operated by the publisher). The conversation has come up a few times, but the industry’s need for scale has outweighed the desire for detail. It’s probably worth cracking this conversation open again, but let’s not pretend this is a new or novel idea. Throwing a new spec that the industry is completely unfamiliar with is not the answer. Sophisticated definitions look good on paper, but practical maintenance is hard both in input and output utility and takes away the flexibility a publisher will need in managing and packaging inventory. Especially in an industry that innovates and moves fast.
Can authorization vary by country or time window? It absolutely can be done by country and site level. Sub-domains allow you to define different seller relationships across a host domain, for example, a sports section within a news publisher. It’s not available at the ad unit level because buyers do not want the complexity of actual authorization at an ad unit level.
Generally for all three of these, a big complaint I have is that a lot of buyers take blunt strategies to nuanced conversations. While I’d love to have attributes that describe inventory in fine-grain detail, we have to balance that with whether buyers will A. want to read those signals and B. change their investment strategies based on that information. When these conversations have come to me in my tenure (and, trust me, they have), the group of, as of last week, a little over 1,000 implementers decided not to go that path. If we’re asking buyers to change their investment strategies to decision on new signals, we need to make sure they’re the right signals. We are more than willing to take another crack at it, though.
All three of these new fields would also add a TON of work to Publishers who have historically only had to worry about adding lines to their ads.txt file. A little history lesson: ads.txt was married to sellers.json to keep the lift for publishers low. That’s why the sellers.json file is more complex, but it also denotes the kinds of relationships each partner in the supply chain has and if those relationships are exclusive (using MANGERDOMAIN), or if there’s some arrangement that gives a party who isn’t the app owner (like a CTV provider) rights to see some piece of the inventory. It can be very confusing for someone just trying to make a business decision, which is why it leaves the complexity in the hands of the adtech partners whose job it is to understand these specifications and write algorithms based on the rules contained in them. TL;DR – If you’re asking to understand which parties are authorized to sell a piece of inventory, sellers.json is how you’d do that. When used together, the existing structure of ads.txt, sellers.json, and Supply Chain Object provides a complete, human and machine-readable picture of the path every media dollar takes.
That said, I agree that we need to do more to illustrate the complicated media rights challenges in CTV. INVENTORYPARTNERDOMAIN was introduced in 2021 to extend these specifications to CTV-specific use cases. I realize that wasn’t enough, and we need to do more. We just need to figure out how as an industry.
Ok…back to the comparison table…
Can the path be described as direct, delegated, or network-mediated? Do you mean MANAGERDOMAIN and INVENTORYPARTNERDOMAIN in ads.txt 1.1? What about DIRECT and RESELLER? Was your agent confused by PUBLISHER, INTERMEDIARY, and BOTH in sellers.json? Seems like the LLM used to develop the adagents.json wasn’t properly grounded in the most recent Tech Lab specs. It’s a super common problem, so it’s totally understandable. In all seriousness, I genuinely understand that it’s confusing, but adding new words to do the same thing isn’t going to help anyone.
This is also why the Supply Chain Object is SUPER important – it gives an audit trail of the path, so even if you don’t know the terminology, you can still see which parties touched the bid request. The existing SupplyChain Object (schain) relies on every node in the chain being identifiable via sellers.json and authorized via ads.txt.
Which brings me to another biggie here; adagents.json doesn’t contemplate a counterparty relationship. When you remove the counterparty requirement, you introduce a huge gap in verification. Without the dual-verification of ads.txt + sellers.json, Demand-Side Platforms (DSPs) lose their most effective tool for blocking unauthorized sellers. Effective supply path optimization depends on triangulating existing IAB Tech Lab frameworks to ensure authenticated, direct, and transparent access to inventory. Instead of creating fragmented solutions, the industry should prioritize hardening current, standardized validation methods.
If you want to do this before the campaign goes live, finding the most direct possible path to a given piece of inventory is very easy for agents; it’s actually WAY easier for agents than for humans. I’ll even write your prompt for you:
“I’m interested in buying media on this site list (upload site list). Using information from ads.txt and sellers.json, find me the most direct possible path and export a list of seller ids (sids) to send to my SSP to create a deal id.”
This does take a little pre-work because you need to crawl websites, but it’ll be an AWFUL lot easier to crawl existing files than it would be to build a new standard from scratch. If you don’t want to crawl, Tech Lab has an API with the most exhaustive information, but there are lots of free services that also have great information.
As we enter an agentic future, it’s worth returning to first principles. Publishers need to authorize who can sell their inventory, and buyers need some way to validate those declarations. Agents can and will be super powerful tools that are able to apply rules that humans may not have had the time or inclination to read and understand. If you ground your Agents in the rules that already exist in ads.txt, sellers.json, using the Supply Chain Object, those Agents will be able to apply more nuanced decisioning, meaning we can move away from the inappropriately blunt strategies we see across the industry today. Adagents.json aims to do one of those three things, but without the other two-thirds, buyers will need to be comfortable buying inventory from parties they can’t see or validate are authorized. That seems… risky.
Recent Jounce research said that 98% of the bid stream enables independent validation of directness. That’s an incredible feat made possible by the hard work of this entire industry over the course of years. I fail to see how starting from scratch is the answer, because *checks notes * …packaging isn’t as well-supported as it could be.
Any time someone comes in hot, saying these are ‘easy’ or pretending that this is in any way a new idea, they devalue the work of an awful lot of very thoughtful people who have spent hundreds of hours in meaningful discussion trying to address them. To date, they have been unsuccessful because when implementers take the time to map specific use cases, edge cases, and actionable data, they are no longer sure the path forward is the right one for the industry. That said, to anyone interested in contributing, rather than just complaining, you are more than welcome to bring a proposal. Door’s open, come on in.
Hillary Slattery
Sr Director, Programmatic, Product Management
IAB Tech Lab