Prebid Server Adapter: participate in fledge auctions

[patmmccann]

Type of issue

Feature Request

Description

The Fledge module takes an auctionConfig that must exist somewhere on the bid response. The PBS bid adapter should have a 'place' for them to be.

https://github.com/prebid/Prebid.js/blob/b04ba3b09b35c5edc4588b569de618d0899ae432/modules/openxOrtbBidAdapter.js#L329 is where they are on the OpenXOrtb adapter response. Open to proposals on where they should be on PBS response, potentially somewhere in meta?

Also pbs adapter should include a unit test it gets imp.ext.ae on fledge auctions just as https://github.com/prebid/Prebid.js/blob/af8fb3816be54406fd69851acc8f6fe0565f9f18/modules/openxOrtbBidAdapter.js#L72

Merging multiple auction configs in one response should be covered in the solution

[dgirardi]

This needs to be implemented server side first. I am not familiar with that codebase but since fledge configs are essentially a "new" type of bid, it's likely to require significant re-tooling.

[patmmccann]

If we decide it exists in the meta response; there might be no server side retooling needed at all. Server just passes through meta unaltered.

[patmmccann]

Correction: it appears to pass through whitelisted fields, eg https://github.com/prebid/prebid-server/issues/2157

[bretg]

There's some overlap here with a new issue I opened -- https://github.com/prebid/prebid-server/issues/2367

For other reasons, I proposed a generic new PBS response extension: ext.seatnonbid. If a bidder doesn't bid but responds with AuctionConfig, that model could be used here too.

{
  seatbid: [{
    seat: "bidderA",
    bid: [{
      ext: {
        fledgeauctionconfig: {...}
      }
    }]
  }],
  ext: {
    prebid: {
      seatnonbid: [{
        seat: "bidderB",
        nonbid: [{
          type: "nobid",
          ext: {
            fledgeauctionconfig: {...}
          }
        }]
      }]
     }
  }
}

PBS could add the ext.seatnonbid whenever a server-side adapter supplies fledge auction config. (Note that the PBS extension standard is all lowercase, no underscores, so we would propose fledgeauctionconfig over fledge_auction_config)

The pbsBidAdapter would then look for seatbid.bid.ext.fledgeauctionconfig and ext.seatnonbid.nonbid.ext.fledgeauctionconfig

[dgirardi]

Fledge configs are independent from bids, so seatnonbid is not a great place for it if it's meant to be populated only when seatbid is not. Counter proposal below

[laurb9]

The fledge auction config is passed out-of-band with respect to the bids (or no bids), it does not contain bid information but rather a specially crafted bid request reflected back to the browser. Since seatbid.nobid is intended for debugging information (non-functional), seatbid.bids is intended to carry actual bids, and even seatbid could be missing entirely if nbr exists, I think it would be simpler to keep passing the fledge auctionconfigs in the response.ext.fledgeauctionconfigs field.

Maybe change the structure from a map of {impid: auctionconfig} to a list [{impid, auctionconfig}] or {impid: [auctionconfig]} to support multiple sellers in the response (seller is passed as a field inside each auctionconfig).

[laurb9]

@dgirardi your proposal looks reasonable, I would go even further and raise the field one level, to ext.fledge, as it is not really a prebid extension.

[dgirardi]

@laurb9, I was thinking about PBS specifically, but it's true that it would work in general. On the naming, how do fledgeauctionconfigs/auctionconfig / compare to fledge/config? How terse is too terse?

For now, updated proposal:

{
  ext: {
     fledge: [
           {
              impid,  // imp.id the fledge auction refers to
              seat,    // bidder code asking for the fledge auction. (not required, but probably useful for analytics)
              config: {
                   // the fledge auction configuration - just a pass-through object. Examples:
                   // https://developer.chrome.com/blog/fledge-api/#ad-auction
                   // https://developers.google.com/publisher-tag/reference#googletag.config.ComponentAuctionConfig_auctionConfig                       
              }
           },
           // ...
     ]
    }
}

[laurb9]

@dgirardi If ext.fledge is used, there should be room left for other things we might want to add in the future under this category. So

• ext.fledge.auctionconfigs[{impid, bidder, config}]

