-
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
Begin dchain implementation #7402
Comments
@khatibda fyi |
Hi @patmmccann For the appnexus bidder, what field in the bid response where you looking at that seemed to correlate to this dchain field? I may have missed something, but I'm not sure we're supplying this data at this time (at least for our client-side requests). |
@jsnellbaker I imagined for appnexus and its aliases the object would look like this "dchain" : { |
I will check with some folks internally, but I'm pretty sure it's not currently supported. |
@jsnellbaker I see BUYERMEMBERID on your bid responses. Do you mean that our set up isn't typical? |
Hi @patmmccann I was assuming that for a bidder to 'support' the dchain spec, they would provide an object chain that would have reflected all the back-end buyer parties/steps involved in the process. From here, it sounds like we're taking the surface information of the 2nd last step (using I'm still learning about this whole topic, so I'm sorry for any confusion I caused. If this is the data we want to collect and it doesn't need to extend further (which again was just an assumption on my part), that's fine. I can work on putting together a PR for our bidder to make this type of object in the As a question about the implementation - if the |
That is one part of the spec I am not super clear on. The buyer seat id of the ssp to the publisher doesn't totally make sense to me; I put the gvlid in as a placeholder, but perhaps the value in ads.txt for the ssp in that publisher makes sense, but there are also reasons to not prefer this value. Leaving it null seems fine. I will bring this question to the IAB committee. You're accurate in that no current ssp passes dchains; this proposal is to begin to construct them client side rather than for ssps to construct them server side. The hope is that transition will happen in time and this would get the ball rolling so to speak. |
Summarizing the discussion in committee today: @jsnellbaker had a much better proposal, that a module or some part of core build the dchain whenever they are missing from available information in meta. This appears superior to my proposal above in which select adapters would be modified. |
Based on my understanding/conversations, below is a 'rough' proposal of what the dchain module could operate/look like. module's logic:
Notes:
|
@jsnellbaker how about the case of appnexus, IX or pubmatic, where there is typically available a bsid for a second node? |
In that case - I was thinking they would make their own 'dchain' object in their bidder (if they wished) to provide this information now. They would create the 'shell' and we'd ask they add only the node that contains their unique bsid value. This would ideally be replaced at a later date when they have the full dchain object, since I assume the full object would end with that bsid as the last node before it comes to prebid. The module would then see an 'existing' dchain object, validate it (if that's a feature we want to do), then append the 'prebid' node to the end of the node list. |
Type of issue
Feature Request
Description
Several adapters currently seem to support passing a dspid, eg AppNexus, Index (#3585), Pubmatic (https://github.com/prebid/Prebid.js/pull/3619/files).
On #3115 this was decided to be placed into a particular place in the meta object.
Since that time, a published spec for the dchain object has come to fruition https://iabtechlab.com/buyers-json-demand-chain/.
I propose a pull request, for the three adapters above to start with, that follows this format, on the dchain meta object.
"dchain" : {
"ver": "1.0",
"complete" : 0,
"nodes" : [
{
"bsid": "12345"
},
{
"asi": "sspname",
"bsid": "gvlid_for_ssp"
}
]
}
and for several others that do not pass dsp id in this format
"dchain" : {
"ver": "1.0",
"complete" : 0,
"nodes" : [
{
"asi": "sspname",
"bsid": "gvlid_for_ssp"
}
]
}
My goal is that dchains start to proliferate, publishers start to demand (pun intended) them, and adapter owners extend them, particularly as they begin to publish their own buyers.json files.
Other information
Related issues:
#6923
#6380
#3115
The text was updated successfully, but these errors were encountered: