Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bidders in top level auction #412

Closed
JensenPaul opened this issue Dec 6, 2022 · 15 comments
Closed

Bidders in top level auction #412

JensenPaul opened this issue Dec 6, 2022 · 15 comments

Comments

@JensenPaul
Copy link
Collaborator

In FLEDGE component auctions, when there are two levels of auction, we should consider ensuring the equity of bidders in both levels of the auction.  One issue to consider is the comparison between a bidder in the top level auction versus a bidder in a component auction.  The bidder in the top level auction need only win that one auction, the top level auction, to display their ad, while a bidder in a component auction must win both the component auction and the top level auction to display their ad.  One way to mitigate this inequality is to require that when component auction configurations are present, either require that the top level auction configuration have no interestGroupBuyers, or have the browser ignore the interestGroupBuyers list in this case.

@michaelkleber
Copy link
Collaborator

I definitely agree that we should make this change — indeed I think that @JoelPM intended things to work this way when he proposed the Component Auctions design, and I intended things to work this way when we adopted it.

Fortunately I'm pretty sure nobody is counting on the current implementation — in particular GAM already does not allow the top-level auction to have any buyers at all, once there is a component auction happening. I think we should make this change quickly, to avoid the risk that anyone starts to depend on the current version.

@JoelPM
Copy link
Contributor

JoelPM commented Dec 7, 2022

Good catch. I very much support this change.

@MattMenke2
Copy link
Contributor

Nothing prevents a top-level seller could also be a component seller, and just passing along the top-scoring bid using the top-level same scoring function as the top-level seller, so this doesn't seem to really get us much?

Also, different component sellers may take different cuts off the top, when modifying the bid, which is another source of inequity among bidders.

@michaelkleber
Copy link
Collaborator

michaelkleber commented Dec 13, 2022

Indeed we expect that the top seller may well be a component seller. But in that case the top seller should pass a single best ad into the top-level auction just like any other component seller does. (And that's already how the GAM component-auction code works today.)

But if anything happens that depends on the bid landscape — a second-price auction, for example — then the top-level seller should just see their own demand, just like any other component auction, rather than seeing their own demand plus the winning ad from other components.

@MattMenke2
Copy link
Contributor

So this is just about second price auctions, then? Sellers only see one bid at a time, apart from exposing the second price to reporting methods.

@michaelkleber
Copy link
Collaborator

I agree that the impact of bid landscape in FLEDGE auctions is pretty limited right now, but I still think we should get this right at the outset, and avoid the risk of burn-in and of more bid landscape reporting leading to any kind of inequity among sellers in the future.

@JoelPM
Copy link
Contributor

JoelPM commented Dec 13, 2022

While technically it may not matter, there will be less concern if conceptually everyone competes at a 'fair' level (as a component auction) and the code that evaluates the outcomes of the Component Auctions doesn't also evaluate IG bids directly.

(And since I've gone to the effort to comment I will also note that I believe @MattMenke2 or another member of the Chrome team designed the ComponentAuction mechanism - I can't take credit for that. I only expressed the request for a means of running a tiered auction. There, I feel better having clarified that.)

@michaelkleber
Copy link
Collaborator

michaelkleber commented Dec 13, 2022

(Hey @JoelPM, re. your final comment: I've been giving you credit for proposing the design because of your issue #202, your presentation which first introduced the "Option 2" approach, and your advocating for that option in the calls referenced in #59 (comment) and further conversation on that issue. The previously-floated Option 1 had problems which had prevented us from moving ahead, and Option 2 showed us the way forward. If you want me to stop crediting you then I am of course happy to do so, but that's what broke the logjam for me.)

@jdelhommeau
Copy link

Fully agree with the above. @michaelkleber this was the issue we raised last time during our meeting and in our notes (IAB France). I think there was some confusion about it last time, but glad to see that we are all aligned now, and that we agree on modifying current behavior.
I also think that it no longer makes sense in bids from buyers to pass the "allowAuctionComponent" as part of their bids, since they will now only be able to participate in either top auction (in case no component auction) or component auctions. Do you agree?

@MattMenke2
Copy link
Contributor

Fully agree with the above. @michaelkleber this was the issue we raised last time during our meeting and in our notes (IAB France). I think there was some confusion about it last time, but glad to see that we are all aligned now, and that we agree on modifying current behavior. I also think that it no longer makes sense in bids from buyers to pass the "allowAuctionComponent" as part of their bids, since they will now only be able to participate in either top auction (in case no component auction) or component auctions. Do you agree?

I, at least, don't agree. The issue with component auctions is that they mean a bidder's bid, and the presence of a user in an IG, will be shared to two sellers, instead of just one. Requiring bidders to affirmatively declare they're OK with this seems safer than just assuming they understand that component auctions exist, and that their information may be shared with more than just the immediate seller running an auction. I don't think not allowing top-level auctions to have buyers directly in them changes anything with respect to that concern.

@jdelhommeau
Copy link

Sellers won't know which specific IG thought, right? Only that for this specific buyer to submit a bid, the user had to be in an IG owned by that buyer, right? I don't really see the reason why the buyer would mind, since he will likely participate in auction ran by either of the sellers, so they will get that information eventually.

@MattMenke2
Copy link
Contributor

The main ad URL is passed to sellers, which may or may not uniquely determine the IG. The bid price is also exposed, which it is my understanding bidders often view as proprietary information.

@michaelkleber
Copy link
Collaborator

@jdelhommeau Yes, this is indeed the issue that Alliance Digitale brought up. Thank you again for pointing it out and letting us track down the confusion.

I agree with @MattMenke2 that we should still keep the allowAuctionComponent bit. This is how buyers make it clear that they are happy with who is running both the component auction and the top-level auction. If buyers only think about single-level auctions (because right now there is not a second SSP testing FLEDGE), then that same buyer might be surprised when they find themselves in a component auction and may not be happy with the outcome.

Since the on-device auction is such a new environment that we will all be getting used to, I support having some extra safety checks to help reassure the participants that things are working like they expect.

@michaelkleber
Copy link
Collaborator

(oops sorry closed by accident!)

@michaelkleber michaelkleber reopened this Dec 16, 2022
@JensenPaul
Copy link
Collaborator Author

Closing this issue as I believe it's addressed with #419

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants