How will turtledove support viewability, audibility, and other inventory quality metrics?

[jdfreder]

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.

[JensenPaul]

@shivanigithub might be interested in this issue

[shivanigithub]

Yes, we are actively brainstorming this and will update back here when we have more concrete next steps.

[shivanigithub]

I have written up a document discussing the problem and solution space for intersection observer in fenced frames. Welcome all feedback, PTAL, thanks!

To summarize, the doc goes into various possible approaches but the most feasible in terms of privacy and accuracy of data is described in the section titled "Aggregate report based solution"

[shivanigithub]

All: Would be great to hear feedback about the use cases that are being currently solved using the intersection observer events. That will help us weigh the trade-offs of the various solution approaches outlined in the doc linked above.

@jdfreder : What do you think about an approach where the scripts running in the fenced frame get to register the IO events they are interested in and their destination for aggregate reports and the browser creates those aggregate reports (no additional worklets get created for processing the events locally)? Also added this in the doc in the section "Aggregate report based solution - no additional worklets"