PAAPI module: fill out auctionSignals.prebid.ortb2Imp.banner better

[patmmccann]

Type of issue

Feature request

Expected results

Sizes are available in auctionSignals.prebid.ortb2Imp.banner, and some more fun additions, including ad unit properties from mediaTypes.video on imp.video

Let's fill out whatever we can from the ad unit, including format, w, h, pos,

Let's not restrict these to PAAPI if we can, but we should be able to provide these into the ortb2Imp object in the bidder request, then we get them here for free.

Actual results

Only ext are available

Here is a full auctionSignals.prebid object we're sending

{ "bidfloor": 1.2068775, "bidfloorcur": "USD", "ortb2": { "source": { "tid": "fe994492-7c57-4e25-baec-0cb36b71bf6f", "fd": 0 }, "cur": [ "USD" ], "at": 1, "device": { "w": 1512, "h": 150, "dnt": 1, "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 FLEDGE_GAM_EXTERNAL_TESTER", "language": "en", "deviceType": 2, "js": 1, "sua": { "source": 1, "browsers": [], "mobile": 0 } }, "site": { "domain": "repurposingjunkie.com", "publisher": { "domain": "repurposingjunkie.com" }, "page": "https://repurposingjunkie.com/cricut-heat-press-alternative-htvront-heatpress-review/?commit=ed7225c&at_features={%22fldg%22:true}&pbjs_debug=true", "content": { "language": "en" }, "cat": [ "IAB9-2" ], "pagecat": [ "IAB9-2" ], "privacypolicy": 1, "mobile": 1, "ext": { "data": { "mcmp": [ "BA_WSKW20" ], "site_id": [ "600ad629adec3b6b7b1dc60f" ], "verticals": [ "Crafts" ], "pmp_elig": [ true ], "sens": [ "alc", "ast", "cbd", "cosm", "dat", "gamc", "gamv", "rel", "ssr", "srh", "ske", "wtl" ] } } }, "user": { "data": [ { "name": "adthrive.com", "segment": [ { "id": "126" } ], "ext": { "segtax": 601 } } ] }, "regs": { "ext": { "us_privacy": "1YNY" } } }, "ortb2Imp": { "ext": { "data": { "hvp": "80", "pos": "atf", "adserver": { "name": "gam", "adslot": "/18190176/AdThrive_Sidebar_9/600ad629adec3b6b7b1dc60f" }, "pbadslot": "/18190176/AdThrive_Sidebar_9/600ad629adec3b6b7b1dc60f" }, "ae": 1, "tid": "36d73594-17d1-46cc-b5aa-6bd4b1782a3e", "gpid": "/18190176/AdThrive_Sidebar_9/600ad629adec3b6b7b1dc60f" } }

Other information

extension of #10649

[patmmccann]

@dgirardi i just noticed openx appears to do this a bit #11012

[dgirardi]

I recently learned that PAAPI auctions target a single size. Since getting size information is the main driver for this, we may want to reconsider: what the paapi bidders need to know is not what sizes are supported, but what size the auction is targeting and will be used for rendering.

Auction configs have a requestedSize field. Currently each adapter is free to fill their component auction's requestedSize with values of their choosing, and they would see them reflected in the sandbox' browserSignals. The top level auction also has a requestedSize field but it has no effect on component auctions.

When GAM runs the top level auction it does not appear to do anything with requestedSize - it doesn't add one to the top level auction nor does it modify any of the component auctions'. Nonetheless, it still has to choose a size for rendering.

If Prebid runs the top-level auction we have the same problem - we need to choose a size outside of the sandbox. It's unclear to me if the chosen size should also be signaled to adapters.

Tentative proposal:

• fledgeForGpt should replicate GAM's size choice algorithm by polling GPT slot configuration, and fill out requestedSize on each component auction accordingly.
• paapi should provide a way to let publishers choose the PAAPI size (it could be as simple as picking the first defined size as done in this PR), and:
  • fill out component auction requestedSize (overriding what adapters set, or rejecting configs that do not match it?)
  • possibly signaling it in adapters' bid requests (does the size affect a DSP's decision to participate in a paapi auction?)

[rdgordon-index]

overriding what adapters set, or rejecting configs that do not match it?

IMO you cannot override component auction's requestedSize -- since this is an indication of what was signalled to DSPs with the ae=1 OpenRTB field.

