FLEDGE triggers reporting worklets prematurely

[zhengweiwithoutthei]

According to the spec and this comment, event level reporting on an auction outcome for both seller and buyer should only be done once the winning ad is handed to a Fenced Frame to render. However, we noticed that the reporting is prematurely triggered in runAdAuction() even though the winning ad is not rendered (BUG). This is problematic, especially since there is no way to stop an auction or prevent it from reporting a winner (if any) once it starts.

For example, imagine the scenario that an auction takes too long to finish, the seller might choose to abandon the auction and render a contextually-targeted ad. The abandoned auction will run to to completion, and report the outcome if there is a winning bid, even though the winning interest group ad will not be rendered. This raises challenges: the backend systems might receive conflicting information about whether there is an interest group auction winner or a contextual winner resulting in an inconsistent auction state; knowing which of the two actually rendered and resulted in a billable event becomes ambiguous.

Can Chrome fix this bug so that the event level reporting is only triggered when the winning ad is rendered in a Fenced Frame?

[JensenPaul]

This does seem like an area of difference between the explainer and the implementation. It’s a little tricky however for a couple reasons:

1. It’s unclear what “when the winning ad has rendered” means. For example, someone could make the rendering of their ad hang after it’s 99.9% visible, so that their ad is nearly entirely displayed but reports never trigger so they never have to pay for the ad impression.

2. If you don’t want to receive reports for slow auctions, how do you want to diagnose what’s slowing down auctions?

I think there’s a few possible solutions:

1. We could maintain the current behavior, but sellers could keep track of which auctions take too long, and report this information to themselves, and ignore other reports coming from these auctions (e.g. report back that “auction number 123 took too long”, and then ignore any reports tagged as coming from auction number 123).

2. We could maintain the current behavior, and bidders and sellers could use the Fenced Frame Ads Reporting API to register ads beacons, and then trigger events to send the reports only when the winning ad has been rendered. This would require cooperation from the ad creative to trigger the corresponding events however.

3. We could maintain the current behavior of sending reports just prior to auction completion, but allow auction configurations to specify an overall auction timeout. If the timeout is hit, no reports are sent.

4. We could maintain the current behavior of sending reports just prior to auction completion, but change the implementation to make the cancellation of the promise returned by runAdAuction() cause the auction to be canceled. If the auction is canceled, no reports are sent.

5. We could change the implementation to delay sending reports until if and only when a Fenced Frame is created using the opaque result of an auction.

Concerns with these solutions:

Solutions that abort auctions prior to reports being sent may make it harder to solve issues like #299 where sellers want more information about slow auctions, as slow auctions may never result in reports being sent if they timeout or are canceled. This could be worked around with a declarative reporting API mechanism (e.g. an API indicating “fetch https://example.com/took-too-long-${bidder} when a particular bidder takes too long”).

Solutions that don’t abort auctions may waste resources by not terminating an auction whose results won’t end up being used.

I think my preference is for solution number 3.

[zhengweiwithoutthei]

Thanks @JensenPaul.

From SSP's POV, option 4 (cancellable API) is preferred as it offers the most flexibility. Imagine a site canceling an auction once a BTF slot comes close enough to viewport which can help minimizing the blank rectangle time. Or the site might want to abort an auction once a slot moves aways from the viewport to save computational resources.
I view option 3 (a global timeout) as a subset of option 4. It can work as a short term solution if it requires significantly less effort to implement compared to option 4.

[jeffkaufman]

Imagine a site canceling an auction once a BTF slot comes close enough to viewport which can help minimizing the blank rectangle time.

See also #293

[zhengweiwithoutthei]

To clarify, it is sufficient to deal with the conflict ping issue mentioned in this post with (only) option 4. It doesn’t mean option 5 is not important. For impression counting purposes, we (seller) still want to be able to learn whether an IG ad is actually handed over to a Fenced Frame for rendering.

With option 4, the ping is sent after an auction concludes. We don’t know if the winning ad would appear on the page. This is quite different from the semantic today in the non-FLEDGE world where we count the impressions only when the browser starts rendering the frame that contains the ad.

In short, we would like to have both option 4 (a cancellable API) and option 5 (delay reporting until rendering).

[JensenPaul]

Solutions 4 and 5 were both implemented.