Header Bidding related clarification on eligible interest group

[virajawati]

Hello Turtledove Authors,

I would like to understand Turtledove Interest group selection in the context of Header Bidding.

Context:
In Header bidding, Publishers request bids for an ad slot from multiple ad platforms via header (ad) calls. Bids from these ad platforms are passed on to the publisher ad server ad call (as an input). Header bidders bids and publisher ad servers bids compete for the ad slot auction and a winner is chosen.

The key aspect is that:
To participate in the auction; header bidders do NOT partner with the publisher ad network.

TURTLEDOVE Interest Group Selection Spec
I am using following part of the proposal as a spec for Interest Group selection :

(The TURTLEDOVE mechanism is triggered) when the browser is in an interest group and loads a web page that gets its ads from a publisher ad network that is one of the group's reader domains or one of their ad-partners.

Interpretation

Following diagram shows state of a browser and how I am interpreting the spec in direct or RTB-style auction.

1 third-ad-network.com (partners with) first-ad-network.com. 
2 IG bid win collapses iframe into restrictive mode and nothing can be communicated with the main frame.  
3 (Assumption) Turtledove will use domain name (first-ad-network.com) to determine eligible Interest Groups

Here is the interpretation for Header Bidding style auction.

4 fourth-ad-network.com interest group is not selected as it does NOT partner with publisher ad network domain.
5 Cannot perform IG based auction in the header call (as not the ad renderer). Even if such thing is enabled; nothing can come out with interaction of IG winner (?).

Questions:

1. Can you please confirm the interpretation of the Spec is correct? Particularly wrt header bidding where 'fourth-ad-network.com's interest group (puzzles) will not be part of the auction.
2. If yes, it seems the independence of header bidders would be broken for Interest based ads (even being within the privacy boundary). Do we need additional trust / partnership establishing mechanisms (& other related changes like in the case of /fetch_ad) to solve the issue?

Thanks,
Viraj

[michaelkleber]

Hi Viraj, sorry for my delay in responding during W3C's TPAC meeting.

In the setup you describe, you say fourth-ad-network.com doesn't parter with the publisher's ad network. Does it instead partner with the publisher directly? In particular, how does the publisher get to exercise their control over what ads they do or don't want on their page? They might care a lot about whether the advertiser is toys.com or toys.xxx.

From the privacy point of view, the part of your flow that seems problematic is

Bids from these ad platforms are passed on to the publisher ad server ad call (as an input).

The exact bid from an interest group's on-device bidding function inherently contains some information. In the flow you describe, the bid value might be enough for first-ad-network.com to learn that this particular person is in the fourth-ad-network.com:puzzles interest group. That's contrary to one of the basic TURTLEDOVE privacy protection goals:

Web sites cannot learn the interest groups of any specific people who visit them.

[virajawati]

Hello Michael,

No worries.. Appreciate your response and session + discussions in W3C's TPAC meeting.

Does it instead partner with the publisher directly? In particular, how does the publisher get to exercise their control over what ads they do or don't want on their page?

Yes, of course. Publisher have a control on the header bidding Ad Network Ads (fourth-ad-network.com in our example). In fact they directly partner with the Ad Network (vs say in RTB; which goes through an intermediary).

The exact bid from an interest group's on-device bidding function inherently contains some information. In the flow you describe, the bid value might be enough for first-ad-network.com to learn that this particular person is in the fourth-ad-network.com:puzzles interest group

Ack this point of view. Based on the same line-of-argument I interpreted Turtledove's spec where " (effectively) 'fourth-ad-network.com's interest group (puzzles) will not be part of the auction. (run by first-ad-network.com)“
[This is the starting point for the next chain of thoughts so let me know if it is not correct]