possibly signaling it in adapters' bid requests
Knowing what the top-level seller will choose re: size has been a long-standing ask (WICG/turtledove#825 and WICG/turtledove#908) -- so we shouldn't create something that can get the size 'wrong' -- but IMO we have to signal this to the bidding adapters so that they can use this in their signalling and determination of the requestedSize -- it cannot just exist client-side.

[dgirardi]

What was signaled to DSPs is a set of supported sizes. Currently they have no way of knowing what the actual size chosen by the client will be. We can try to define a way to signal it, but I don't understand how we can respect what comes back in requestedSize - either they all match what the auction actually targets, or they're using incorrect info.

[rdgordon-index]

What was signaled to DSPs is a set of supported sizes. Currently they have no way of knowing what the actual size chosen by the client will be.

That assumes that the seller isn't already choosing a single size, knowing that PAAPI only runs a single size.

[dgirardi]

That assumes that the seller isn't already choosing a single size, knowing that PAAPI only runs a single size.

Sure, but even then, there's only one correct value for requestedSize - there's no way we can honor it if it doesn't match.

A compromise is to fill component auctions' requestedSize only when it's left blank by the adapter, and recommend that it should be left blank.

[rdgordon-index]

and recommend that it should be left blank.

Given that the component auction's requestedSize indicates what has already taken place in the contextual auction, it should never be left blank -- there's no mechanism for signalling multi-size perBuyerSignals from a given response, and hence there can only be a single size by the time the auctionConfig for a component seller is returned. Leaving it blank would create a situation where it would be mismatched.

and fill out requestedSize on each component auction accordingly.

This would need to be signalled to the bidder adapters, as you've suggested earlier -- and then there won't be any ambiguity through the programmatic chain of OpenRTB requests.

[dgirardi]

requestedSize is optional and 2 out of 2 of the adapters that I could get to work leave it blank. It's meant to be set by the seller, not buyer, and it's not part of the InterestGroupAuctionBuyer extension.

To me this means that it is not supposed to have any influence on the buyer and vice-versa; the "normal" flow appears to be: SSP forwards the request, which includes all sizes, to DSPs; DSPs decide to signal interest in the PAAPI auction, with signals based on it; SSP collects them into an auction config, and has no interest in setting requestedSize on top of that. Unless the SSP decides to manipulate the bid request to choose a size, I don't see the scenario where it makes sense for them to set requestedSize. If they do, fine - they can choose to botch rendering, but it seems sensible to recommend that they stop doing it.

[rdgordon-index]

requestedSize is optional and 2 out of 2 of the adapters that I could get to work leave it blank. It's meant to be set by the seller, not buyer, and it's not part of the InterestGroupAuctionBuyer extension.

Agreed that it's supposed to be set by the seller, not the buyer -- and yes, it's optional, because it wasn't part of the original PAAPI spec.

SSP forwards the request, which includes all sizes, to DSPs

This 'forwarding' isn't always 1:1 with the incoming request from the publisher, as not all DSPs support multi-size.

Unless the SSP decides to manipulate the bid request to choose a size, I don't see the scenario where it makes sense for them to set requestedSize

As per the previous statement, this 'manipulation' part of the DSP integration based on their capabilities -- and, as a result, there's often a need to choose a size, and indicate which size was chosen using requestedSize. This also avoids the DSP having to needlessly return an igbid for a size that will ultimately be skipped for the on-device auction.

If they do, fine - they can choose to botch rendering, but it seems sensible to recommend that they stop doing it.

Based on the above, this isn't purely a rendering problem on-device, it also impacts programmatic chain signalling via OpenRTB in the sequential auction setup -- I think we need a different solution.

[dgirardi]

Proposal:

• Publishers can choose the PAAPI size for an ad unit with

  ...
  ortb2Imp: {
       ext: {
            paapi: {
                 requestedSize: {width, height}
            }
       }
  }
  ...
  

• If ext.paapi.requestedSize is not specified, Prebid replicates GAM's size choice algorithm to fill it out.
• The PAAPI requested size is thus available for adapters to forward downstream. Adapters that use ortbConverter would automatically forward it in imp[].ext.paapi.requestedSize.
• When adapters reply with PAAPI auction configs, if they leave requestedSize undefined, Prebid fills it out.
• Worklets then have access to both browserSignals.requestedSize, as defined by the adapter, falling back to the publisher's choice; and auctionSignals.prebid.ortb2Imp.ext.paapi.requestedSize, the publisher's choice.
• When Prebid manages the top level auction, it also fills out the top-level requestedSize.

We would then recommend publishers to leave requestedSize unspecified on the ad unit if GAM manages their top level auctions; the publisher choice should then match the actual slot size.

[rdgordon-index]

If ext.paapi.requestedSize is not specified, Prebid replicates GAM's size choice algorithm to fill it out.
When adapters reply with PAAPI auction configs, if they leave requestedSize undefined, Prebid fills it out.

So, to clarify, if both are undefined/unspecified, they would both replicate GAM's size choice algorithm? If so, should be fine, since it's just making the implicit decision that adapters need to make server-side if the absence of a signal more explicit.

Also implies that this also should be backwards-compatible with today's presumed behaviour -- since if seller participants are also replicating this algorithm, their requestedSize would match Prebid's decision, and the new logic wouldn't override the value if set.

Makes sense to me.

[dgirardi]

So, to clarify, if both are undefined/unspecified, they would both replicate GAM's size choice algorithm?

Correct.

[patmmccann]

Marking as high priority given increasing attention on calculating the size and the excellent proposal from @dgirardi