Introducing a Fledge module

[vincent-grosbois]

Type of issue

Feature request

Description

Hello,

as you may know, Chrome is starting development on its own privacy sandbox for ads, called Fledge (full ref here : https://github.com/WICG/turtledove/blob/main/FLEDGE.md). We'd like your opinion on adding a new prebid module to handle Fledge auctions.

how Fledge works

In a nutshell, this is how it works: Fledge ads are stored in the browser, and any publisher website will be able to execute a Fledge auction, by simply calling navigator.runAdAuction(...) in JS code. The browser will execute the auction purely locally based on the stored data, and will return a display for the winning ad. Reports of who won the auction will also be sent to the relevant parties. On publisher side, the caller of navigator.runAdAuction(...) will also have the ability to inject lots of parameters and logic, such as logic to apply floors. However, note that a call to navigator.runAdAuction(...) is one-shot: it will either fail (can happen when there are no displays to show, or none of the display passed the publisher logic), or suceed. If it succeeds, then the auction is considered won and displayed. This means it's not possible to ask fledge "what would your best fledge bid be?" and either stop the fledge auction or decide to proceed depending on what the fledge bid would be.

Our proposal

In order for Fledge to be widely adopted, we are trying to leverage existing solutions so that publishers can unlock Fledge supply without having to directly implement themselves the calls to Fledge API. Hence, we'd like to use Prebid for this. We propose to add a Fledge module in prebid, that would be execute before renderAdHook. This module, when activated, would :

• get the final highest bid available, let's call it b
• if Fledge is not available on the client (ie browser too old, etc), do as usual
• if Fledge is available on the client, setup a Fledge auction on the client, with properly set-up configuration, and with a floor of value b. If Fledge returns a winner, we display it. Otherwise, we display whoever was the highest bidder

What do you think about this? Do you have any remarks ? Basically, we'd like to do a module similar to what was done here : https://github.com/prebid/Prebid.js/pull/7189/ but that seems was abandonned

thanks!

[brodrigu]

Hi Vincent, @iamnewton was previously working on #7189 as part of his role at Magnite, but has moved on to another company. I have planned to pick is up and get it running in the next couple weeks.

While the work in #7189 was groundwork to do what you have suggested, it was also leveraging a polyfill to run fledge auctions before any browser fully supports Fledge.

I'd be happy to work with you to get this module fully implemented.

[vincent-grosbois]

Hi @brodrigu thanks for the quick answer!

About the polyfill: to be honest I wonder what the other prebid people think about this. From what I saw, the Fledge polyfill isn't up-to-date anymore with current Fledge API (ie now the Fledge API will return a fenced frame, I think that Fledge polyfill returns a "normal" URL to be inserted in a classic iframe), and I also don't think the polyfill will ever switch to "true fledge" if available on the browser. So in that sense, I'm not sure what is the benefit of using this polyfill, rather than always just calling the "real fledge" when it's available.

Othewise I agree with you! I think the work to add this module in Prebid was 90% done in #7189 , the only thing missing I think is that Prebid should probably fill a bit more the fields for the "auctionSignals" argument to Fledge, and also set everything so that the auction run in Fledge is using as floor the highest bid so far - for this last part unfortunately I think it will have to rely on an externaly hosted .js file to provide this logic.

Le mar. 26 oct. 2021 à 22:23, Brad Rodriguez @.***> a écrit :

Hi Vincent, @iamnewton https://github.com/iamnewton was previously working on #7189 https://github.com/prebid/Prebid.js/pull/7189 as part of his role at Magnite, but has moved on to another company. I have planned to pick is up and get it running in the next couple weeks.

While the work in #7189 https://github.com/prebid/Prebid.js/pull/7189 was groundwork to do what you have suggested, it was also leveraging a polyfill to run fledge auctions before any browser fully supports Fledge.

I'd be happy to work with you to get this module fully implemented.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/prebid/Prebid.js/issues/7634#issuecomment-952294983, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTE6JF3B6RHAJMORE4QNTDUI4E4NANCNFSM5GYT3L4A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[brodrigu]

I agree that the polyfill referenced in this PR is not up to date, and we either need to update it, or switch to the google ads polyfill if we want to go that route. We don't have a timeline for an origin trial on "true fledge" so if we want anything to be useable for a test in the short term, polyfills are our only option.

We have identified some advantages for using the polyfill even if Fledge is available (more control and reporting available for the test period) but ultimately it depends on what publishers and buyers want out of a test and I think a prebid module should support a configuration for either.

I plan to refactor with an aim to making the module agnostic to polyfill vs native fledge and aligned with at least the latest API of the Fledge proposal.

[gglas]

Thanks @brodrigu -- do we plan on picking this PR back up ? https://github.com/prebid/Prebid.js/pull/7189/files

[JoelPM]

In light of what GAM has published here, I believe the only thing needed to test Fledge initially is for adapters to invoke the addComponentAuction call in their interpretResponse function if they are interested in participating in Fledge. Down the road, Prebid may choose to do something more complex, but for now this should suffice.

Edit: had wrong link to GAM change initially.

[patmmccann]

this really feels like something adapters should not be doing, we'll end up having enormous code duplication

[patmmccann]

Also, i find this doc a bit alarming, https://github.com/google/ads-privacy/tree/master/proposals/fledge-multiple-seller-testing why is ad manager getting the results of the auction the browser conducts and selecting the highest ad. that seems backwards of what was proposed, in which ad manager & prebid might pass its result to the browser and the browser would choose

[JoelPM]

I'd be in favor of Prebid.js providing a means of registering the AuctionConfig from auction participants. That would be similar to what I proposed here.

Regarding your second comment, technically the browser is still making the choice, though GPT is facilitating the in-browser auction as the top-level seller. I had hoped Prebid.js would have opportunity to be the top-level seller, but GAM has not implemented things this way.

[nllerandi3lift]

Is there a PMC for Prebid/Fledge convos, or are we sticking with this Issue for now?

[patmmccann]

@nllerandi3lift taking this at the top of the js agenda June 8

[JoelPM]

(In preparation for the conversation tomorrow) I'm assuming that each bidder wishing to participate in the Fledge auction for a zone will provide an AuctionConfig object in their bid response (for that zone). Prebid could provide some metadata to enrich that AuctionConfig, things like:

• Overall Prebid.js bid landscape
• Highest bid from Prebid.js
• First party data

This meta-data could be used by bidders' decisionLogic to help evaluate bids, and could also be passed to IG bidders. What information does Prebid.js want to pass (by enriching AuctionConfigs)? Prebid.js could pass the whole OpenRTB data structure that got passed to the contextual request if they wanted to.

Prebid could also provide code to be embedded by each SSP/bidder in their decisionLogic URL. I'm not sure what the benefit is at the moment, but it seems like it could be worthwhile to help standardize ad scoring/selection.

We can obviously start with something very simple, but I expect that we'll need to answer these questions at some point.

[JoelPM]

Summarizing the discussion that we had today at the Prebid.js PMC: we agreed that there is a need to enable bidders to provide an AuctionConfig object for ad slots where they wish to participate in the Fledge auction. Prebid.js core should provide a means of collecting these AuctionConfigs and registering them with GAM via the addComponentAuction GPT call (for now). OpenX (@laurb9 @kenan-gillet @luigi-sayson) will provide a way of triggering a call that always returns an AuctionConfig to ease testing. @dgirardi will review docs and work with OpenX as we develop support for this.

[dgirardi]

Here's my tentative proposal - but keep in mind that my understanding of the feature is likely still very flawed.

I'm going to use "flegde" as a placeholder in names, not sure if that's going to be appropriate in the final revision.

I would:

• update how core handles interpretResponse; in addition to accepting an array of bids, it should also accept an object containing {bids, fledgeConfigs}. Anything received in fledgeConfigs should be sent to a dummy hook meant to be overridden by a fledge module (see this as an example of the pattern).

• introduce a fledge module that would:

  • perform some sniffing to detect if fledge is available, and make the result available as a flag in the bidderRequest object (by hooking into makeBidRequests)
  • expose a public pbjs.runFledgeAuction({auctionId, bids}) that the publisher would call from their bidsBackHandler (in effect replacing the usual setTargetingForGptAsync). I am imagining that to mean "run a fledge auction to compete with these bids - or all bids from auctionId - or all bids from the last auction if neither is specified".

I am not sure what the best way to implement runFledgeAuction would be, especially how to mesh it with contextual bids. Because the "uber-auction" seems to be controllable only by GPT, we can't provide a single decisionLogicUrl to exclude those that bid lower than "vanilla" contextual bids. Options I can think of are:

1. register prebid as a buyer with the winning bid. Not sure if this is even possible.
2. provide the winning bid as a floor through auctionSignals. I think prebid would need to trust each SSP to respect it in their decisionLogic.
3. use only a single, prebid-owned decisionLogicUrl for every seller. This would require at least some standardization of all the signals.

2 and 3 are assuming that we can exclude every bid from the fledge auction (if the winner is contextual), and that we can detect when all bids have been excluded to fall back to the usual setTargetingForGptAsync. It's not clear to me if either is true - can GAM add its own inventory to the auction? How can we tell that there's no winner?

In terms of how prebid should enrich signals sent to fledge, I'd like to see some examples of buyer or seller "worklets" to understand more. I'm guessing that first party data (the ortb2 / ortb2Imp objects) would be a good starting point.

[JoelPM]

Thanks for giving this some thought @dgirardi. In the short term, I think Prebid.js should make it easy for publishers to utilize GAM, while keeping the door open for Prebid.js to play a larger role down the road on non-GAM pubs (is there such a thing?).

If that's the goal, I think the Fledge module would check for the existence of pbjs.addComponentAuction and, if present, invoke it for each of the AuctionConfigs returned by bid adapters from the interpretResponse call. As noted during our conversation today (and in your comment), Pbjs can't really create and run the uber-auction.

I expect that bidders (SSPs) will want to control their own decisionLogic for now. I propose that the Fledge module not worry about adding any winning bid information. Since the SSP is just running scoreAd and not running a second price auction, I don't think knowing the highest contextual bid is even needed. GAM/GPT, as the runner of the uber-auction, will have the full contextual bid landscape and will also make the decision of whether an IG bid exceeds that or not.

The Fledge module should enrich each of the AuctionConfig objects with the OpenRTB structure that was provided when the contextual call was made.

[dgirardi]

I don't think GAM is in general aware of Prebid auctions - that was a really recent feature afaik only available on GAM 360. Do you mean fledge support will be limited to the same? (and if that's the case, I'd still have hoped for some input or at least visibility on how our bids would be compared with fledge, thinking now about things like bidCpmAdjustment / originalCpm for example).

But if we decide that just passing fledge configuration to GPT is enough, I still think that a public API that the publisher can choose to call is the best way to implement it.

[patmmccann]

My understanding is gam will send the winning gam outcome to the browser with the price configured in gam, so in prebid case, the line item cpm that targets that hb_pb (often set to the same value) for regular workflow and the more precise outcome in the case of header bidder manager gam360 users (a tiny minority). They call this the winner of the contextual auction that's equivalent to the current one that occurs in the ad server. They use the word contextual to imply the future state they imagine in which this auctions lacks user identifiers. Turtledove issue 119 covers their mechanism for passing the price in secret, but they shroud their secret price in discussions of hiding predicted viewability from the publisher.

Our long term goal should be to submit bids to fledge in a way that disintermediates gam endpoint calls and even the gpt library, but for now we'll want to play in that fence as the gpt developers have a head start. We certainly won't want to yield that territory to them after the origin trial ends in August.

[dgirardi]

Is that documented anywere? In my ignorance I'd think that hb_pb is just a targeting key for GAM, how does it know that's (sometimes) the price? Nevermind - you meant (I think) that in most cases pubs will have set up their GAM so that the line item CPM matches hb_pb. The issue you mentioned describes a different flow as far as I can tell, translated to prebid it would look like adding fledge support to PUC (with no hard dependency on GAM). Is there a reason that's not an option for us right now - is it just the effort required? We wouldn't need to hide signals (i.e. the auction result) as that's already public within the publisher's page.

[lukwlodarczyk]

Hi @dgirardi, The only documentation regarding GAM support for component auctions we have is this note from GAM. Unfortunately, still we lack clarity on how will Ad Manager "compare" the bids of all sellers with dynamic allocation. To move things forward we need to make some assumptions and iterate with origin trails moving forward.

Here you can find also an issue where you can ask questions directly to the GAM team. I would highly recommend listing there:

• all open questions
• our assumptions
• or potential blockers in developing prebid support for FLEDGE testing with GAM.

I am not sure how it would be helpful but I can also provide some testing scenarios with real advertiser & publisher integrations using FLEDGE API and RTB House prototype bidder. @dgirardi please let me know on Slack if that would be helpful from your perspective.

[JoelPM]

This is an update on the status of Prebid.js Fledge support.

tl;dr: We have simplified the pull request and are confident it works, but have struggled to get a consistently working test page.

The work in #8716 initially covered two use cases: 1) Integration with GPT where GPT runs the Fledge uber auction 2) Prebid.js runs the Fledge uber auction in the case where Prebid.js wins the contextual auction

I asked @kenan-gillet to simplify the PR so that it only addresses the first use case. The second use case was just a proof of concept demonstrating what it would look like if Prebid.js ran the Fledge uber-auction. Since GPT has chosen to run the uber auction, and indeed Prebid.js exists to facilitate integration with GAM/GPT, the first use case is the one that really matters for publishers. This is why @kenan-gillet removed support for use case 2. It simplifies the code and makes it easier to focus on what is important. Kenan will separate the code for use case 2 into a separate module and we can submit a PR for that use case if there's interest, though I personally am opposed to complicating the code base if there isn't large value.

We are working with two DSPs, one of which is RTBHouse (@lukwlodarczyk), who are sending us IG bid signals in their contextual bid responses, which we then combine into an AuctionConfig object and return to our Prebid.js BidAdapter. We attempted to test with our own GAM account, but had trouble getting GPT to trigger the Fledge auction. The GAM team was kind enough to provide a tag that ran the auction, and we had some success with it, but not consistently. Furthermore, I don't think Yield Groups were configured to support the Prebid.js standard (contextual) functionality. We have reached out to them to see if we can get a more consistent result that demonstrates Prebid.js working as intended.

That being said, I am confident the code the team has written works, though we'd prefer to have a consistently working test page to demonstrate it before integrating the PR.

Those who are interested can try hitting this page with the Chrome Beta: https://codinginadtech.com/prebid-live-tests/fledge/gpt.html?pbjs_debug=true