Begin dchain implementation

[patmmccann]

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

[patmmccann]

@khatibda fyi

[patmmccann]

@jsnellbaker @ix-prebid-support @ix-prebid-development @pm-harshad-mane @mike-chowla for viz.

[jsnellbaker]

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).

[patmmccann]

@jsnellbaker I imagined for appnexus and its aliases the object would look like this

"dchain" : {
"ver": "1.0",
"complete" : 0,
"nodes" : [
{
"bsid": "BUYERMEMBERID"
},
{
"asi": "BIDDER_CODE",
"bsid": "GVLID"
}
]
}

[jsnellbaker]

I will check with some folks internally, but I'm pretty sure it's not currently supported.

[patmmccann]

@jsnellbaker I see BUYERMEMBERID on your bid responses. Do you mean that our set up isn't typical?

[jsnellbaker]

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 buyermemberid in the appnexus bid response; which is not a unique thing) to create our own object chain for prebid.js to use.

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 bid.meta field.

As a question about the implementation - if the gvlid is not available (like it is for some of the aliases under the appnexus bidder), should the bsid property still exist with a null or undefined value? Or should it be removed entirely?

[patmmccann]

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.

[patmmccann]

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.

[jsnellbaker]

Based on my understanding/conversations, below is a 'rough' proposal of what the dchain module could operate/look like.
Please share any feedback/concerns/questions about the below. Thanks.

module's logic:

• create a hookFn on addBidResponse(adUnitCode, bid)
• check the bid.meta.dchain field if it exists?
  • if not, add following object:

let dchain = {
  ver: '1.0',
  complete: 0,
  nodes: [{ asi: bid.bidderCode }]
};

bid.meta.dchain = dchain;

• (check cont)
  • if it does, append the below node object to represent 'prebid':

bid.meta.dchain.nodes.push({ asi: bid.bidderCode });

• exit hook

Notes:

• would assume that the bidder would/could still provide their own dchain object...
  • using either the data they have now, or when they (eventually) support the full data-set from their adserver.
• is there any need for publisher controls?
  • possible mirror from schain module, a validation setting for the dchain object? (config mock below)
  • anything else?

pbjs.setConfig({
  "dchain": {
    "validation": "strict"  // strict (default), relaxed, off
    ...
  }
});

[patmmccann]

@jsnellbaker how about the case of appnexus, IX or pubmatic, where there is typically available a bsid for a second node?

[jsnellbaker]

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.