We would like ecosystem feedback on an initial proposal for instream video support with fenced frames. To summarize, the fenced frame (and its child frames) is responsible for hosting the ad player as well as the ad, including the ad user controls, and the embedding frame is responsible for hosting the content player, the content, and the user controls. This design considers the following high level parts of an instream video ad.

1. Media Player Synchronization: Events needed to be communicated from the content to the ad and vice versa, during the start and end of the ad.
2. Ad video player controls: The controls that allow users to interact with the ad video player, e.g. play, pause, volume change, bitrate change etc.
3. Ads represented as VAST: Wrapping of ad’s VAST source to ensure there is an HTML/JS layer wrapping the buyer’s VAST XML which is responsible for communication with the outer frame and reporting.
4. VAST Tracking events: Reporting of events from within the ad that includes integration with Fenced Frames Ads Reporting (FFAR) for all entities involved, e.g. seller, buyer, component seller..

Media Player Synchronization for initial and final state of the ad

This is about the information that is needed to be communicated between the embedding context and the fenced frame, at the start and end of the ad. The requirement that this solves is that the user expects both content and ad to have the same volume and the bitrate that they selected. We propose 2 events in either direction at the start and end of the ad lifetime. These will need to be severely rate-limited to a small number of bits so as to not communicate arbitrary information to and from the fenced frame.

1. The 1st event will be the initial volume and bitrate that the ad should start with, sent from the embedding frame to the fenced frame.

Sample pseudocode in the embedding frame: fenced_frame_element.setInitialVideoParams(<video_params>);

Inside the fenced frame, this information will only be available if autoplay is granted to that frame via browser’s autoplay rules or if not granted, when the frame gets user activation.

2. The 2nd event will be the final volume and bitrate that the ad ended with, sent from the fenced frame to the embedding frame. This will similarly be rate-limited to a small number of bits.

Sample pseudocode in the fenced frame:

window.fence.notifyEvent(<video_params>);

The parameters will only be allowed to go out if the fenced frame receives a user activation i.e. the user interacted with the ad fenced frame, but the message without any additional data will go out regardless, indicating that the ad has ended.

Ad video player controls

It is our understanding that instream ad videos, in most cases, have the same user controls as the content video. In the fenced frame world we propose that the controls be created separately for the ad inside the ad fenced frame, but additionally have some provisions for the look-and-feel of the controls to be the same as the content video.

To achieve the same look-and-feel we could allow the embedding frame to set an html document for the controls and the ad FF would be responsible to create a nested FF to display the controls. Note that the ad FF only sees an opaque fencedFrameConfig for the nested FF and does not know its actual URL. Being displayed in a nested FF creates a privacy boundary between the ad content FF and the controls FF. The nested control FF would be able to indicate to the ad FF if the user interacted with the controls and the event, e.g. play/pause/volume change etc., via _window.fence.notifyEvent(<video event enum>, <optional event param>) with the enum indicating the event, and each call will be gated on transient user activation. The event param e.g. volume level would be rate-limited to a small number of bits.

Sample pseudocode in the embedding frame to set the controls document:

fenced_frame_element.setNestedFencedFrameConfig(<fenced_frame_config>);

The following diagram summarizes the last 2 sections

Ads represented as VAST

The ad renderURL would be buyer provided as part of the interest group’s renderURL. This also includes the renderURL to contain the HTML/JS player along with the VAST XML,
e.g. https://video-player.com/PA-video-player. html?vast_xml=https://buyer.com/ad1234.xml

VAST Tracking events

Any events that the seller and buyer are interested in tracking about the ad would need to be registered and reported via the FFAR API surface. There are IAB documented events e.g. pages 69-70 for video ads which can help the code calling registerAdBeacon and the ad code calling reportEvent() to use those standardized event names. Note that this assumes VAST extensions enabling Fenced Frame Ads Reporting API tracking as described in an iframe-based proposal here.

We would like to hear feedback on this high level design from the ecosystem. We will also follow up on this issue, diving into more details about the rate-limited events and other design considerations.