Skip to content
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

Prebid Server: Multiple Root SChain nodes #1091

Closed
bretg opened this issue Oct 28, 2019 · 8 comments
Closed

Prebid Server: Multiple Root SChain nodes #1091

bretg opened this issue Oct 28, 2019 · 8 comments
Labels
Intent to implement An issue describing a plan for a major feature. These are intended for community feedback PBS-Go

Comments

@bretg
Copy link
Contributor

bretg commented Oct 28, 2019

(This is the Prebid Server side of prebid/Prebid.js#3870)

Copying the use case from that issue for context:

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.

In this scenario, Prebid Server is not receiving a single simple schain on source.ext.schain. Rather, it will receive a list of schains that are appropriate for different bidders. Here's the proposed location and format:

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

Prebid Server's job would be to parse this list and pass the correct source.ext.schain to each bidder. It should also remove ext.prebid.schains before sending to the adapter.

If there's already an source.ext.schain and a bidder is named in ext.prebid.schains, the latter would override the former.

@bretg bretg added the Intent to implement An issue describing a plan for a major feature. These are intended for community feedback label Oct 31, 2019
DGarbar added a commit to prebid/prebid-server-java that referenced this issue Dec 2, 2019
```
ext.prebid.schains: [
   { bidders: ["shinyClicks"], schain: { SCHAIN OBJECT }},
   { bidders: ["*"], schain: { SCHAIN OBJECT }}
]
```
 * pass the correct source.ext.schain to each bidder
 * remove ext.prebid.schains before sending to the adapter

 For more information prebid/prebid-server#1091
@bretg
Copy link
Contributor Author

bretg commented Apr 14, 2020

This is done in PBS-Java.

@bretg bretg added the PBS-Go label May 18, 2020
@bjorn-lw
Copy link
Contributor

bjorn-lw commented Jun 1, 2020

I'd like to bump this one. We have cases where this support is needed.

@SyntaxNode
Copy link
Contributor

Noted. We've been focused on privacy policies a lot recently. I understand it's a common ask from the community and have bumped up its priority within Xandr. I added the 'help wanted' tag if someone else is able to get to it first.

@bsardo
Copy link
Collaborator

bsardo commented Jun 22, 2020

I'm picking this up for PBS-Go.

@bsardo
Copy link
Collaborator

bsardo commented Jun 30, 2020

@bretg I spent some time going through the spec and the applicable github issues/PRs and I didn't see anything about how to handle the case where multiple non-wildcard schains are defined for a bidder. PBS-Java appears to ignore all schains for a bidder if multiple are defined for a bidder, leaving source.ext.schain unmodified. Can you confirm that this is the expected behavior?

@bretg
Copy link
Contributor Author

bretg commented Jul 1, 2020

What's the use case here @bsardo ? Seems like a data problem to me, but I'm open to input: should we use the first or use the last. Right now it's considered invalid input and ignored.

@rpanchyk - heads up.

@bretg
Copy link
Contributor Author

bretg commented Jul 6, 2020

I'm told that PBS-Go is going to treat this scenario as invalid and reject the request. Am ok with this. @rpanchyk - let's update PBS-Java to do this too.

@SyntaxNode
Copy link
Contributor

This has been implemented in PBS-Go. It's available in release 0.120.0 and newer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Intent to implement An issue describing a plan for a major feature. These are intended for community feedback PBS-Go
Projects
None yet
Development

No branches or pull requests

4 participants