Feedback on Protected Audience API for Instream Video

[mkendall07]

Wanted to share some feedback and thoughts on the 2 proposals for instream video (https://github.com/google/ads-privacy/tree/master/proposals/protected-audience-video, and https://github.com/google/ads-privacy/blob/master/proposals/protected-audience-video/component-seller.md)

1. The Protected Audience VAST Player (PAVP) component adds additional complexity and complications:

   1. Introducing player interactions between publisher player, 3p SDK (if applicable) and PAVP via postMessage could introduce latency into the user experience (i.e. pause, play interactions etc).
   2. The implementation of this component would reside with either the publisher or the video player if the publisher is not using GAM as the primary ad server which would be a significant lift to be implemented by the publisher and or video player.

2. The construction of the renderUrl presents a few challenges:

   1. Multiple sellers using macro expansion - builds a chain of dependencies of 3rd parties to execute properly, introduces extra latency, would be difficult to debug and conceptually is complex.
   2. Using renderUrl for video/native seems like a bit of a misfit/hack. Instead - there is a proposal for "first class citizen rendering" for Native/Video (Support for native advertising WICG/turtledove#265 (comment)) that seems like it could solve some of the challenges of the “renderUrl” problem.

3. Reporting VAST events through reportResult would require changes to all the VAST payloads (in the form of a VAST extension) from the DSP as well as the seller or SSP and might take a long time for adoption.

4. Long term, I'm unclear how VAST redirects would be supported if the fence frame doesn't allow additional HTTPS requests. What would be the mechanism for supporting such scenarios (which are very common)?

[patmmccann]

re 2ii: +1 on extending @timphsieh-google 's proposal on the native thread WICG/turtledove#265 (comment) to Instream video, it seems quite workable. On this proposal, https://github.com/google/ads-privacy/blob/master/proposals/protected-audience-video/component-seller.md, the coordination problems seem a bit overblown to me, the TLS can publish a spec and component sellers can build to it. Other TLS will likely copy the first mover so sellers don't need to re-implement. There might be an evolution that either SSPs wil need to become player companies or player companies might stand up component selling. I agree with @mkendall07 that the rendering proposal in the native thread is the preferred solution; but the component selling extension here seems quite workable in the meantime.