Everything You Need To Know About Sellers.json

On April 11, 2019, the IAB Tech Lab released two new standards for public review: sellers.json and the OpenRTB SupplyChain object. InMobi has been a key partner in helping to develop these specs, and we are excited for them to be live in this initial instance.

What do these specifications do, and how do they help programmatic advertisers? Keep reading for more information.

What is Sellers.json and How Does It Work?

In short, sellers.json is a file that enables the players of the ecosystem to map back the request to the entities behind that specific opportunity, including the final publisher. Essentially, it’s a file that maintains the mapping between the identifiers and the related entity name along with the relationship type and some additional information.

While ads.txt (To learn more about app-ads.txt, the in-app version of ads.txt, check out this blog post and video) did a great job in publicly disclosing the list of authorized sellers for the demand side to look up, it does not offer any means for the demand-side platform (DSP) to pinpoint the specific publisher behind the ad request (supply side). This is where sellers.json comes in, by allowing the supply-side platform (SSP) to publish such mapping list into its root domain (for example: http://{advertising_system_domain}/sellers.json).

Why is Sellers.json Beneficial?

The goal of sellers.json is to give the buy side (also known as the demand side) and publishers of the advertising ecosystem greater transparency within the larger programmatic and ad tech space. This has long been one of the top concerns around programmatic advertising, and the introduction of sellers.json is a huge step forward in making the programmatic ecosystem much more fair, open, transparent and trustworthy.

This spec mainly aims to combat fraud across the ecosystem. It is also true though that by combating fraud, a brand can have much more confidence on the inventory being bought, so it definitely has an indirect impact into brand safety too. It also gives full transparency into all the intermediaries that participated in the selling of a bid request.

These aren’t the only benefits of sellers.json. It also allows smaller payloads or bid request object sizes, by allowing this information to be directly looked up online as opposed to be supplied with every bid request.

"Sellers.json and SupplyChain object are the natural evolution to help make the ecosystem even more transparent and trustworthy," Sergio Serra, senior product manager, supply and programmatic at InMobi, told The Drum.

What About the OpenRTB SupplyChain Object?

Sellers.json is not the only new spec, as the IAB Tech Lab also released the OpenRTB SupplyChain Object for public comment on the same day. This works in tandem with sellers.json to provide more oversight and transparency on the buy side in the programmatic ecosystem.

Currently, it is possible for the final seller to be identified via the Publisher.name and Publisher.domain attributes in the oRTB request. However, in practice, these properties are wrongly populated or simply omitted by most of the advertising systems. As a result, this also becomes restrictive in the case of resold inventory.

As a consequence, IAB came up with an additional spec - SupplyChain object - which should be included in the BidRequest.Source.ext.schain attribute in OpenRTB 2.5 onwards. For older oRTB versions, the implementer should fall back to BidRequest.ext.schain.

The SupplyChain object is composed primarily of a set of nodes where each node represents a specific entity that participates in the selling of a bid request. Consequently, a complete chain represent all sellers that were paid for an individual bid request. Each node is composed of two required properties:

• The advertising system identifier (ASI), which is the canonical domain name of the SSP, Exchange, Header Wrapper, etc system that bidders connect to.
• The Publisher’s account ID (Pub.Id).

How Is This Different from Ads.txt?

In some ways, both ads.txt and app-ads.txt are in the same arena as sellers.json and the OpenRTB SupplyChain object. They’re all from IAB Tech Lab, and are designed to increase transparency and trust in the programmatic space. However, AdExchanger noted that the new specs complement the existing ones and provide additional information that ads.txt was never designed to highlight.

That said, on the app side at least, adoption is taking its own time and there is a long way ahead. Even though app-ads.txt's benefits are undeniable, there is a lot of education that has to be put in place across the ecosystem.

Realistically speaking, DSPs cannot really drive adoption until critical mass is reached. It is a duty of SSPs and exchanges to evangelize and push for it. The demand side will be able to help by mandating app-ads.txt only after a sufficient share of the developers and app publishers have implemented it.

What Are the Next Steps?

IAB has opened the spec to 30-day public comment period, through May 10, 2019. After that deadline, the community will review the feedback from the ecosystem and evaluate whether any further adjustment to the spec is needed.

Post this, the ecosystem is supposed to adopt it. In order to speed up the adoption, it is crucial we get all the possible help from everybody in the chain; for instance, it’s entirely feasible for TAG to mandate this and possibly replace the existing pchain requirement with the SupplyChain object. Specifically, for their CAF program, they require the adoption of pchain (you can refer to oRTB 2.5). Since pchain spec is only available to TAG members, its adoption never really got into the next level of adoption.

Since SupplyChain object is, from some extent, a natural evolution of pchain (it would be best if TAG moved towards it). This would give an enormous boost to SupplyChain object in particular.

As far as next steps are concerned, here’s what Sergio recommends: "It's crucial that everyone in the space evangelize the importance of supply path transparency in the spirit of fair and more reliable advertising and programmatic trading. InMobi will be an early adopter of both sellers.json and SupplyChain object and we hope the rest of the industry will follow."

Sellers.json Explained: Whiteboard Video

Interested in learning even more about sellers.json? In the whiteboard tutorial video below, Sergio Serra explains in greater detail what sellers.json is and why it's beneficial.

Sellers.json Whiteboard Video Transcript

Hi everybody, this is Sergio Serra. I work in the InMobi product management team, in the supply side of things specifically. And today we’re going to talk about two important innovations that got recently released by IAB. These are sellers.json and SupplyChain Object.

Now these two specs are completing - or trying to complete - a major effort that started two years ago from IAB with ads.txt, which is combatting as much as possible fraud. Now if you really think about ads.txt, what ads.txt was trying to do - and when I’m talking about ads.txt, I want to put it in context with apps, so app-ads.txt, which was released at the beginning of this year, 2019. So when you think about app-ads.txt, what it was trying to solve for was basically bundle spoofing along with detecting any unauthorized resold inventory.

What ads.txt was not really solving for was providing a view from the buyer’s standpoint into the actual ad opportunity. So that’s where these two new specs are coming in place.

Let’s look at the template. So if we start with sellers.json, sellers.json can be actually seen as a counterpart of ads.txt but for the SSPs. Actually, I don’t really want to trivialize this spec as a counterpart of ads.txt because the primary goal is slightly different. So both sellers.json and SupplyChain purely look at the money flow, right? So while ads.txt is more about account ownership in the SSP platform, when it comes to sellers.json and SupplyChain, we purely refer to the money flow. So these two tools are given to the buy side simply to understand where the money is going to.

Now let’s look at the matter. Sellers.json has a couple of fields, the most important ones being on top. So we have the seller type, so seller type here can be three kinds: you can have publisher type, which is direct, and in this case InMobi has an SSP paying direct to the publisher. Then you can have the intermediary type of partnership, in which we are paying someone else on behalf of the publisher, which means that it’s not a direct payment to the publisher. And then you can have a use case in which both publisher and intermediary use cases are possible.

Now the second field is seller ID. Seller ID is the same ID that ideally the SSP should be providing to the publisher in terms of ads.txt, so a DSP should try to look for the same ID when it comes to sellers.json and ads.txt, so pub ID specifically. And this, by the way, is also the same ID that is present in the pub object of the OpenRTB request to the DSPs.Now the other important field is name and domain, where name is simply the name of the seller and domain is, you know, it’s domain.

We also have two additional fields, which are Is_Confidential. For some minor use cases nowadays - it used to be more common in the past, but now it’s slightly less common - so in some cases publishers don’t want to disclose the partnership with the SSP; so in this case the SSP is given flexibility. We’ve decided, as an IAB community, to give flexibility to the publisher - to the SSP actually - not to declare what the publisher behind this seller ID and seller type is. Now, and this is more like Sergio giving an active tip to DSPs, if you are working with an SSP that have couple of occurrences which Is_Confiendetial is one, in which they don’t want to disclose the actual entity, that’s understandable. But, if all of their publisher portfolio is tagged as Is_Confidential, well I would doubt, I would question the health of that business.

Now the last field is Is_Passthrough. This mostly applies to use cases in which the seller is acting as a facilitator, so for instance Google or Amazon TAM.

Now let’s look at the second important innovation, which is the SupplyChain Object. SupplyChain Object is meant to be a part of the OpenRTB request. So just to summarize again, app-ads.txt, if you remember from the previous video, is supposed to be in the publisher root domain, while sellers.json is supposed to be in the SSP’s root domain, so these are two external files that are hosted by these two stakeholders. Now SupplyChain Object is an object that is a part of the OpenRTB request. So the great thing of this object is that it gives final view, again from a buying standpoint, of where your money is going and all the hops that were behind that specific ad opportunity.

So if you look at the scheme of the SupplyChain Object, you will have a couple of important fields. The first one is the ASI, which is practically the domain of the SSP or the seller. Then you have the SID, which is the ID that SSP is giving to that specific seller, and again this has to match with the publisher ID and the seller ID of sellers.json. And then you have the request ID, which is by the way generated by the seller, and then you have two additional fields, which are kind of redundant when you support sellers.json as well.

Reason being that SupplyChain Object and sellers.json should go hand in hand. Meaning that whenever you have this SID in the SupplyChain Object, the DSP can simply look up the SID to the sellers.json file, and this allows also to a lighter payload, meaning the request itself will be lighter because now all the players in the chain don’t have to add name and domain into their node.

So this is the whole object. Now, this specific section can be seen as a node of the object. So, each stakeholder that is taking a cut in the journey of this ad opportunity is supposed to inherit this SupplyChain Object from upstream and to append its own node.

So I think the primary value of this object comes when the SSP doesn’t have a direct integration with the publisher, because in case there is a direct integration while the SSP can just create the SupplyChain Object on its own and the DSP is not given any additional visibility.

But now suppose you have a use case in which InMobi is, for instance, getting the supply from another aggregator, which we can define aggregator 123. So if I’m passing, as InMobi, the ad request, the publisher ID as aggregator 123, basically the DSP doesn’t get to know whether that aggregator is getting the request directly from the publisher or from another aggregator. So as you can understand, this becomes fairly difficult from a demand side to understand where their money is going to.

So that’s a great spec. Again, most of the value comes when it comes to resold supply. I will also say that these two specs together, along with app-ads.txt, puts the whole programmatic advertising in a much better shape.

So of course our message to SSPs is to adopt this as soon as possible. And this is our message to our peers, because again from a demand side I would highly recommend pushing your SSPs towards the adoption of these two specs.

Now when it comes to InMobi, we did roll support to sellers.json as of October 9. This file is fully accessible in our root domain, so inmobi.com/sellers.json. Please go and visit. And then SupplyChain Object is definitely in our roadmap. We are on track to release it by the end of November/the end of the quarter.

That’s it for today. Thanks everybody.