-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Add support for passing SupplyChain Object to all bidders #3870
Comments
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. |
Hello @mkendall07 , @jsnellbaker , |
I'm not sure at this time, but will keep the ticket open so it can be reviewed more formally. |
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.
|
this seems like a reasonable proposal. @bretg for visibility |
Thank you @mkendall07 for the feedback. |
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. |
Hello @briandamaged , We have started the work, will keep you all posted. |
Hello @briandamaged , I have made some code changes related to schain here, Please note that changes in utils.js and adapterManager.js are only related to schain. Flow:
Let us know your thoughts. |
Hello @mkendall07 , @jsnellbaker , @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? |
Sounds good @bretg , I will add the changes in the same PR |
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? |
@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. |
I agree with @mike-chowla 's suggestion. |
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:
In same prebid configuration, we will need three different schain config to be passed:
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. |
@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. |
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. |
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. |
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:
Where do I have this wrong? |
@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. |
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 In the first two cases, the exchange pays SuperAds, who pays me. I don't control the accounts on the exchanges. |
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)
According to that proposal, the adapters would just call |
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:
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. |
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
|
I liked the 2nd approach and agree with prebid-server adapter changes. |
Update - we've met a couple of times debating how to handle this within Prebid.js. @snapwich is going to prototype a smart |
The approach we settled on in #4334 is that bid adapters will be modified to read schain data from 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?
|
Closing this issue -- basic schain support is live. Per-bidder schain is covered by #4465 |
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.
The text was updated successfully, but these errors were encountered: