Alternative video flow for component seller to reduce user latency

[timphsieh-google]

Proposal

Video Support for Component-seller Auction in Protected Audience API proposes to include the sellers (top level seller and/or component seller) as part of the VAST redirect chain. Being part of the VAST redirect chain allows a seller to return tracking information to the video ad player. However, this flow adds complexity to the auction and additional redirects increase user latency.

Instead of using VAST to define tracking events, sellers could use the Fenced Frame Reporting API with a set of predefined tracking events. For example:

1. The video ad player publicly publishes a list of significant ad events that they will support through the Fenced Frame API. For example:
   • video-impression
   • video-click
   • video-1st-quartile
   • ...
2. During reportResult(), sellers can register a tracking URL for these events using registerAdBeacon() .
3. During playback, the video ad player calls Fenced Frame API’s reportEvent() on each significant event.
4. The browser calls the URL that is pre-registered with the event.

Pros

• The component seller does not need to use macro replacement to insert a VAST URL for their tracking events.
  • This reduces dependence on APIs marked by chrome as deprecated.
• The video ad player does not need to follow redirects to the seller or component seller. This can reduce user latency.

Cons

The component seller cannot return a VAST document in this proposal. As such, the component seller would not be able to:

• Use 3rd party verification adtech through <AdVerification>.
• Utilize the custom eventData feature of the Fenced Frame Reporting API.
• Use progress events with arbitrary time offsets.

Questions

• What other functionalities do we lose if the seller and component seller do not provide VAST?
• Are these functionalities worth the latency and complexity?

[patmmccann]

I like this proposal, removing the layers of the vast onion one at a time is not particularly elegant in the status quo and proposals to do instream that do not inherit the problems and complexity of the status quo for momentum's sake will certainly earn my +1.

The second con here sounds quite serious however, "the component seller would not be able to ... Utilize the custom eventData feature of the Fenced Frame Reporting API."

Would this be mitigated if the player and the component seller were the same entity?

Perhaps the browser could be modified to solve?