Proposal: Add support for passing SupplyChain Object to all bidders

[pm-harshad-mane]

Type of issue

Proposal New Feature

Description

With Supply Chain Object coming as a new standard, Prebid should have a way to allow publishers to pass the first node of the supply chain object as mentioned in the examples on https://github.com/InteractiveAdvertisingBureau/openrtb/blob/master/supplychainobject.md

We can have an option through setConfig API to pass Supply Chain Object which will be passed to all bidders.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[pm-harshad-mane]

Hello @mkendall07 , @jsnellbaker ,
Any thoughts on supporting schain?

[jsnellbaker]

I'm not sure at this time, but will keep the ticket open so it can be reviewed more formally.

[pm-harshad-mane]

Hello @jsnellbaker and @mkendall07 ,

PubMatic wants to support the schain object soon so we are thinking of allowing pubs to set it as follows so that adapters can consume it.

We will make the code changes ready in the next few days.

Let us know your thoughts.

pbjs.setConfig({
                    "schain": {
                        "ver":"1.0",
                        "complete": 1,
                        "nodes": [
                            {
                                "asi":"indirectseller.com",
                                "sid":"00001",
                                "hp":1
                            }
                        ]     
                    }
                });
```code

[mkendall07]

this seems like a reasonable proposal. @bretg for visibility

[pm-harshad-mane]

Thank you @mkendall07 for the feedback.

[briandamaged]

I agree that this proposal seems reasonable. It would be great if this could get officially adopted ASAP so that we can begin updating the adapters accordingly.

[pm-harshad-mane]

Hello @briandamaged ,

We have started the work, will keep you all posted.

[pm-harshad-mane]

Hello @briandamaged ,

I have made some code changes related to schain here,
master...pm-harshad-mane:small_changes

Please note that changes in utils.js and adapterManager.js are only related to schain.

Flow:

• adapter manager will validate the schain object
• if it is valid then only it can be passed on to all bidders
• bidders do not need to validate again

Let us know your thoughts.

[pm-harshad-mane]

Hello @mkendall07 , @jsnellbaker , @bretg
I think we need to support schain parameter from Prebid-server JS adapter so that Prebid-server(Go component) can pass it to server-side adapters to forward to respective servers.
What do you suggest?

[bretg]

Sure, should be easy enough for the prebidServerBidAdapter call getConfig('schain') and add it to the openRTB in source.ext. I don't think any changes would be needed to Prebid Server code at all -- it passes everything through to adapters. So will your change be in this PR or a separate one?

[pm-harshad-mane]

Sounds good @bretg , I will add the changes in the same PR

[mgriego]

Hey all, curious about one thing. I saw that the first round of schain support was merged. I have a concern about bidder instances that might need a different schain object. From what I can see, it looks like schain is currently implemented as a global setting. I can, however, have a couple of different bidders that are set up for different partners. Since each partnership would constitute a different supply chain, each bidder might need a custom schain. Has any thought been given to this yet?

[mike-chowla]

@mgriego I can see two ways to handle this. Either the bidders can just support their own schain config per ad unit or someone does another PR to enhance the schain support to be scoped per bidder and support multiple schain objects.

[pm-harshad-mane]

I agree with @mike-chowla 's suggestion.

[jdelhommeau]

Just to emphasize on @mgriego 's point. Current implementation (prebid global config to set schain) seems quite wrong. That assumes that only one seller is implemented prebid side. If that was the case, we wouldn't have needed to come up with standard like sellers.json. The reason we need sellers.json is that in most cases, publishers will work with many different resellers (most of them implemented through prebid) and each of those resller will have a different schain config to provide downstream.

For example:

• Pub A works with SSP1 and SSP2 directly
• Pub A also works with network 1 and network 2
• Network 1 works with SSP1 and SSP3
• Network 2 works with SSP2 and SSP4
• They are all implemented through prebid

In same prebid configuration, we will need three different schain config to be passed:

• 1 for the pub (this one is actually empty)
• 1 for network 1
• 1 for network 2

This can't be supported with current proposal of having one global prebid config. It needs to be setup at the bidder level (including aliases).

Moreover, current implementation (one global schain for all bidders) would most likely result in bad schain passed to bidders (if a pub tries to implement it despite having multiple sellers in prebid) which would defeat completely the purpose of schain.

[mike-chowla]

@jdelhommeau I agree that the current implementation doesn't cover the use case you are describing and that's probably a valid use case. When we inventoried our publisher use cases, the every bidder needing the same supply chain object was the common one.

No one has any objection to further enhancement of the schain module to support additional use cases. Since the schain object is passed as part of the bid object, a future enhancement to the schain module can support multiple schain objects scoped to specific bidders. Handling this in schain module seems better than attaching the schain object to every ad unit for every bidder.

As for the whether there will be the wrong supply chain object passed with current approach, the publisher has to build schain module and configure for anything to be passed. Publishers who need different schain objects for different bidders will need to wait till an enhancement is made before using schain module.

[jdelhommeau]

Thank you @mike-chowla . It may varies per market, but in France, I don't think any of the top 100 publishers doing prebid would have a single schain node for his setup. They would all work with direct integration and at least 1 intermediary partner (MSQ, Sublime, Gravity, teads, etc.), so would need at least two different schain node.

Agree that the schain module is probably the best place to do that, rather than per adUnit setup (would be redundant).

I understand there was a need for quick support, considering tight timeline around sellers.json / schain, but to me, current implementation design is wrong, in the sense that it considers that schain node are an integration level information, while really it is a seller (bidder) level information. It would support basic use case (single seller implemented) but design seems wrong. And if we go live with this, even if we build (what I believe) proper support later on, it will be harder to move people from (legacy) implementation.

[iantri]

Just wanted to offer support from Centro for the view that SupplyChain should not be global -- we definitely see scenarios like described above by @jdelhommeau.

I do also appreciate the effort made with support for it thus far.

[bretg]

Sorry, I don't have a good context here, so I'm a good naive party who can ask you guys to better document the use cases you're concerned about.

My foggy understanding is that each player should be be adding its own node in the chain. I fail to understand why the publisher would need to create separate schains for each bidder before it's sent to each bidder.

In my head, the flow is like this:

1. pub adds the root node to their schain for their ad server
2. this chain is sent to every bidder
3. when bidderA receives the auction request, it adds its own node to the chain
   3a. bidderA sends a request to a DSP, which sees an schain of two nodes
4. when bidderB receives the auction request, it adds its own node to the chain
   4a. bidderB sends the auction on to an SSP, which adds its own node to the chain
   4b. the SSP sends the request to a DSP, which sees an schain of 3 nodes

Where do I have this wrong?

[markd-fs]

@bretg your flow assumes that each bidder account used for a publisher's stack is owned by the same entity. This is not always the case.

For example, here at Sortable, we partner with publishers to include some of their own direct relationships with exchanges, and some of ours, to fill out their desired prebid configuration (managed by us). So bidder A may include Sortable as an intermediary in the payment flow, but bidder B may not.

So I definitely agree with @jdelhommeau and @iantri that SupplyChain needs to be bidder level, not global.

[iantri]

So let me give a story that perhaps illuminates one of these scenarios.

I'm a publisher. I work with SuperAds, a fictitious monetization platform who provides me prebid.js implementation and access to multiple exchanges. SuperAds does this by configuring prebid.js for me, with multiple bidders (Exchanges A and B), making use of the seller account (publisher ID) for SuperAds on those exchanges. However, I also have a direct relationship with ShinyClicks, an ad exchange with a prebid.js adapter, and SuperAds configures that in prebid.js for me too.

SuperAds has assigned me publisher ID 123 internally.

In this case, the supply chains needing to be sent out in bid requests by prebid.js would be:

Bidder for Exchange A: superads.com, 123
Bidder for Exchange B: superads.com, 123
Bidder for ShinyClicks: (I own the account on ShinyClicks)

In the first two cases, the exchange pays SuperAds, who pays me. I don't control the accounts on the exchanges.
In the third case, ShinyClicks directly pays me, as I control that account.

[bretg]

Helpful - thanks @iantri and @markd-sortable.

So interestingly, this could be another use case for the "protected" setConfig() that we came up with over on #3687 (comment)

pbjs.setBidderConfig({
    "bidders":  ['bidderA','bidderB'],
    "config": {
                    "schain": {
                        "ver":"1.0",
                        "complete": 1,
                        "nodes": [
                            {
                                "asi":"superads.com",
                                "sid":"123",
                                "hp":1
                            }
                        ]     
                    }
     }
});

pbjs.setBidderConfig({
    "bidders":  ['bidderA','bidderB'],
    "config": {
                    "schain": {
                        "ver":"1.0",
                        "complete": 1,
                        "nodes": [
                            {
                                "asi":"ShinyClicks.com",
                                "sid":"456",
                                "hp":1
                            }
                        ]     
                    }
      }
});

According to that proposal, the adapters would just call getConfig("schain") to obtain the schain appropriate for them.

[bretg]

Had an internal conversation that filled in a few more gaps. In the case of superads.com, seems like updating the schain config every time there's a new bidder would be annoying. Perhaps what's needed is a default schain (just what exists now) and an schain override available per-bidder.

Here are some ways to model this that could work for both schain and for first party data:

1. two separate pools of config data -- global config is obtained by adapters via bidrequest.schain, bidder-specific (override) config data is passed to them on the bidrequest.protected.schain. For schain, adapters would need to look in both places.

2. smart schain module -- the schain module writes the global schain data to bidrequest.schain as it does today, but PBJS core calls out to it before sending the bid request to each bidder, giving it a chance to overwrite bidrequest.schain if there's an override for that bidder. i.e. add an optional argument to copySchainObjectInAdunits that takes a biddercode. If provided and if there's some bidder-specific config, then use that instead. (Could also create a first party data module that does something similar.)

3. enhanced getConfig -- add an optional biddercode parameter to getConfig. Every bidder adapter would need to pass their biddercode on every getConfig, which will take care of merging the global and bidder-specific data. Would have to make sure that bidders are passing the correct value, including aliases.

I suspect #2 will be the most popular amongst developers because it simplifies the adapter interface, but I believe #1 is cheaper from a browser cpu-cycle and memory perspective.

[bretg]

I guess we should assume that Prebid Server needs to support multiple schains as well. Which means that we'll need to create an openrtb extension. I would suggest

ext.prebid.schains: [
   { bidders: ["shinyClicks"], schain: { SCHAIN OBJECT }},
   { bidders: ["*"], schain: { SCHAIN OBJECT }}
]

1. Prebid Server bid adapter would be updated to pass these ext.prebid.schains values
2. Prebid Server would be updated to pass the appropriate schain to each bidder on source.ext.schain

[pm-harshad-mane]

I liked the 2nd approach and agree with prebid-server adapter changes.

[bretg]

Update - we've met a couple of times debating how to handle this within Prebid.js. @snapwich is going to prototype a smart getConfig that would be the path forward if it works.

[bretg]

The approach we settled on in #4334 is that bid adapters will be modified to read schain data from getConfig rather than the bidrequest. As part of this change, we will update all bidder adapters that current read schain from the original location.

The work for the setConfig updates will be done as part of #4334

@pm-harshad-mane - are you willing to make the other changes needed?

• schain module should stop writing to the bidrequest object
• schain module to validate schains coming in from setBidderConfig (?)
• update each bid adapter referencing schain to pull from getConfig instead of bidrequest. Or coordinate with others?

[bretg]

Closing this issue -- basic schain support is live. Per-bidder schain is covered by #4465