How can Prebid.js and GAM/GPT function together in Fledge?

[JoelPM]

As noted in the WICG Fledge call today, we are trying to understand how Prebid.js will function in Fledge. The biggest unknown is how the publisher's ad server (most often GAM) intends to function in Fledge. In the present world, the final ad selection happens inside of GAM using proxy line items to represent Prebid.js demand. In Fledge, the browser will run the final ad selection process and this necessitates the consolidation of all demand in the Fledge Auction. This is made somewhat easier by the introduction of Component Auctions, which allow each partner to run their own Interest Group auction. However, several challenges remain to be solved regarding the uber auction. Those are:

1. Who owns and configures the uber auction?
2. Inputs are necessary for the uber auction

Who owns and configures the uber auction?

The uber auction code needs to be publisher configurable (to meet their business use cases) while also being a standard that different partners can integrate with. There are compelling arguments for making this code open-source and consortium owned (explored in brief here). Prebid.js has evolved as a solution that allows competitors to work together in a standardized way on the publisher's behalf and this seems like a good model to continue.

Inputs necessary for the uber auction

The uber auction requires several things:

1. AuctionConfig for every component auction.
2. The maximum contextual bid price (and potentially priority).

The need for component auction AuctionConfigs is self explanatory. The maximum contextual bid price is necessary to allow the uber auction to determine if any of the component auctions performed better than the contextual ad selection process.

Needed from GAM/GPT

AuctionConfig

If GPT were to provide a mechanism by which an AuctionConfig object could be retrieved, it could be added as a component auction of the uber auction for the ad slot.

Bid/Price Signal

All the Prebid.js SSPs currently provide a price signal that is used by Prebid.js to determine the contextual winner. Something similar would be needed from GPT in order to determine what the price to beat is for the Fledge auction.

In short, it would be great to work with the GAM team to devise a solution that enables publishers to easily integrate Fledge demand in the future.

cc @jeffkaufman @sbelov @brodrigu @jonasz @fbastello

Further Reading
An overview of our current thinking can be found here. A partial sequence diagram that prompted this issue:

[jeffkaufman]

Hi Joel, I just wanted to quickly reply to let you know that we're thinking about how we could support multi-seller FLEDGE, and we'll get back to you once we have a better idea what that might look like.

[AramZS]

Hi all, I wanted to note my support here. The idea that the uber auction might be reliant on a specific ad server is not a desirable outcome. I agree that the Prebid model here, building on the existing standards they have established and working in the open, is the best way to go. The idea that the web page executing a FLEDGE bid would have more then one demand source has been a pretty clear under-served use case from day one and making sure that use case is well supported is absolutely desirable.

I will additionally note that I agree that Prebid as the collaborator for the open source code is desirable here. While we don't use Prebid.js on The Washington Post or as part of Zeus, we do use their published technical standards and open source schema for communicating with ad tech systems, as we--and most of the folks we work with--assume the Prebid-established technical standards as a baseline default for these types of operations. It would be very useful to have them building a way to manage FLEDGE's interactions, as that would also lead to an easier path towards adoption.

[lukwlodarczyk]

Hi all. Wanted to express my support for a multi-SSP integration enabling a level playing field. In my opinion, it’s important for such integration to be an equal auction of equal participants.

GAM should be able to fit both roles - be in charge of “top-level” auction as well as participate as one of the SSPs in the Component Auctions.

Similarly - other entities - SSP or for example Prebid.org - should be able to take the role of “top-level” auctioneer with GAM as one of the Composite Auction demand providers.

The context for this support

• FLEDGE introduced an on-device auction. Instead of offering impressions to one preferentially treated partner, FLEDGE allows solution comparing literally all bidding partners on a level playing field - similarily to today’s header-bidding solutions
• Current header-bidding solutions are a workaround to allow external demand to compete in Google Ad Manager:
  • Google demand (Google Ads and DV360) are represented directly in GAM and do not compete with outside demand.
  • Google Authorized Buyers (Google Owned & Operated SSP) are also represented directly in GAM and do not compete with outside demand outside of Google’s Ad Exchange.
  • The Google Ad Manager auction audit is not easily available on the browser and happens on Google’s servers.
  • Header bidding demand is transparent and easily auditable in a browser. The logic to select from that demand is governed by an open-source consortium and configured by the publisher. As a result, the header bidding auction is auditable by the publisher and auction participants.
  • Comparison of Google Ad Manager winner with Prebid winner is not always easy. While Prebid’s demand comparison is easy to access in the browser - it’s not trivial to compare with Google’s Ad Exchange demand.
  • The header bidding auction winner is passed into Google Ad Manager so that it can compete in the (opaque) ad server auction.
  • Currently, Google Ad Manager performs the final ad selection, choosing between header bidding demand and Google Ad Exchange demand.
• Google Chrome team designed a space for an independent publisher actor that might be outside the Google Ad stack. Two-level auction. Component auctions, each with demand from a number of competing SSPs and top-level auction that might be managed by a separate mechanism.

According to my findings (based on conversations with publishers, ad tech vendors and my own experience - working on DSP side):

• The industry needs an independent top-level auction handler that will guarantee a level playing field for Advertisers, Demand-side platforms, Supply-side platforms and Publishers. Prebid model as an open-source code is desirable due to its impartiality.
• The industry needs a top-level auction handler independent from a specific ad server. Impartial auctioneer allows publishers and buyers to transact openly and fairly, with assurances that no party is preferred - a statement that can be audited in an open codebase if needed.
• Multi-SSP FLEDGE is mandatory as stated by Chrome Team in the explainer. From day one it is well known that publishers use more than one SSP today. Executing FLEDGE with more than one SSP is and will be essential. This use case is well supported in today’s ad tech state.
• Support from the Prebid community and open Prebid model guarantees higher adoption, better trust and broader support from publishers and ad tech vendors in the origin trials and in further implementation post-OT.

Desired multi-ssp auction landscape from my perspective (preferable during Origin Trails):

• Google Autorized Buyers (SSP) participates in component auctions equally to other SSPs.
• Google will not “push” by artificial technical blocks other SSPs willing to participate in FLEDGE auctions via EBDA (Open bidding).
• Publishers and their vendors will have technical means to compare demand in GAM without the need of using EBDA (Open bidding).
• Google Demand participates equally with other demand partners in the component auctions and there is no way to skip bids directly to the top-level auction.
• Google Ad Manager ad server is not the only possible final decision-maker in the top-level auction.
• Google and the rest of the market participants (publishers,ad-tech, direct buyers) collaborate on an open standard similar to the prebid model (or based on the prebid model) allowing to audit outcomes and logic of component auctions and top-level auction.

[onetag-dev]

Since some time has passed, and in the meantime Prebid.js has released the integration module for FLEDGE (fledgeForGpt), it's not yet clear how the top-level seller (in this case, GPT) compares contextual bids with those derived from IG signals. In cases of FLEDGE eligibility, adapters can return a tuple consisting of contextual bids and FLEDGE Auction Configs inside the interpretResponse function. As also described in this issue, we should expect that the top-level runner can choose the winning bid between the 'classic' contextual auction and the FLEDGE one.

Is this assumption correct? If so, how is the comparison performed? Does GPT compare the bid value of the contextual winner with that of the FLEDGE auction? It would be great to have some documentation references, let us know if it would be more appropriate to raise this request in a new issue, thank you