You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
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.
The text was updated successfully, but these errors were encountered:
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):
Private aggregation api:
Attribution Reporting API with Aggregatable Reports (not implemented yet):
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):
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 :
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:
The text was updated successfully, but these errors were encountered: