PAAPI: add support for protected audience extensions and "direct" buyers (igb)

[dgirardi]

Type of change

• Feature

Description of change

This adds support for the ORTB protected audience extensions:

• when PAAPI is enabled, bid requests' ortb2Imp.ext.igs is populated (similar and in addition to ext.ae)
• bid adapters can reply with buyers (igb) objects in additon to auction configs (config). The fledgeAuctionConfigs response property is migrated to paapi. for example:

    // current response from interpetResponse, returning an auction config
   return {bids: [...], fledgeAuctionConfigs: [{bidId: 'xxx', config: {...}}]}
  
   // equivalent to the above, using `paapi`
   return {bids: [...], paapi: [{bidId: 'xxx', config: {...}}]}
  
   // return a buyer (igb) object instead of a full auction config
   return {bids: [...], paapi: [{bidId: 'xxx', igb: {...}}]}
  

• ortbConverter can now parse responses' ext.igi to generate a paapi array.
• publishers can set up auctions to run igb with:

   pbjs.setConfig({
      paapi: {
         enabled: true,
         componentSeller: {
            auctionConfig: {
                  decisionLogicURL: 'publisher.example'
                  // ...
            }
         }
      }
   })
  

• if paapi.componentSeller.auctionConfig is set, we attempt to collect all IGB objects into a single auction config, which is then treated like any other auction config for the purpose of getPAAPIConfig/setPAAPIConfigForGPT.
• it's possible for IGB objects to be incompatible with each other (same origin, different signals). In this case we split the conflicts into a second (or third, etc) auction config.
• Because IGB objects come from different adapters, and first-party data (ortb2/ortb2Imp) can vary by adapter, auction configs generated from IGB have it set in perBuyerSignals instead of auctionSignals. "Normal" auction configs also have first party data repeated in perBuyerSignals, for consistency.
• Instead of one auction config (minus conflicts), it's possible to generate one for each bidder with

   pbjs.setConfig({
       paapi: {
           enabled: true,
           componentBuyers: {
                separateAuctions: true,
                auctionConfig: {/* ... */}
           }
       }
   })
  

  In this case, auctionSignals is populated with first party data as usual.

Other information

Closes #11131
Closes #11094

[dgirardi]

Summary of PMC feedback:

• componentBuyers config should be renamed to componentSeller
• bidders should get a signal that tells them whether the publisher can set up a component seller (bidRequest.paapi.componentSeller ?)

[rdgordon-index]

when PAAPI is enabled, bid requests' ortb2Imp.ext.igi is populated (similar and in addition to ext.ae)

Shouldn't this be BidRequest.imp.ext.igs ?

[dgirardi]

Shouldn't this be BidRequest.imp.ext.igs ?

Yes. It looks like I used the right field in code but not the description.

[pm-harshad-mane]

@jlquaccia please review the PR

[jlquaccia]

Noticed on https://github.com/InteractiveAdvertisingBureau/openrtb/blob/main/extensions/community_extensions/Protected%20Audience%20Support.md, it states that the biddable field is 0 by default (indicating a buyer is not allowed). Also saw in the prebid "fledge" slack channel (about a month back) that the biddable field default may get reversed to 1 instead. Is there an update on the latest around this?

[dgirardi]

AFAIK there's no concrete plan for the spec to change.

[patmmccann]

I found this default in the spec a strange choice as well, however, Prebid can default to a different value than a dsp should interpret a result with a missing value. A dsp should consider biddable null as non-biddable, we'll always pass 1, bc we consider these requests worthwhile. What a dsp should consider biddable null to mean doesn't impact what field we should choose to pass.