It seems to me that 'fourth-ad-network.com's IG exclusion (despite publisher's desire) is an artifact of the currently proposed mechanism where we account for only a single way (namely - Publisher Ad Network domain) to decide 'allowed' Interest Groups during the bid-processing.

Publishers use Publisher Ad Network configurations to control the ad-network participants for the ad-slot. Turtledove seems to be relying on Publisher Ad Network domain-name (& partnership conclusions derived upon it). With the toy example I want to highlight the point that both are not the same.

I think if we can build a construct (say as part of the construction of the ad slots iframe or some other way) which can enable participation of multiple Ad-Networks interest group (along with its contextual counterpart) inside the sandbox declared via publisher specified configuration; we can solve this use-case within Turtledove's privacy goals.

Let me know if above arguments makes sense and you think there will be a room for such a solution if it satisfies all the privacy constraints (if not, why :)).

Thanks,
Viraj

[michaelkleber]

Thank you, that does make sense.

It seems to me that you're looking for two things:

1. An extension of TURTLEDOVE in which there is a waterfall of two (or more?) auctions, one "run by" the publisher and another "run by" first-ad-network, with the winner of one of them flowing into the other one.

   Obviously that is a new type of complexity, but seems like something we could design. Of course for TURTLEDOVE's privacy model to hold, we would expect both (or all?) of those auctions to happen on-device.

2. A way for the person running an auction to list which buyers are allowed to participate, rather than the buyers having to specify which auctions they'll buy on at interest-group addition time. This is a sort of pull-vs-push change to how things are specified.

   It seems like there is a two-sided design requirements here: an auction runner needs control over who's allowed to buy, and a buyer needs control over what auctions they participate in. (I'm assuming that fourth-ad-network won't buy on just any old publisher page, but only pubs they have approved!) This also seems like a new type of complexity, since presumably an ad isn't going to be bundled with a list of the million different domains it might buy on. But again, seems possible to design.

Is this an accurate way of breaking down your feature request, or have I over-simplified away something important?

[appascoe]

Chiming in here, that if @michaelkleber's last reply here is accurate, that TERN has mechanisms for both of these things, if it's of interest to you @virajawati. I wrote TERN to add functionalities like these to the base TURTLEDOVE proposal.

1. In TERN, the publisher supplies the auction logic. This script could be provided by an SSP, or it could be that it incorporates the logic from a series of SSPs. Using the privateData object, the publisher could specify its buyers that it wants to treat in a "header bidding" way for the particular ad slot. privateData could also contain a blocklist for certain advertisers, DSPs, SSPs, etc. The logic is quite open and allows for waterfalls; it all happens on-device.

2. In TERN, I see multiple ways of addressing this. The publisher can declare which buyers are allowed to participate in the metdata field of the publisher request. This can be enforced by the auction JS as in point 1. As for the buyer deciding which publishers or pages they want to buy on, there is also a privateData object in the advertisement data object which eventually gets passed into the bidding JS. While an allowlist of millions of domains probably can't happen here, certainly modest blocklists will be doable. Another way is, during the publisher request, a DSP (or advertiser) can pass in a flag through the publisherSignals object that also gets picked up by the bidding JS. Here, the bidding JS can incorporate logic where perhaps the adSignals object has a flag that needs to match the flag in the publisherSignals object in order to generate a bid. This is one way of ensuring millions of domains don't need to be shipped around.

[virajawati]

Overall, you are right Michael that the idea is : ‘Wire additional participants in the final auction’.

About the specifics from your response;

An extension of TURTLEDOVE in which there is a waterfall of two (or more?) auctions, one "run by" the publisher and another "run by" first-ad-network, with the winner of one of them flowing into the other one.

I think you got it close enough with ‘the winner of one of them flowing into the other one'. A slight nitpick is; I feel 'waterfall bidding' hints for an early return which may not apply to 'run by publisher' results.
Today, Publisher Ad server performs the final auction on the server-side which is typically hosted on the 3p domain - 'first-ad-network' in our case.

So I will rephrase it as '(effectively) the winner of the auction "run by" the publisher flowing into auction "run by" Publisher Ad Network'.

Obviously that is a new type of complexity, but seems like something we could design.

Glad to know & appreciate it!

Of course for TURTLEDOVE's privacy model to hold, we would expect both (or all?) of those auctions to happen on-device.

Yes - on same page.

A way for the person running an auction to list which buyers are allowed to participate, rather than the buyers having to specify which auctions they'll buy on at interest-group addition time.

Agree on the first part ‘A way for the person running an auction to list which buyers are allowed to participate’ with Publisher’s configuration being the total allowed space for the Ad-Network participants.
But I am not sure about the 'rather than'. Since all this being wired through an Ad-Network (or some equivalent notion) it may be good to have a combination where Publisher specifies its choice of Ad-Networks and Advertisers specifies its choice of Ad-Networks as the minimum bar (for this use case).

and a buyer needs control over what auctions they participate in

You are right. My thought is with Turtledove's contextual request in place we can reuse todays control where on-device IG bidding function gets the contextual response securely providing necessary details. With that control feasible; are you referring to something more as Turtledove's off-the-shelf feature?

Michael, does this gives some more clarity on the goal?

Andrew, thanks a lot for the TERN pointers and a detailed proposal. Will definitely go through it and confirm it being covered in TERN !

Thanks,
Viraj

[michaelkleber]

Thanks to both of you.

@virajawati Sorry for my accidental implications from using the word "waterfall" — I did indeed just mean a sequence of auctions run by different parties, in which the winner of one becomes a participant in the next.

@appascoe I'm not sure I fully believe the idea that TERN's single auction with publisher-or-SSP-provided JS is the right thing here. How would such an auction include decision logic written by two different parties? It would certainly make my life easier to only have a single auction, but I'm worried that it might not give everyone the control they need.

[appascoe]

@michaelkleber I'd say that, speaking personally, I'd prefer a single auction to be run by the browser: it's simpler, provides more trust in the outcomes than arbitrary auction code, etc. We added this to TERN as a response to PARRROT, and, thinking about it, that it is indeed probably closer to the way the market operates today: SSPs and publishers are the ultimate arbiters of how the auction works and who the resultant winner is at a particular price.

I suppose I'm imagining something like each SSP integrated with the publisher provides ssp1-auction.js, ssp2-auction.js, etc. Each of these, according to TERN, is responsible for providing a function that inputs the list of ads, and returns the winning ad and a price. Above this, I'd say the publisher could provide a function publisher-auction.js, which can execute ssp1-auction.js, ssp2-auction.js, ... as subfunctions, and return the winning ad and price from this "meta-auction," which can include mechanics such as a waterfall.

[brodrigu]

What @appascoe is describing is very much in line with how we think about the auction working in PARRROT. The JS which executes in the fencedFrame would be configured and ultimately controlled by the publisher, but could include JS that is provided by SSP or DSP partners similar to how prebid.js modules are enabled in a header bidding solution.

As @michaelkleber points out, there is additional complexity in accounting for all the crazy use-cases that are at play in the current ecosystem. What PARRROT is advocating for is a system where the browser can provide a safe sandbox for the publisher to continue to leverage solutions that work for it, without requiring custom browser code for every use-case.

[michaelkleber]

I don't think I understand some parts of how "single auction to be run by the browser" works for @virajawati's situation.

Suppose the browser has joined a dozen interest groups all buying through first-ad-network.com, the publisher's SSP. That SSP wants to run an auction to choose which of those dozen ads it most wants to show.

Are you saying that some code running on publisher.com should be able to overrule that decision, and pick a different ad buying through the SSP other than the one the SSP itself would have chosen? Because that's what a single auction would mean — all of the SSP's demand would flow through, and the final choice among them would be someone else's, not the SSP's.

That seems very surprising to me.

[brodrigu]

I’m not sure I follow how you got to a situation where the decision is being overruled.

