Google announced that its DSP, DV360, would extend its enforcement of its supply chain object (SCO) policy whereby every node in the chain must be authorized in the originating site or app’s ads.txt/app-ads.txt file. This is a big – and positive – step towards the goal of full supply chain transparency, but it’s important to put SCO in the context of three elements that form a balanced system and there are pitfalls from only looking at parts of the whole.
Recent call-outs of inaccuracies and outdated entries on ads.txt and sellers.json are by no means a “smoking gun” that something nefarious is going on. In most cases, something that doesn’t look right on a single element of the system may simply be noise, not proof of something malicious.
Today, there are actually three legs to the stool – ads.txt, sellers.json, and SCO – that work together to create a triangulated view of the supply chain transparency. The industry needs to recognize this and ensure that any future improvements take this symbiotic relationship into consideration.
Ads.txt/App-Ads.txt Launched the Transparency Revolution
Ads.txt (followed by app-ads.txt a year later) was created to help combat issues with fraud, spoofing and arbitrage found in programmatic desktop (and mobile web) inventory.
After the adoption of ads.txt reached critical mass, allowing us to observe where intermediaries were authorized, we were all able to terminate accounts that were taking advantage of the previous lack of transparency.
But, along with positive advancements, there are issues with ads.txt. The ads.txt file is just a page of text entries. And the definition of direct vs. reseller seems often up to interpretation. For researchers and twitter activists, who often reference ads.txt entries as proof positive of deception, conclusions are often muddied by ongoing issues with ads.txt that were not foreseen when the spec was created. Outdated entries, reseller “spray and pray” entry inclusions, and definitions of “direct” inventory that don’t satisfy all parties are examples of pitfalls in relying only on ads.txt files to validate supply paths.
Sellers.json Provided the First View into How Many Sellers were Participating
Sellers.json arrived in 2020 to bring more transparency to the supply chain.
The sellers.json spec was designed to follow the money. Sellers.json entries must document entities that receive payment – as the supply path moves from inventory source to buyer – payment moves from buyer to inventory source.
Sellers.json also has its own issues including hygiene and general maintenance for accuracy. What’s more, just because an entry exists on sellers.json does not mean that inventory from that seller is available to buyers.
Unlike ads.txt files, of which there are hundreds of thousands spread widely, sellers.json files are only required for intermediaries – a much smaller number. Thus, for anyone without access to SCO/bid stream data there is a tendency to assume if an entry is on the sellers.json file, it must represent live inventory. This is not true. SCO data is also needed.
SCO Enables a Full 360 Degree Approach to Supply Transparency
Whereas sellers.json and ads.txt/app-ads.txt are accessible to anyone with a web browser, without access to the supply chain objects included in bid requests, it’s impossible to gain full transparency into a supply path.
Every supplier, intermediary or buyer that is party to a specific programmatic transaction needs access to SCO reporting that provides full transparency (warts and all) of the path from the inventory source to the buyer or at least, to the relevant party in the path.
While SCO acts as a key to provide the context for ads.txt and sellers.json entries to which it refers, its inclusion in the bidstream means that specialized tools are needed to extract it and fully unlock the ‘transparency equation.’ These tools are important, especially for buyers, in order to see the number of hops a bid request has taken, along with any missteps made along the way.
Whereas ads.txt/app-ads.txt and sellers.json had an immediate impact with these files’ public availability from day one, SCO requires some extensive scaffolding and infrastructure to fully leverage the power it can bring those transacting programmatically. Thus, those companies that have benefited first are those that have built up the necessary reporting and enforcement of these SCO log files pulled from the bidstream.
SCO provides clarity into the supply path from the original inventory source, and when working in conjunction with ads.txt and sellers.json, an exchange or DSP can fairly confidently validate the sellers included in the supply path. Users of SCO get direct inventory, double confirmation of authorized sellers and can more easily spot an incomplete chain.
Ironically, while SCO provides full transparency to all parties in the programmatic transaction, if you’re outside the bid stream, the only tools left to gain insight into supply paths are ads.txt and sellers.json. Moreover, the only reliable way to know if a seller is transacting against certain inventory is through visibility into the bid stream and SCO. While this won’t change, better management of sellers.json and ads.txt files would reduce the incidence of misinterpretation of these files.
Ultimately, stakeholders across the supply ecosystem need to take responsibility to ensure clean and accurate ads.txt and sellers.json files, while passing full supply chain object nodes upstream. Each intermediary and DSP must keep those downstream accountable by rejecting bids that don’t have supply chain objects that meet the IAB Tech Lab specs. Buyers must not only insist that sellers provide these three legs of the transparency tripod, but in order to maximize the value of this triangulated view of the supply chain, they need to leverage the data and reward supply partners who adopt and comply with these critical standards. Only then can the benefits of full transparency be realized, and poor quality supply be more easily identified and pushed out of the marketplace.
