Header Bidding is often a hybrid auction which takes place on the Client (Prebid.js) and Server (PBS). Since Prebid.js adds new demand to the auction, it's impossible for Prebid Server to know who the true winner is.
Because "the winner" is a key part of analytics, Prebid Server must make other analytics data available in the response as well.
Proposal
Since OpenRTB requires at least one bid in a response.seatbid, and we still want to return this data even if the bidder makes no bids, we will need to put this in response.ext.
For errors, we will add a code to the existing response.ext.errors API.
{
"errors": {
"appnexus": [
{
"code": 1,
"message": "A hybrid Banner/Audio Imp was offered, but Appnexus doesn't support Audio."
}
]
}
}
This is technically a breaking change, because the response today would be:
{
"errors": {
"appnexus": "A hybrid Banner/Audio Imp was offered, but Appnexus doesn't support Audio."
}
}
...but my hunch is that the project is small enough that nobody would mind yet, and it's doubtful that anyone is parsing error strings.
The intent here is that the response.ext.errors.{bidder}.code would use a rigorous, well-defined list of error types, while response.ext.errors.{bidder}.message is a human-readable explanation of what went wrong. Changes to codewould constitute a breaking change to the PBS API, while changes to the message text would not.
Motivation
Header Bidding is often a hybrid auction which takes place on the Client (Prebid.js) and Server (PBS). Since Prebid.js adds new demand to the auction, it's impossible for Prebid Server to know who the true winner is.
Because "the winner" is a key part of analytics, Prebid Server must make other analytics data available in the response as well.
Proposal
Since OpenRTB requires at least one
bid
in aresponse.seatbid
, and we still want to return this data even if the bidder makes no bids, we will need to put this inresponse.ext
.For errors, we will add a code to the existing
response.ext.errors
API.This is technically a breaking change, because the response today would be:
...but my hunch is that the project is small enough that nobody would mind yet, and it's doubtful that anyone is parsing error strings.
The intent here is that the
response.ext.errors.{bidder}.code
would use a rigorous, well-defined list of error types, whileresponse.ext.errors.{bidder}.message
is a human-readable explanation of what went wrong. Changes tocode
would constitute a breaking change to the PBS API, while changes to themessage
text would not.