Within PARRROT, I imagine bidders (DSPs, SSPs, Advertisers, Ad Networks) would be able to run some logic leveraging available data (interest group info, contextual info) to provide one or more bids to the auction logic that would be controlled by the publisher (or some third party acting on the publishers behalf). The auction logic would choose a winner from among these bids, determine price, report on the outcome and serve the ad.

The logic the bidders use to provide the bid(s) could perhaps be considered an auction, but that would depend on what that bidder is doing and I don’t think PARRROT or TURTLEDOVE needs to standardize that.

[michaelkleber]

In the TURTLEDOVE paradigm, each interest group acts independently: the "bid" that's produced by the ad that targets www.wereallylikeshoes.com_athletic-shoes is the same no matter what other interest groups this browser is in.

If you're thinking that first-ad-network.com has a separate opportunity to use its own logic to pick just one of its many interest-group-targeted ads... then yes, that's exactly what I'm calling an auction.

[virajawati]

Apologies for the delay in explanation from my side.

Now let me step back and make sure I remove any ambiguity with my possibly too generic usage of 'ad-network'.

I am very much referring to a standard header bidding use case like say shown in prebid.js diagram. The orange colored ad-slots on the page gets handled by calling Publisher Ad server. I couldn't find the spec in Turtledove to add multiple SSP's declaratively; hence I opened the issue.

One possible confusion could be that I showed the publisher ad-server as first-ad-network.com. If it simplifies I would rename it as publisher-ad-server-service.com. While naming it as first-ad-network.com I wanted to include another publisher ad server feature where ad server also provides server-to-server RTB style bidding.

Now PARRROT indeed adds a provision to solve the 'bidding participant problem' by allowing to wire multiple SSP's. Also, I think I get TERN can address it through some meta-data driven actions.

@michaelkleber Let me know if this clarifies. Also, can you please elaborate a bidding participant use case which I might have conveyed which will not be solved above? Or it is about the bidding auction aspect of it. I have slightly simplified publisher-ad-service server-to-server RTB flow hoping it can be possibly covered through generic mechanisms of PARRROT / TERN.

Will add my interpretation on the Bidding Auction piece mentioned by appascoe@ once this first issue is settled.

Thanks,
Viraj

[michaelkleber]

I do believe this is all clear now.

• Viraj, you're correct that the original TURTLEDOVE didn't contemplate wiring together multiple SSPs.
• Discussion in this issue, and at this past Web Adv BG meeting, has made it clear that when an auction is "run by" some party, that party
  1. gets to control which ads are allowed into the auction (which requires more flexibility than in the original explainer), and
  2. gets to write the "final javascript" that assigns a score to each ad (where the winner is the ad with the highest score, and the score may be different from any $ changing hands).
• Since only one party can own the "final javascript", the use cases in this issue require wiring together multiple auctions, with the winner (or maybe multiple winners?) from one auction being participants in another auction.

I think once we support wiring together multiple auctions, it can support all the uses described above. And also, I now think PARROT is actually a proposal for wiring together multiple auctions, even though it wasn't described that way :-).

[virajawati]

Thanks Michael !

imho, for clarity it may be super helpful to add such 'declarative participant inclusion' extension to :

The TURTLEDOVE mechanism is triggered when the browser is in an interest group and loads a web page that gets its ads from a publisher ad network that is one of the group's reader domains or one of their ad-partners

(which I feel has a great importance and is a precursor to the on-auction extension you added)

Lastly touching on the Auction piece; I do think some hierarchical control 'within the party' using custom ranking + filtering + bid only script would give an ability to view its own choices and will open optimization opportunities for all the parties like DSP, SSP & Publishers - say : [a] within interest group reader ad-network [b] within SSP ad-network (which will use outputs of a) [c] unified final auction (which will use outputs of b). {If such a custom script can be standardized via advertisings standards that would be awesome but browsers can less worry about it}

I personally feel; unified final auction [c] (possibly achieved by Turtledove style local-only and open to read auction) itself may alleviate some auction dynamics issues in the past and give some visibility to the involved parties to move towards the best auction strategy without worrying about transparency.

