Skip to content

Commit

Permalink
InterestGroup in reportWin() (WICG#303)
Browse files Browse the repository at this point in the history
Clarify expectations about when and how the interestGroup will become available to reportWin()
  • Loading branch information
mbowiewilson authored May 12, 2022
1 parent b34bd20 commit dda979a
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions FLEDGE.md
Original file line number Diff line number Diff line change
Expand Up @@ -399,7 +399,7 @@ Once the winning ad has rendered in its Fenced Frame, the seller and the winning

_As a temporary mechanism,_ these reporting functions will be able to send event-level reports to their servers. These reports can include contextual information, and can include information about the winning interest group if it is over an anonymity threshold. This reporting will happen synchronously, while the page with the ad is still open in the browser.

In the long term, we need a mechanism to ensure that the after-the-fact reporting cannot be used to learn the advertising interest group of individual visitors to the publisher's site — the same privacy goal that led to Fenced Frame rendering. The [Private Aggregation API](https://github.com/alexmturner/private-aggregation-api) proposal aims to satisfy this use case. Therefore event-level reporting is just a temporary model until an adequate reporting framework is settled and in place. (Once we have a trusted reporting mechanism, we can consider allowing the reports to be influenced by the interest group's `userBiddingSignals`.)
In the long term, we need a mechanism to ensure that the after-the-fact reporting cannot be used to learn the advertising interest group of individual visitors to the publisher's site — the same privacy goal that led to Fenced Frame rendering. The [Private Aggregation API](https://github.com/alexmturner/private-aggregation-api) proposal aims to satisfy this use case. Therefore event-level reporting is just a temporary model until an adequate reporting framework is settled and in place.


#### 5.1 Seller Reporting on Render
Expand Down Expand Up @@ -436,7 +436,7 @@ The arguments to this function are:

The `browserSignals` argument must be handled carefully to avoid tracking. It certainly cannot include anything like the full list of interest groups, which would be too identifiable as a tracking signal. The `renderUrl` can be included since it has already passed a k-anonymity check. The browser may limit the precision of the bid and desirability values to avoid these numbers exfiltrating information from the interest group's `userBiddingSignals`. On the upside, this set of signals can be expanded to include useful additional summary data about the wider range of bids that participated in the auction, e.g. the second-highest bid or the number of bids. Additionally, the `dataVersion` will only be present if the `Data-Version` header was provided in the response headers from the Trusted Scoring server.

The `reportResult()` function's reporting happens by calling the Private Aggregation API or, temporarily, directly calling network APIs. The output of this function is not used for reporting, but rather as an input to the buyer's reporting function.
The `reportResult()` function's reporting happens by directly calling network APIs in the short-term, but will eventually go through the Private Aggregation API once it has been developed. The output of this function is not used for reporting, but rather as an input to the buyer's reporting function.


#### 5.2 Buyer Reporting on Render and Ad Events
Expand All @@ -457,7 +457,7 @@ The arguments to this function are:
* sellerSignals: The output of `reportResult()` above, giving the seller an opportunity to pass information to the buyer. In the case where the winning buyer won a component auction and then went on to win the top-level auction, this is the output of component auction's seller's `reportResult()` method.
* browserSignals: Similar to the argument to `reportResult()` above, though without the seller's desirability score, but with additional `interestGroupName` and `seller` fields. The `dataVersion` field will contain the `Data-Version` from the trusted bidding signals response headers if they were provided by the trusted bidding signals server response and the version was consistent for all keys requested by this interest group, otherwise the field will be absent. If the winning bid was from a component auction, then `seller` will be the seller in the component auction, a `topLevelSeller` field will contain the seller of the top level auction. Additional fields could also include some buyer-specific signal like the second-highest bid from that particular buyer.

The `reportWin()` function's reporting happens by calling the Private Aggregation API or, temporarily, directly calling network APIs.
The `reportWin()` function's reporting happens by directly calling network APIs in the short-term, but will eventually go through the Private Aggregation API once it has been developed. Once the Private Aggregation API has been integrated with FLEDGE the `interestGroup` object passed to `generateBid()` will be available to `reportWin()`.

Ads often need to report on events that happen once the ad is rendered. One common example is reporting on whether an ad became viewable on-screen. We will need a communications channel to allow the publisher page or the Fenced Frame to pass such information into the worklet responsible for reporting. Some additional design work is needed here.

Expand Down

0 comments on commit dda979a

Please sign in to comment.