New VAST Macros Proposal: Continuous Play

[JohnRossDV]

The industry seeks to better differentiate between valid binge behavior and endless back-to-back ads with no viewers. This is particularly sensitive in lean-back environments such as CTV where a streaming device may be active while the screen is turned off or in another input.

Identifying this behavior has specifically been a part of the IAB Digital Video Impression Measurement Guidelines since 2018: “...to the extent that the video content itself (inclusive of advertising) is played without user interaction (Continuous Play) this should be disclosed to users of measurement data including disclosure of the parameters and settings to the extent known by measurement organizations“. Link to this language: http://mediaratingcouncil.org/Digital%20Video%20Served%20Impression%20Measurement%20Guidelines%20(MMTF%20June%202018).pdf

To help identify environments where ads may play endlessly without users present, DoubleVerify proposes two self-declared identifiers for passing seconds since the user last interacted with an environment and whether the environment autoplays content without user interaction.

There are two proposed macros:

1. TIMESINCEINTERACTION: The time since the user last interacted with the device or app controls. This includes any user interaction with the environment including opening the app, clicking to play a video, muting, and pausing. Any interaction that a user directly drives should be counted. Any automatic functions should not be counted - e.g. auto play of a video.

2. CONTINUOUSPLAY: Identifies if an environment is set to play additional videos automatically without user interaction after the end of the current video.

Please see the attached document for further details on these macros.

DVContinuous Play Proposal Aug 2020.pdf

[graphicdeveloper]

I can offer a few immediate observations to get the ball rolling on this...

1) I think it would be helpful to include the full text of the proposal here in GitHub, if possible, just to minimize friction to getting further feedback from the community herein (yes, opening a PDF is just 1 more click, but we all know that each extra click counts!) ;-)

2) While I support both of these macros in philosophic principle, it needs to be considered that honest data for each will reflect a decreasingly-engaged user as session time increases (thus a less valuable user). It just raises the risk of a video player's incentive to report dishonest values rather than devalue their impressions (thus, is no data better than fudged data? Are these macros we will be able to rely on outside of our own internal use thereof?)

3) I think [TIMESINCEENGAGED] needs a clear definition of what qualifies as engagement. Further, how do we know if a user is actually engaged (watching a video with focused attention, say, on CTV from their couch)? The intent of this really seems to be about interaction (volume change, pause, etc.) – so maybe it should be changed to [TIMESINCEINTERACTION]?

4) I think [CONTINUOUSPLAY] is a bit simplified vs. real world use cases to which it might apply. For example: 4A) A video is a one-off on any given video site, and when it ends the site auto-recommends a related video after N seconds. We see this in many popular video sites, and it's the obvious use case with a simple TRUE/FALSE value. ...But... 4B) What if a video is the first or last video in a discreet playlist (watchlist)? Does the first video get a TRUE value if a click was required to start the video? Does the last video get a TRUE value if nothing further plays after the playlist ends?

I think either clarification is needed for edge cases, or perhaps a slightly different macro with an enum list of possible universal values would be better (a list which could epxand as new use cases arise). Just an initial idea might be: [PLAYBACKCONTEXT] : one of [ USER_SELECTION, AUTOSTART_RECOMMENDATION, AUTOSTART_PLAYLIST, etc... ]. That value combined with the other macros may give us a more complete picture of what's actually going on with the user. I don't claim that this is a complete idea, just examples to think about.

[JohnRossDV]

Hey @graphicdeveloper - Thanks for the review and the great feedback!

Responding to each piece here: 1: I've updated the original body to include more info. The PDF still has extra table info since I couldn't get that in here. 2: Understood on your concern here. Autoplay or binge behavior isn't really a less valuable user/environment though - it's an expectation in CTV that the environment is setup as such. I imagine the guideline is trying to get at more of the edge cases where an environment is playing ads for 24+ hours with no user behind it. On the dishonest values part - we're pretty much all as an industry at risk of that occurring with any data point for better or worse. And as with the other macros, these are all optional. 3: Completely agree with you there - I've updated the proposal to TIMESINCEINTERACTION and tried to nail down the definition to be more precise. 4: Great point across these! In fact, we're going to re-approach the MRC on this particular macro as we'd like additional advice to make sure an approach like what you're mentioning would work with their guidance. For reference, here is the section in the guidance that refers to Continuous Play

[7tonrobot]

Looking at how the information in these macros can be passed through the AdCom standard. Continuous Play is a boolean and seems like it should be a property of the Video Object. Time Since Interaction seems like it should be a property of the Device Object.

I can't find any examples of information representing time that has passed in the format 00:00:00 in AdCom (it's mostly used for a timestamp) but I do see time in seconds in a few places. We have the MediaPlayhead macro for VAST which is using that format as well. Is there a reason not to use it in AdCom?