-
Notifications
You must be signed in to change notification settings - Fork 232
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
Event level signals for generateBid
and reportWin
#435
Comments
Hi Ryan, I'd like to share our perspective at RTB House:
Best regards, |
Any addition of some form of advertiser signals would provide a tracking vector, wouldn't it ? Shouldn't be the path to reporting be solved before making an additions ? My current understanding is to measure publisher/contextual signals or billing via event level APIs and any advertiser signals or advertiser/publisher interactions via aggregated reporting. |
Alonso Velasquez here, Product Manager in FLEDGE Chrome. You will see more of me in these GitHub discussions going forward. Excited to work with you all! Thank you to everyone who has weighed in on this issue. Let me preface by saying that as per our February 9th blogpost indeed we have decided to extend event-level win reporting until at least 2026. So, addressing use cases for bid optimization based on these noised, event-level datasets makes sense to us so that adtech can start propping up ML-based infrastructure in the short term, to give adtech ample time to start training and tuning their optimization models to learn to deal with the noise and eventually migrate to training in a trusted environment reporting infrastructure in the future, which continues to be our ultimate goal for FLEDGE reporting. It also makes sense to us to think about the signals adtech would find the most useful in terms of browser-defined signals and adtech-defined signals. For the browser-defined signals, for the proposed signals we are thinking the following: Please see the full proposal for value ranges for both signals in this spreadsheet. For the adtech defined signals, the feedback we have heard from adtech falls into 2 camps: Option A: support specific raw signals that GeneratedBid() would then calculate and bucketize following value buckets that we specify and pass that into reportWin(), Option B: support a single large field We have settled on Option B, and to support the variety and fidelity of signals we’ve heard we have decided to provide 12 bits of information, which equates to 4096 buckets. Adtech can choose to allocate those buckets across any number of variables they choose to. We believe with this approach adtech will have a large degree of flexibility as they iterate on which signals to pass and with which fidelity, and could potentially facilitate differentiation across adtech vendors. Noising: it is important that we have at least some nominal noise to curb reidentification efforts. We are proposing that 1% of the time each of the 3 fields, |
To clarify Option B: Signals can be stored in the interest group however an adtech desires as they are today (e.g. as part of |
|
Thanks for clarifying @ajvelasquezgoog , being able to compute these signals in I was wondering, do you have any thoughts on how long |
@jonasz yes, you are right, with the timeline assessment. |
This feature has landed in Chromium and will be available in M114, versions 114.0.5689.0 and later. See also #481. |
Closing this issue as I believe the ask was addressed. Feel free to reopen if there is remaining work here or further discussion is warranted. |
In order to prevent serving-training skew, we would like to request that the |
@stguav this request makes sense and we determined we will take on this remaining work |
This will land with GA (M116) or in some follow-on? |
We are in the middle of determining this, but yes if it's not M116, it should be a fast follow in M117 |
As requested in WICG#435 (comment)
* Add recency signal to generateBid() As requested in #435 (comment) * Fix spelling * Update FLEDGE.md
We propose to create the ability of having some event level signals for bidding and reporting. The signals proposed here describe the interaction between the user and the advertiser and don’t aim for identifying the users uniquely. It would be very beneficial to advertiser performance to have these additional event-level signals in
generateBid
andreportWin
. We propose to have a set of browser provided signals and a set of ad-tech provided signals.In the long-term, one could envision a system where these signals are used in
generateBid
per query but reported through Aggregate Attribution Reporting API. However, given the challenges there (e.g. issues/289, the latency of receiving aggregate data, and the need to reconstruct bid/cost at event level) we propose to have them in event level reporting in the short-term for the first versions of the Fledge framework.Browser Provided
generateBid
, but notreportWin
).These signals could be stored and updated by the browser at
interestGroup
registration time. Then, they could be provided togenerateBid
as part ofbrowserSignals
for bidding optimization. Finally, by providing these signals toreportWin
, they could be used for training ML models.For both of these signals bucketed values would suffice and some noise could be added.
Ad-tech Provided
There are additional signals we would like to include which would be difficult for the browser to provide as it won’t have easy access to non-FLEDGE ad placements. These signals capture top features of the user interaction with the advertiser (e.g. data on previous conversions/clicks that the user had with this advertiser). This information is available from the 1P data that the advertiser knows about the user. Then, these signals can be passed into bidding as part of the
interestGroup
, possibly as part ofuserBiddingSignals
or as a new field. The browser could then make these signals available in some form toreportWin
to enable ML model training.There are a couple ways we imagine that Chrome could enable these signals in reporting while controlling their information content and limiting the privacy impact:
The text was updated successfully, but these errors were encountered: