“The Sell Sider” is a column written for the sell side of the digital media community.
Today’s column is written by John Clyman, vice president of engineering, marketplace quality and security, at Magnite.
It’s time to provide sellers with transparency into the buy side of the industry, just as buyers have rightfully demanded transparency from sellers.
Buyer-driven initiatives such as ads.txt, Supply Chain Object, and sellers.json have had dramatic positive impacts on supply transparency and quality, helping buyers protect themselves and make more informed decisions by enabling them to see the provenance of the inventory they purchase. They help sellers protect themselves too, by making it harder for imposters to siphon off ad spend intended for legitimate sites and apps.
But while buyers have clarity into supply, we’re missing the flip side of these efforts to ensure publishers have that same clarity into the demand that monetizes their inventory. A widely adopted buyers.json standard can be a key part of the solution, as it could protect sellers from bad behavior and enable them to see more clearly into the demand path.
Several companies are collaborating with the IAB Tech Lab to make this idea tangible by developing a buyers.json spec, and all interested parties are needed to support its completion and, ultimately, widespread adoption.
Potential use cases for buyers.json
To better grasp the need for buy-side transparency, put yourself in a seller’s shoes. When you, a web publisher or app developer, run an ad, you’re literally letting third parties – potentially undisclosed ones – place content and run code on your site or app, which could affect your user experience.
In the worst case, you’ve opened up your property to purveyors of malware, scams, automated redirects that catapult your visitors elsewhere and other serious ad-quality violations. Technical countermeasures such as ad quality scanners can help but are not perfect.
Encounter a problem and you may find yourself locked in a frustrating game of whack-a-mole. A malvertiser turns up as a buyer through one DSP, gets shut down for misbehavior, and subsequently pops up on another, and another. And this bad actor is allowed to continue its schemes simply because it can hide its identity. A buyers.json standard could put an end to this by bringing in greater transparency.
There are certainly other benefits to transparency. You may want to know about a buyer’s relationship to affiliated entities. Which brands does an agency represent? Which agencies are contained within a holding company? Compiling this information takes time. With frictionless insight into these relationships, you could make more educated decisions regarding who you want buying your inventory and at what price, and how you can make deals with them to more effectively reach your unique audience. It also follows a basic tenet of good business: Know who you’re working with. Scale and automation do not obviate the value of that principle.
Just as ads.txt and app-ads.txt have helped protect sellers, more comprehensive approaches to buy-side transparency could also help protect buyers themselves from having their creatives stolen and used to propagate malware or scams that can damage their brand, or whose demand is resold without their consent.
What buyer transparency could look like
An effective buyer-transparency solution needs to be machine readable (with human legibility as a bonus), easy to produce and easy to consume.
Machine readability is critical. For an industry that calls itself “programmatic,” far too many people spend time emailing and reformatting spreadsheets.
Easy to produce means that DSPs can easily compile the necessary data and package it for consumption with modest engineering effort.
Easy to consume means that data readers such as SSPs, and other interested parties including publishers and app developers, shouldn’t require a significant engineering effort.
A buyers.json file that’s published on a DSP’s core domain fits the bill. The industry needs to agree on a spec for what goes in the file and where, but JSON (JavaScript Object Notation) is standardized, structured, strictly defined, and readable both by machines and moderately technical humans.
Publishing buyers.json is then just a matter of collating the business entities that are already part of the payment process and the seat IDs associated with them, then formatting the data and depositing it on a web server. Consuming buyers.json is even simpler because you can grab it from any programming language, various command-line tools, or even manually from your web browser.
Alternatives could include a buyer-seat API such as the Ad Management API proposed as part of OpenRTB 3.0, but there’s a major disadvantage to APIs in general: Each publisher and consumer needs to support the API, and each publisher-consumer pair needs to validate the pairwise connection. Publishing a file on a website is far less fiddly.
Overcoming the objections
We can imagine two major objections to buyers.json: Confidentiality and the raw work involved.
Confidentiality was an issue for sellers.json too, and was solved by supporting a confidential flag on entries in the file. If that’s too blunt a solution for buyers.json, let’s examine exactly why and use our collective creativity to find a solution. As for effort, yes, there will be some, but let’s not pretend that the status quo is effortless – there’s already lots of time wasted trying to dig up and communicate this information, all while bad actors continue to wreak havoc.
The need for more transparency on the buy side of the industry is clear. Ultimately, the programmatic industry will be more efficient, fair, and safe when sellers, as well as buyers, have the tools they need to protect their interests. While buyers.json won’t be a panacea, it will be a foundation – and a crucial one that is long overdue.
Follow Magnite (@magnite) and AdExchanger (@adexchanger) on Twitter.
