Viewability, audibility, and other inventory quality metrics differ from click, impression, and begin to render reporting in that they require session-long observations of the advertisement. This presents a challenge for fenced frame reporting as it is designed today, which is to run sellside and buyside reporting worklets once at the start of the ad's life cycle.

Another challenge is that different vendors often report different definitions of viewability than what most are familiar with (MRC viewability), and there is still ongoing innovation in this space. That said, the design has to be flexible enough to express all of these variants, and any future variations in order for it to be palatable.

There are a couple of possibilities that we have discussed today:

1. A fully declarative approach, like AMP. Vendors would describe an arbitrary number of "triggers", which can fire (one or more times) based on variations in key metrics that they specify. These triggers would be wired to one or more beacon URL templates, which would be filled with the current measured state and sent to the vendor's event processing server.

   Benefits

   • the worklets can continue to run at the start of the ad's life cycle

   Downsides

   • the declarative syntax is very complex (e.g. AMP)
   • it isn't inherently more secure than measurement today. Each beacon can contain a large amount of data, and an arbitrary number of beacons may be sent.
   • declarative API are likely to be over-constrained, covering a known use case or standard, but more difficult to evolve and/or generalize.

2. An imperative approach, where the vendors continue to operate very similar to how they do today, but the beacons are not event-level. They are processed / aggregated on the client before getting sent as a single aggregated, multi-event beacon to the vendor's server.

   Benefits

   • no complex declarative syntax
   • similar to what vendors have today - allows for arbitrary innovation and reporting of different/new things. APIs like Intersection Observer API could be used with little modification.

   Downsides

   • worklets execution lifecycle would need to change to run continuously during the ad's lifecycle

An issue with viewability and audibility measurement, no matter how we solve it, is that the information must be calculated using data from outside of the fenced frame. In both solutions, this means an arbitrary number of bits can be encoded by the publisher, for example by positioning the ad on/off screen as to encode a signal over time. I think the only solution to mitigate this is to move from event-level reporting, to aggregated reporting. Note that this is required for both of the above solutions. Since we will end up paying this cost anyways, the only cost to approach number 2 is that the worklet must run during the ad's lifecycle.