{
  ext: {
    fledge: {
      auctionconfigs: [
        {
          impid: 123,
          configs: [
            {seller: "https://privacysandbox.openx.net", decisionLogicURL, auctionSignals, sellerSignals, interestGroupBuyers[], perBuyerSignals},
            {seller: "https://magnite.com", decisionLogicURL, auctionSignals, sellerSignals, interestGroupBuyers: [], perBuyerSignals}

• ext.fledge.auctionconfigs{impid: configs[]} is the most concise, we lose the bidder which is less useful in the context of sandboxed bid generation, scoring and reporting. As OpenRtb seems to prefer arrays to hashmaps, this can look odd.

{
  ext: {
    fledge: {
      auctionconfigs: {
        "123":  [
          {seller: "https://privacysandbox.openx.net", decisionLogicURL, auctionSignals, sellerSignals, interestGroupBuyers[], perBuyerSignals},
          {seller: "https://magnite.com", decisionLogicURL, auctionSignals, sellerSignals, interestGroupBuyers: [], perBuyerSignals}

An alternative would be to have prebid-server always return seatbid, even with no bids, and pass the auctionconfig responses from each SSP in their own seatbid[].ext.fledgeauctionconfigs without doing any merging. This has the potential to be confusing to consumers of this response, in case the presence of seatbid or one value in it is taken to mean there should be bids in it. I am not sure if there is any advantage in doing this though. I expect the seatbid information to be dropped as the configs are added to slots.

{
  seatbid: [
    {
      seat: "openx",
      bid: [], // or just missing
      ext: {
        fledge: {
          auctionconfigs: {
             "123": {seller: "https://privacysandbox.openx.net", decisionLogicURL, auctionSignals, sellerSignals, interestGroupBuyers[], perBuyerSignals}
          }
        }
      }
    },
    {
      seat: "magnite",
      bid: [], // or just missing
      ext: {
        fledge: {
          auctionconfigs: {
             "123":  {seller: "https://magnite.com", decisionLogicURL, auctionSignals, sellerSignals, interestGroupBuyers: [], perBuyerSignals}

... or the same but with auctionconfigs as lists

[bretg]

I like @laurb9 's first proposal because it would be easy for Prebid Server to collect auctionconfigs from multiple bid adapters without having to merge. I also like getting away from 'seat', which has recently become confusing with the 'multiple biddercode' feature.

{
  ext: {
    fledge: {
      auctionconfigs: [{
          impid: "123",
          bidder: "bidderA",
          configs: [ ... ]
     },{
      auctionconfigs: [{
          impid: "123",
          bidder: "bidderB",
          configs: [ ... ]
     }]
  }
}

I'm concerned that the "false-seatbid" scenario could carry risk of client misinterpretation. Prebid Server's ORTB responses are used by old versions of Prebid.js, mobile SDKs, AMP, and custom upstream servers (e.g. SSAI servers)

[dgirardi]

I'll defend mine, meaning ext.fledge.auctionconfigs[].config as a single object, instead of an array ext.fledge.auctionconfigs[].configs[]. Nested arrays are redundant and server still only needs to collect without merging.

If we do choose the double array, bidder needs to be removed or moved inside the inner array - unless server does some aggregation.

[bretg]

So I think this is what you're arguing for @dgirardi ?

{
  ext: {
    fledge: {
      auctionconfigs: [{
          impid: "123",
          bidder: "bidderA",
          config: { ... }
     },{
          impid: "123",
          bidder: "bidderB",
          config: { ... }
     }]
  }
}

[dgirardi]

Yes, that seems the cleanest to me.

[bretg]

I'm ok with this. @laurb9 ? Has this been discussed in IAB circles?

[laurb9]

I do not know if it has been discussed at IAB, but it looks reasonable. The bidder is the alias, correct ?

[bretg]

The bidder is the alias, correct ?

I used the term "bidder" instead of "seat". It's the entity that's returning the config. Most often that will be the biddercode (e.g. appnexus, pubmatic, rubicon), but nowadays, there are scenarios where someone bids for someone else.

[bretg]

So - is there someone who wants to present this to the IAB ORTB working group, or are we just going to bull ahead and implement in Prebid?

[patmmccann]

I think @SyntaxNode volunteered to float it to them?

[dgirardi]

Related: https://github.com/prebid/prebid-server/issues/2411

[patmmccann]

we should attempt to preserve the alias in the field 'bidder' above

[piwanczak]

+1 to the effort, interested to see this through and implemented