Workflow for adservers

[jdelhommeau]

Hi all,

If I understood correctly, with FLEDGE, there will be a "standard" cookieless auction happening first, including the classical workflow (Adserving, SSPs, header bidding, etc.). Then, post that auction, will happen an on device-auction for FLEDGE demand with on page logic to decide what ad to render between the classical auction and the FLEDGE auction.

In such workflow, I am unsure how some mechanisms will continue working, such as Adserver pacing, which today can work because adserver is the final decision maker. In FLEDGE world, the adserver loose this position to the profit of the browser. I am not sure how adserver will be able to adapt and be able to forecast and pace correctly, since part of the demand will be out of their scope. Maybe I am missing something, but that seems pretty strong issue.

@gangwang-google , I am curious if this is something that you already have given a thought about and if you have an idea how would FLEDGE incorporate in current GAM / ADX workflow. Would GAM runs before FLEDGE auction? How would you enable competition between GAM / ADX demand and FLEDGE demand? How will GAM be able to forecast and pace correctly if not the final decision maker anymore?

[gangwang-google]

Thanks @jdelhommeau for surfacing this important topic. Your description of the workflow matches my understanding of the FLEDGE proposal.

The question of pacing in TurtleDove/FLEDGE has been discussion previously, for example, Issue #25. @michaelkleber ‘s response was

Regarding reporting latency, for pacing and budgeting purposes, check out the discussion on WICG/attribution-reporting-api#39.

Presumably forecasting can also be based on aggregate measurement API.

The timeliness, precision and/or granularity of aggregated measurement API might be a concern for pacing purposes. Much study and prototype effort is needed to assess and to improve the effectiveness of the proposed solution.

Dovekey Auction has an alternative proposal for timely budget enforcement and pacing based on Secure Mutli-Party Computation (MPC), which is in the general direction of Microsoft MaCAW proposal.

As stated in the Mar 3, 2021 blog, Google Ad Manager (GAM) is fully committed to Chrome Sandbox APIs. We are committed to collaborating with partners and browser vendors to incorporate Sandbox API to Google’s ads products.

It seems reasonable that GAM will run a contextual ad auction and submit the contextual ad auction winner to the FLEDGE auction. It also seems plausible that GAM can forecast on behalf of publishers and AdX buyers based on the Chrome reporting API, among other things.

Pacing can be either a buy side functionality implemented by programmatic buyers, or sell side functionality for reservation ads on behalf of publishers. GAM is not directly involved in buy side pacing. Sell side pacing for reservation ads doesn’t seem to be impacted by 3p cookie deprecation much and such impact could be mitigated by the Chrome reporting API.

[jdelhommeau]

Thank you @gangwang-google !

If I understand correctly, you are saying that gam would run a "normal" 3rd party cookiesless auction, including adserver demand as well as programmatic demand coming through ADX.

Gam would then return the auction result (price and creative code?) To the page, then through a client side script run the fledge auction.
How do you enable competition between the initial gam auction and the fledge one since fledge auction doesn't return a price in clear? Would you pass the gam auction result price as a floor into the fledge auction?

The issue I see with pacing (as in sell side reservation pacing) is that gam wouldn't know how much of the inventory he sees would be taken by fledge demand. Couldn't that invalid gam forecasting and pacing?

Thank you for your help, really appreciate and really helps me wrap my head around the workflow logic!

[gangwang-google]

Hi @jdelhommeau,

How do you enable competition between the initial gam auction and the fledge one since fledge auction doesn't return a price in clear? Would you pass the gam auction result price as a floor into the fledge auction?

Let’s ask browser vendors what they have in mind. I don’t see obvious privacy issues with what you suggested. But there might be other options.

gam wouldn't know how much of the inventory he sees would be taken by fledge demand. Couldn't that invalid gam forecasting and pacing?

The percentage of publishers’ inventory sold to all remarketing demands combined has been quite predictable for the purpose of GAM forecasting and sell-side pacing. If the 3p cookie deprecation gives us any challenge for GAM forecasting and sell-side pacing, we are expecting the Chrome measurement API to mitigate, as I replied in my previous post.

[fbastello]

Chiming in with extra context, I think the description of the contextual response is not defined in FLEDGE but in the original turtledove proposal:

The contextual response includes:
i. An ad;
ii. A positive number bid, where larger bid = ad is more likely to show, but whose meaning is otherwise up to the ad network;
iii.An object containing arbitrary "contextual signals" for the local bidding logic.

So my understanding is that strictly speaking, a contextual bid price might not necessarily be available in the Interest-Group/FLEDGE auction as it's primarily this "positive number bid" that is I believe compared at the end of the ranking exercise that takes place once all the I-G bids have been provided.