Thanks,
Viraj

[michaelkleber]

I quite agree that we'd need to change more things to handle your desire for a second auction eligibility model. I feel there are still important and very practice questions to think about.

Going back to the goal "a buyer needs control over what auctions they participate in", I think it's clear how that happens for a DSP choosing to buy through a particular SSP. But when bidding into an auction directly on a publisher page, how can the DSP be will-informed enough to exercise that control?

It seems hard for a DSP to keep track of thousands of different domains, any of which might change the rules of their auction at any time. Do you think the publisher page needs to provide some kind of metadata about whose logic is in charge of the auction? In the web-adv BG we've seen some heated disagreements about first- vs second-price auctions — surely the buyer at least needs to know that before bidding!

It seems like you want shoes.com to say "I'm willing to buy into any auction that happens on myLocalNewspaper.com no matter who is running it or what its rules are", and I feel like that API might not afford enough control.

[appascoe]

For an auction happening directly on a publisher page, I would say that the publisher is functioning as an SSP, and would call out to a DSP using the same mechanism as available in TURTLEDOVE or TERN. If a DSP has enough control in the SSP context, I don't see the issue here in the publisher context... but maybe I'm missing something. But generally, today, header bidding functions by the publisher page making a direct call to the DSP with the understanding that it's a header bidding auction for that publisher. It just doesn't feel that different to me from a call from an SSP.

TERN specifies that that the publisher or SSP declare, mandatorily, the type of auction it intends to run, to allow the DSP to take this into account in its bidding function. What's to stop the publisher or SSP lying? Well, nothing really. This is actually the situation as it stands today. Indeed, as a DSP, we've detected such abnormalities and adjust accordingly. We've even seen players modifying our bid prices after submission. I don't want to make this sound common, but it does happen, and as a DSP we try to be vigilant of these things.

[michaelkleber]

Andrew: the reason the publisher-as-SSP situation feels different to me is that a buyer might well know the auction details, habits, and reputation of each SSPs they choose to integrate with. This seems more feasible for 10's of SSPs than for tens of thousands of publishers. (Any time the number of parties you're interacting with increases by three orders of magnitude, it's worth rethinking assumptions.)

If the buyers of the world indicate that this is not a concern, then it's OK by me!

[JoelPM]

@appascoe - I dispute that the publisher acts as an SSP in the page level auction (most commonly run by prebid.js). In that situation the publisher isn't providing his own AQ solutions, reporting, DSP targeting, QPS throttling, etc. In those cases the Pub is just soliciting multiple SSPs (with each of whom there is a pre-existing relationship that involves inventory mapping, market rules, paper/contracts, etc), and then passing the highest bid to the adserver/AdX to compete. This has traditionally been a first price auction. The SSPs all ran their own auction (server-side, and it may have been 1st or 2nd price) to choose their winner. And prior to that the DSPs all ran their own auctions to select what qualified bid they would respond with to an SSP (of the N that may have been available). In that case the auction was likely not purely monetary, but also took predicted performance into account, however it was still an auction of sorts. All that to say that running an auction doesn't make you an SSP.

In my reading of TURTLE-DOV it seems like the goal is to enable a single SSP to choose between contextual and IG based bids, but it doesn't address the publishers ability to choose from multiple TD auctions. I would love to see this clarified, as it leads to a lot of confusion (which I think is what spawned PARRROT). (Update: opened #73 to get clarity on this.)

Is the goal of TD to protect user's privacy, or to control the final page level auction (or both)? I'm assuming it's the former, but in that case TD needs to provide an API that the pub (most likely using prebid.js) can access to get the final TD bid for a single SSP.

[AramZS]

Hey @michaelkleber I've been thinking more about this and your proposed solution in FLEDGE and since this seems to be the main thread to discuss it I thought I should put my feedback on the current state here. (Take my use of FLEDGE or TURTLEDOVE interchangeably as I understand FLEDGE to be a precursor that leads into further development of TURTLEDOVE)

The auction configuration's list of additional_bids is meant to allow a second way for ads to participate in this on-device auction. More design work is needed to figure out how to support buyers' and sellers' needs in the multi-level decision-making use cases like those discussed in Issues #59 or #73 — a simple approach like putting one auction's auctionResultPromise into another auction's additional_bids is probably not sufficient. This field may not be usable yet in the First Experiment stage, depending on how much new complexity it adds to the design.

I agree that this is not sufficient. I think it might be worthwhile to talk about some of the issues here.

1. This would likely cause an overall delay in returning the bid. Any delay is expensive and a single element of the bid process having to wait on other bid process methods to complete is not only likely to be very expensive.

2. If the final bid decision is in the browser protected space then it pushes logic for the bid decision into an increasingly black box and removes significant degrees of control from the client side which is closest to the browser.

Now... to be clear here, I'm not accusing anyone specifically of being likely to perform shenanigans in the protected auction space if the FLEDGE/TURTLEDOVE auction process has domain over all other bids... but it is very easy to see how a protected space without transparency into its operation that also could potentially gain knowledge of all bid values before deciding if a FLEDGE auction wins might be able to unfairly advantage the FLEDGE auction in a variety of ways. If it did advantage the FLEDGE signal that would be invisible and disadvantageous to all other players in the hands of an unscrupulous browser interested in proving FLEDGE's value, or that browser's particular value. Once again, not saying that anyone in particular is likely to use sole control of the auction space to look at the other bids that come in and make a choice to promote the FLEDGE response, regardless of the performance of other bids, or to delay resolving the bid process in order to advantage slower players' response to FLEDGE signals. But the idea that ad functions are moving into the browser would seem to incentivize even a creation of extending browsers that approach these ad functions differently and in that case, the likelihood of malicious action goes up.

I think a situation here might be to allow the publisher to make the final decision on how to resolve a set of bids. This could be accomplished by a change to the auctionResultPromise object. This could instead be an object that contains the Promise and a property that indicates the value of the winning bid (perhaps itself a promise). That object could then be resolved by whatever method a sell-side site resolves incoming auctions to make the final decision on which auction wins in a transparent way visible and executed client-side. While setting bid floor might be a way to remove the privacy guarantee, I'm not sure that returning a winning bid would have the same vulnerability, but I would think adding noise or rounding that value might be a way to be sure to preserve the guarantee.

Perhaps that is still too privacy invasive, in which case a mechanism like decision_logic_url might be useful. But I think this brings forth that question of a trusted server again (from a number of proposals that have gone deeper into the topic than I). In either case the most optimal situation would be to have another entity than the browser make the final bid decision in a way that is auditable and/or transparent.

[JoelPM]

"I think a situation here might be to allow the publisher to make the final decision on how to resolve a set of bids."

My hope/expectation is that Prebid.js will fill this void. I've delved deeper into that thinking here, though I haven't updated it for FLEDGE. I think the principles that make Prebid acceptable to pubs and SSPs will also be the same ones that are needed for a workable solution in that space. I'm glad this is being raised.

[michaelkleber]

Hi Aram: Just to be sure we're on the same page, in the FLEDGE model the question of which ad wins is entirely in control of the seller who runs the auction. The seller's code gets to see each buyer's bid, assign some "desirability" score to each bid, and the most desirable one is the winner.

So when you say a better approach "might be to allow the publisher to make the final decision on how to resolve a set of bids", are you distinguishing the seller's code from the publisher's code here, or is there some other hole that you're trying to plug?

Perhaps the key thing here is "make the final decision on which auction wins in a transparent way visible and executed client-side"? I think Michael Lysak = @TheMaskMaker's #114 is the most relevant discussion we've had on this transparency goal — per our 3/17 meeting, this "publisher trusted agent" / "auditor" would be in a position to look at the auctions inputs and outputs. But again, for privacy reasons, this would also need to happen on-device: that auditor's code would be in a position to see enough information to track a person across sites, so it would need to be limited to only aggregate reporting.

[michaelkleber]

Following up on this issue, there has been substantial discussion of this topic in the FLEDGE phone calls on 2021-08-18 first topic, and 2021-09-01 last topic.

In particule, @JoelPM has advocated for a model that is not based on "multiple auctions feeding into another auction", but instead "multiple auctions and then on-device rules that decide which auction's winner renders". This is much simpler than what I had imagined, which makes me happy!

[fbastello]

Hi @michaelkleber ,

Thanks for the feedback on this issue.
A quick note from my side to second what was discussed in the 2021-09-01 meeting. Would it be reasonable to have this "resolveAdAuctions" function as part of the Chrome API in time for OT?

There are still consequences to consider and discussed further stemming from the addition of such function I believe, like how scoring would work across SSP participants and if enough metadata can be made available to implement a publisher logic as defined in slide 13 of the presentation shown during the meeting.

[michaelkleber]

We're still figuring out how to offer this functionality, so it's too soon for me to make any promises about when we'll have an implementation. My best guess right now is that we can fold it into the URL selection capability in https://github.com/pythagoraskitty/shared-storage, which already envisions a worklet with private information affecting the choice of what ad to render inside a Fenced Frame.

[JensenPaul]

I’ve been spending a lot of time talking with a variety of Chrome folks about how best to implement support for multiple SSPs in FLEDGE. I think there are a couple of implementation choices here that I wanted to walk through.

First implementation choice: Should the final ad selection be made via Shared Storage or a FLEDGE auction?
My proposed answer: FLEDGE auction.

There’s a few trade-offs here so I wanted to run through them. I don’t feel like there’s a clear winner but I think FLEDGE makes more sense:

1. Fitment of purpose: As the name Shared Storage suggests, Shared Storage selects ads based on a store of data shared across multiple sites. In the case of selecting amongst ads from multiple SSPs’ auctions, this shared storage doesn’t seem particularly useful. In @JoelPM’s admittedly crude pub logic example there is no reference to such a data store, instead each SSP’s result could be scored independently and the browser could pick the highest scoring ad, exactly as in a FLEDGE auction.
2. Direct correlation: Using Shared Storage to select the ad would allow information from a variety of other sites the user has visited affect the final ad selection which breaks the direct correlation benefit I talked about in my issue 162 response. Using a FLEDGE auction for the final ad selection does not break this benefit.
3. Added dependency: Using Shared Storage for the final ad selection introduces an additional dependency on Shared Storage for FLEDGE. Adding dependencies to FLEDGE increases the risk to shipping FLEDGE.
4. Possibly increased utility: Using Shared Storage could introduce extra utility by drawing from the other information in Shared Storage. This comes at the cost of the direct correlation mentioned above.

Second implementation choice: Have multiple runAdAuction() calls (passing each SSP’s auction result to the final auction via opaque URLs) or just one runAdAuction() call (specifying each SSP’s auction config, and the final ad selection auction config)?
My proposed answer: one runAdAuction() call.

Again I’ll run through the trade offs, and although I don’t feel like there’s a clear winner, I think having a single runAdAuction() call makes more sense:

1. More intermediate results exposed to site: As the FLEDGE explainer talks about, each auction result encoded as an opaque URL leaks one bit of information to the surrounding page depending on whether it’s null or non-null. Having multiple runAdAuction() calls would leak correspondingly more information to the surrounding page.
2. More IPCs: Passing around opaque URLs requires more complexity on the JavaScript side and on the browser implementation side. The intermediate auction results have to be encoded and decoded as opaque URLs. The opaque URLs must be passed back and forth via IPC between the browser and renderer processes more. This added complexity and work will decrease the performance of FLEDGE auctions.
3. Confusing reporting: With multiple calls to runAdAuction(), it’s unclear how to do reporting for non-final auctions. For example if a bid wins a non-final auction but loses the final auction, reporting the initial win may be incorrect as the bid’s ad didn’t actually win the final auction and get displayed.

Do these two decisions properly address the use case here?

Which bids does it make sense to report as the winner in a multi-SSP case? Just the one that wins the final auction? or does it make sense to report the winners of non-final auctions as the winners as well?

[JoelPM]

I believe those two decisions properly address the use case, at least from my perspective.

I hadn't considered the possibility of reporting non-final auction winners, but it's an interesting idea. I think that functionality would be useful for sellers (pubs and SSPs) to understand dynamics of the demand landscape, which would be similar to the use case that @suprajasekhar raised in the last FLEDGE call (sorry, link to meeting notes not available yet). At this point I'd probably classify that as more of a nice-to-have than a requirement, though.

It's great to see the Chrome team putting thought into supporting multiple SSPs - very encouraging.

[qingxinwu]

I’m thinking about what to do for reporting the winning bid price and 2nd highest scoring bid price in the multi-SSP case, specifically I’m trying to answer:

1. Do we want bidders of a component auction to receive the winning bid price and 2nd highest scoring bid price from the top-level auction or from their component auction, or both?
2. What about for sellers in the component auction and top-level sellers?
3. And in cases where the component sellers modify the bid price, do we want to report the modified or original bid price?

[JoelPM]

These are my current thoughts, which are based on how auctions work today on the server-side:

1. I think a bidder (DSP) should only receive information for an auction it participates in. If it participates in both, then it should receive info from both. If it only participated in a component auction, it should only receive info from the component auction. I'm not sure what info a bidder should be told; in the contextual (server-side) auction they only know the winning bid price if it was theirs, and they don't receive other information on the bid landscape. This is intended to keep them bidding based on how they value the opportunity and not simply what it takes to beat their competitors. If we keep things the same, they would be told the winning bid price if they won, and be told they lost if they didn't win.
2. I would expect the seller of a component auction to have access to the entire bid landscape of the component auction. When it competes in the top-level auction it is effectively functioning like a bidder, and thus I would expect it to know the winning price if it wins, and otherwise be told that it lost (no other bid landscape info provided).
3. I expect modifying the bid price will be the norm. That being said, I think the bidder and the seller should both receive the modified (actual) price.

[dialtone]

My $0.02 is that the decision on what is shared with a bidder should be based on what we want their incentive to be mathematically. Bidding true value isn't optimal in a first price auction for example, and providing the winning price doesn't seem to me like it should be considered giving much insight into the bid landscape, this is something that Google AdX already support with RTB Feedback for example. We also shouldn't be looking to make participating in component auctions worse data-wise than participating in the top level auction, as that would hurt component auctions (saying this as a general opinion, not that it necessarily applies here). Lack of transparency in the current multi-level auctions for header bidding is not a feature but a bug IMHO.

[JoelPM]

We also shouldn't be looking to make participating in component auctions worse data-wise than participating in the top level auction, as that would hurt component auctions (saying this as a general opinion, not that it necessarily applies here).

This is a very good point, and I agree 100%.

Lack of transparency in the current multi-level auctions for header bidding is not a feature but a bug IMHO.

Doesn't a first price auction (at all tiers) actually work in your favor here? The challenge with second price auctions was that the clearing price in a sub-auction meant that a DSP couldn't predict how they'd participate in the final auction. I can see how that would be very frustrating. With FPA, the bid should largely* just get passed through each layer and participate in the final auction in a much more deterministic way (unless it loses, but if it loses in a sub-auction, it would've lost in the final auction).

On the topic of bugs and features, I would say that the current method of DSPs passing only a single bid when multiple were eligible is also a bug, not a feature. There is bid landscape information asymmetry for both pubs and bidders in the current setup, which leads to an inefficient market.