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

Dchain objects #6380

Closed
patmmccann opened this issue Mar 2, 2021 · 1 comment
Closed

Dchain objects #6380

patmmccann opened this issue Mar 2, 2021 · 1 comment

Comments

@patmmccann
Copy link
Collaborator

patmmccann commented Mar 2, 2021

Type of issue

Standardization request

Description

With the adoption of standard bid.meta fields as per #3115 in Prebid 4.0 and their expected enforcement in #6345 with Prebid 5.0, the spec should naturally extend to where to place the demand chain object bidders receive or are required to create.

The IAB DemandChain working spec indicates "The DemandChain object should be included in the BidResponse.seatbid.bid.ext.dchain attribute in OpenRTB 2.5 or later. For OpenRTB 2.4 or prior, the BidResponse.ext.dchain attribute should be used."

Publishers likely prefer to parse complicated demand chain objects themselves over having SSPs return parsed fields into the various existing meta objects, particularly if they are using analytics or security vendors which are able to parse them.

I propose the preferred way to pass the object back is for it to be copied to bid.meta.dchain, with the ssp adding a node as per the spec. Also as per the spec, if the SSP receives a bid with no dchain, it should initiate one eg "dchain" : { "ver": "1.0", "complete" : 0, "nodes" : [ { "asi": "magnite.com", "bsid": "123456789", } ] } either from its adapter code or in its endpoint response. The prebid server adapter bid response should always include a dchain.

A future validation module will likely have options for size validation, dchain validation, meta.advertiserDomains validation, mime type validation etc.

@ChrisHuie
Copy link
Collaborator

#6383 merge closes this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants