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

Assess the true performance of Fledge #317

Closed
fhoering opened this issue Jun 17, 2022 · 2 comments
Closed

Assess the true performance of Fledge #317

fhoering opened this issue Jun 17, 2022 · 2 comments

Comments

@fhoering
Copy link
Contributor

As detailed in Google’s CMA commitments, the Privacy Sandbox has to be evaluated, among other things, with respect to:

impact on publishers (including in particular the ability of publishers to generate revenue from advertising inventory) and advertisers (including in particular the ability of advertisers to obtain cost-effective advertising)

At Criteo, we think that the Origin Trials should be the way to do that. In January 2021, Criteo published TEETAR, as a path toward such testing.

We would like to re-activate this discussion now focusing on some concrete steps on how to get real world measures within the current Origin Trial.

In this post, we’d like to discuss how to achieve, for a given set of users, FLEDGE auctions that would not compete against auctions where participants can use third-party cookies.

The current plan from Google Ads during the origin trial (OT) is to activate the Fledge bidding logic on top of the current RTB pipeline process (ads-privacy/proposals/fledge-rtb at master · google/ads-privacy , ads-privacy/proposals/fledge-multiple-seller-testing at master · google/ads-privacy ). This means that for the same user Fledge interest group bidders would bid against existing RTB bidders who could still use 3rd party cookies (running side by side).

While this is a good first step to be able to test the Fledge pipeline, it is a blocking point to assessing FLEDGE’s potential. As the current bidders use more information about the user (for example by combining multi-advertisers signals) the bid would be necessarily better. Therefore we somehow already know that:

  • Fledge bids will loose against existing bidders for good opportunities
  • Fledge will win some bad opportunities (because other bidders know that it would be a bad opportunity)

So the result of the current setup would be very likely that the performance of Fledge is not good enough.

To remove this biais, we’d like to come up with a plan, that will be activated at a certain stage in the Origin Trial, preventing FLEDGE auctions to compete with auctions based on third-party cookies.

Some considerations that we think are important:

  • Chrome could put some users into a small AB test population where it stops sending 3rd party cookies under certain conditions
  • This would apply to interest group creation where for example all fetches initiated from scripts taking part in the Origin Trial (having set a token) would not receive the 3rd party cookie for this user.
  • On bidding side it seems trickier because Google Ad Manager should stop transmitting the user identifiers/3rd party cookie in the existing bid streams
  • Ideally current SSPs would take part in the Origin Trial to increase the competition of the Fledge auction process
  • Capping of frequent ads could be handled through Fledge as the same user would go through the Fledge pipeline (browserSignals.prevWins) and would be unhandled for the contextual requests

Would you please share Google’s plans related to such testing?

We also welcome ideas and contributions from other SSP on how to test FLEDGE as described.

CC: @sbelov

@michaelkleber
Copy link
Collaborator

See excellent discussion of this topic in the notes from today's FLEDGE call, https://github.com/WICG/turtledove/blob/main/meetings/2022-06-22-FLEDGE-call-minutes.md

@JensenPaul
Copy link
Collaborator

The plan here seems to address some of the asks laid out in this issue.

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

3 participants