Declarative reporting

[michal-kalisz]

Various APIs integrated with Fledge allow (or will allow) defining data to be reported when some event on banner occurs:

• Fenced Frames Ads Reporting (event-level):

  • registerAdBeacon (report win)
  • window.fence.reportEvent("click"); (inside ad)

• Private aggregation api:

  • privateAggregation.reportContributionsForEvent (bidding function/ report win)
  • window.fence.reportPrivateAggregationEvent("click"); (inside ad)

• Attribution Reporting API with Aggregatable Reports (not implemented yet):

  • attributionReporting.registerPendingAggregatableSource (bidding function)
  • window.fence.registerAttribution("click"); (inside ad)

This provides some flexibility and enables implementing custom logic on the ad. However, in many cases we want to report a click event and there is no need to interfere with the banner logic.

FFAR comes with the idea of ​​introducing an event type reserved.top_navigation.
Private aggregation API provides reserved.{win|loss|always}

Moreover, FFAR reports submitted for the seller must also be called from the banner. Currently, the seller (SSP) often requires to provide information about the click (e.g. to calculate CTR for a given placement):

window.fence.reportEvent({
  'eventType': 'seller_click',
  'eventData': '',
  'destination':['seller']
});

But there is no standard for 'eventType': each ssp can define it differently. There is also related topic: clicks on the ad component (discussed in issue 332)

What do you think to make reporting APIs more consistent, so that :

• The reserved.top_navigation type event is supported by all 3 APIs
• Event type reserved.win is supported by ARA-AGG (to support post-view conversions)
• For aggregated (PAAPI, ARA-AGG) it is possible to define reserved.top_navigation event data (contribution/attributionSrc) per ad and per each ad component..
• Reports are sent to the seller/direct-seller (FFAR) and the buyer (FFAR, PAAPI, ARA-AGG)
• Banners (ad and ad component) do not need to call the reporting API (unless they want to introduce custom logic)

We call this a "declarative" approach, as the standard use cases require no javascript logic within the banner - the reporting behaviour is declared within generateBid. This has two important advantages:

• Buyers don't have to coordinate with sellers which events to report from within the banner. The standard events are reported by the browser, and the sellers may make use of them in any way they want.
• From our perspective, not having to handle the reporting events from the banner makes the implementation considerably easier.