That said, if this number is "up to the ad network", then I'm wondering too how we can enable competition across several ad networks/SSPs if this "number bid" only makes sense for only one of multiple parties that represents the buyer.
So to me, this enablement is somewhat related to #202 (Multi-SSP support), in one of the links on that issue (https://github.com/JoelPM/prebid-td/blob/main/PrebidFledge.md) @JoelPM describes a possible workflow that include multi-SSPs and the Ad Server.
This "explorative" workflow hasn't been endorsed but it helped me understand better where the ad server could fit.

[jdelhommeau]

Thank you @fbastello and @gangwang-google . I think this part of the github you posted helped me better understand and formulate the issue I am seeing:
https://github.com/JoelPM/prebid-td/blob/main/PrebidFledge.md#chromefledge-becomes-the-final-selection-layer

Today GAM is the final ad selection layer because it contains the publisher's direct demand, is tightly integrated with AdX and doesn't provide a price signal externally. However, in a Fledge world, Chrome will contain interest group demand that isn't accessible via any other means and won't provide a price signal externally. When navigator.runAdAuction returns 'true' it has identified an appropriate ad for rendering based on provided bids and scoring logic. As a result, the browser/Fledge must become the final selection layer.

SSPs are used to participating in a final selection hosted elsewhere but it raises the question of how GAM will adjust to this.

You can replace "GAM" by any Adserver in above quote. So I am wondering about how Adserver (such as GAM, but not only) will adapt to that new workflow.
@michaelkleber , adding you in this discussion since @gangwang-google asked for browser vendors's opinion.
You and I briefly discussed this on FLEDGE meeting on July 7th, and here is what you said at the time:

MK: The model for FLEDGE is that the same party that used to make the final decision is still able to make the final decision. We’ve only changed where the decision happens. Historically, the pub ad server (on a server) would make the decision. Now the pub ad server (in JS on the client) will make the decision. The same person (publisher or someone working for them) is making the decision. So we’re not trying to change the person, but changing where the decision happens.

So my understanding is that Adserver would then move final decision layer into the web, in a js script. But I am still having a hard time fully understanding how that will be done. @gangwang-google do you, or anyone else in Google Ads team has started to think this through?
The way I see it right now is:

• contextual auction (including adserver and SSPs demand) would run as normal (classic header bidding + Adserver workflow).
• The result of the auction would then be returned to the page, as a JS, which would have knowledge of the contextual auction result (creative + price)
• The JS would then initiate a FLEDGE auction, evaluating all the IG demand
• FLEDGE auction would then return an obfuscated result, where the JS would only be able to know "FLEDGE auction has an ad or not"

Where I am not sure is after that last step, when JS has access to the contextual auction result (creative + Price) and the FLEDGE auction result (obfuscated object with just a "ad" / "no ad" info), how is the final decision to render either one of those auction is done? It seems to me the JS is in no position to make the decision, since he can't tell how much is worth the FLEDGE auction. Can the JS pass the contextual auction result (at least price) to the FLEDGE auction, so that FLEDGE can return a "no ad" signal in case FLEDGE auction price is below the contextual auction price? Some other mechanism?

This seems like a fundamental piece for the success of the FLEDGE proposal. If the FLEDGE auction works, but can't be inserted in the existing workflow, I don't see how it could be adopted. Or publishers will have to make a choice between getting only IG demand or only contextual demand.
@gangwang-google or @michaelkleber , if you have any idea about the above, I am very much interested to better understand that crucial part.

[michaelkleber]

Can the JS pass the contextual auction result (at least price) to the FLEDGE auction, so that FLEDGE can return a "no ad" signal in case FLEDGE auction price is below the contextual auction price?

Yes, this is exactly what I had in mind. As in the FLEDGE explainer's section 2.3 Scoring Bids:

The output of scoreAd() is a number indicating how desirable this ad is. Any value that is zero or negative indicates that the ad cannot win the auction. (This could be used, for example, to eliminate any interest-group-targeted ad that would not beat a contextually-targeted candidate.)

In the original TURTLEDOVE explainer's API example flow, the browser itself made this decision, based on actual bid values. But under FLEDGE, all the logic of evaluating bids is in the hands of the seller, so their scoreAd() function is the only one that can possibly make that final decision.

[jdelhommeau]

Thank you!
So to summarize:

• Adserver and SSPs would run a "normal" contextual auction
• They would return the result of that auction to the page (creative code + price), somewhat similar to what we do already in header bidding
• Then adserver would initiate a FLEDGE auction, passing as input price information form the normal auction winner
• FLEDGE auction would run, in case an IG ad returns a bid value below the normal auction winner price, its desirability score would be 0, to effectively eliminates it.
• FLEDGE auction would then result in a "no ad" response if none of the IG bid was above normal auction winner price, or "ad" in case an IG bid was above it
• If the FLEDGE auction result is "no ad" then adserver JS would render the normal auction winning creative
• If the FLEDGE auction result is "ad" then adserver JS would render the FLEDGE auction result in a fence frame and discard the normal auction winning creative

Is that correct @michaelkleber ?
Is that also how you were thinking of it @gangwang-google, or did you think of a different scenario to manage that?

Thank you again, this is incredibly useful to understand how FLEDGE would integrate in auction workflows.

[JoelPM]

@jdelhommeau - just a note that what you reference above as "adserver JS" could also be some other pub controlled script (a la Prebid.js). Unless the "adserver JS" adds all the necessary logic to call the participating SSP's IG code and passes in their contextual information, it's unclear to me how the "adserver JS" would allow multiple SSPs to compete like they do today. The diagram I put together here attempts to show one way of assembling logic/metadata that would allow this. If an "adserver JS" (GAM code or other) did this, then it would suffice. If an "adserver JS" does not, then it is likely not going to meet the needs of publishers.

As you note above, GAM isn't the only adserver that might get used (though it is the leading one by a large large margin), which is an argument for having a solution other than the "adserver JS". In other words, I'd like to see a model where any ad server can plug their JS into a solution rather than being the solution. To make it painfully clear: I'd like GAM and other ad servers to provide modules in Prebid.js, rather than attempting to take over the role of Prebid.js.

[michaelkleber]

@jdelhommeau Your summary is correct!

@JoelPM What you're talking about seems like the essential question from #59 or #202, about how to support the winner of one auction becoming a buyer in a second auction run by a different seller. Right? This still has some pretty hard questions that came up in previous discussions — especially around whether the carried-forward ad gets an opportunity to change its bid, obviously crucial if there is first-price-vs-second-price skew in the auction rules.

[appascoe]

I would just point out that in @jdelhommeau 's outline, the desirability score for the IG auction needn't be 0, though that may be a typical outcome. For example, a publisher may want to make sure an SSP gets a certain amount of delivery to keep the relationship healthy, and favor an ad with a lower bid.

[michaelkleber]

@appascoe Sure, so let's be very clear here. @jdelhommeau wrote:

• FLEDGE auction would run, in case an IG ad returns a bid value below the normal auction winner price, its desirability score would be 0, to effectively eliminates it.

Julien is pointing out that the score of 0 is how scoreAd() says: "This IG ad should not beat the contextual ad." This is completely correct. Once any IG ad receives any score above 0, the on-device auction will return a winner, and the contextual ad would not show.

Andrew, you're pointing out that the decision about which ad is better (the contextual one vs. the IG-targeted one) can be based on lots of factors, not just bid price. That's also completely correct. The code in scoreAd() is written by the publisher's chosen ad network, and they can use whatever criteria they want when they decide to bid zero vs non-zero ("let contextual ad win" vs "prefer this ad to the contextual ad").

[jdelhommeau]

thank you all.
@gangwang-google , do you have anything to add from the Google ad side? The new workflow seems quite far from the way GAM / ADX currently operate. Do you envision any friction updating the tech to fit into this? Do you feel this can be done under the currently defined timeline by Google Chrome? That seems challenging to say the least.
I am also interested in your point of view on @JoelPM comment, of having prebid.js run some kind of master FLEDGE auction on behalf of all the SSPs, rather than having a single partner to do it.
Maybe something we could discuss during today's call?

[jdelhommeau]

Hi all,
Restarting this conversation, as we still haven't confirmation from GAM on how they will interact with FLEDGE, while Chrome announced yesterday that testing is now available to developers and will soon be available on beta and stable versions through OT.
As most publishers out there use GAM as their adserver, and as far as I am aware, GAM must take final decision server side, which is not the case with FLEDGE as per above discussion. Does it mean that publishers using GAM can't realistically test FLEDGE for now?
@gangwang-google can we have more details in how publishers are expected to test FLEDGE while using GAM as an AdServer? How will GAM provide his own auction result to the page, in order to establish competition with the FLEDGE auction? If GAM has not planned to change its current behavior, does it mean publisher must change adserver if they want to test FLEDGE? If GAM has planned to change current behavior to be compatible with FLEDGE workflow, can we get documentation on this?

[jeffkaufman]

@jdelhommeau we are actively thinking through how to enable testing FLEDGE for publishers using Ad Manager, including integrations with other sellers, and we're hoping to share more details soon.

[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

[dmdabbs]

You might consider posting to the Google Ads GitHub repo.