Video Ad Tech: Overview

Having understood the participants involved in the ecosystem, the next step in understanding digital video is learning how digital video advertising is executed. This chapter focuses on the “how,” honing in on the video player—digital video’s central character—its role, and the technologies it utilizes. The Video Ad Serving Template (VAST) and the Video Player Ad-Serving Interface Definition (VPAID) are broken down in both technical and practical terms and event tracking and tags are highlighted. Finally, it introduces digital video creative formats and containers, adaptive bitrate support capabilities, as well as iframes and their function. At the end of this chapter you will find further in-depth information on the player, video ad serving requirements and Digital Rights Management (DRM) cross-platform capabilities.

The Player 

At the most basic level, the main technical difference between display advertising and digital video advertising is the player. When the call goes out for a display ad, the publisher’s ad server is looking to find a set of HTML code on the page to insert the ad. Once it finds it, the ad is shown.

Before including the player into the equation, it is important to understand how ad serving works. Ad Ops Insider published this useful overview.

Calling the Publisher Ad Tag 

When a browser navigates to a publisher website (1), the publisher’s web server sends HTML code that (2) tells the browser where to get the content (3) and how to format it. Part of the HTML code returned to the browser (4) will include a coded link known as an ad tag.

Here is a theoretical example of what an ad tag from DoubleClick by Google, one of the major ad serving companies, could look like: 

The ad tag points the browser to the publisher’s ad server, a system designed exclusively for delivering and tracking advertising. In most cases, the publisher’s ad server (5) is a network of cloud servers[16] owned and maintained by a separate company. In the case of the tag shown above, the content server tells the browser to get the ad from DoubleClick. 

The Ad Selection Process 

In many cases the ad server is deciding among thousands of potential ads to deliver to the page in mere milliseconds. The ad server makes a decision, and usually sends back another ad tag (6), or redirects the browser by pointing it to the marketer’s ad server. These are technically 302 redirects, which tells the browser the page has been “temporarily moved.” This allows ad servers to count the 302 call as an impression and serve the actual ad content on a different server. Once the publisher’s ad server sends the browser a redirect to the marketer, it counts a delivered impression in its own reports database.

The only exception here is if the publisher decides to deliver a house ad or the marketer has asked the publisher to “site-serve” the ads, both of which require the publisher to load the actual creative files into their ad server. This indicates the publisher is the final source and destination of the ad, and the browser can skip the loop through the marketer’s ad server (steps 7, 8, 11, 12). 

Read more from Ad Ops Insider about Why Publishers and Marketers Have Their Own Ad Servers

Image files, on the other hand, are kilobytes or even megabytes in size and could be called millions of times a day, requiring a much faster and robust infrastructure. Ad servers might maintain multiple data centers across the world, but a content delivery network (CDN) can distribute delivery, process heavy bandwidth, and deliver the ad content faster. They operate hundreds of data centers and can route requests to the one nearest to the user, no matter where they are. Think of the ad server as the brain and the CDN as the brawn.

Ad servers aren’t the only companies that use CDNs, in fact many websites host their bandwidth intensive files in these cloud networks. A CDN is almost always another independent company, such as Akamai, that hosts the heavy creative assets.

In addition to sending back the redirect to the CDN, the marketer’s ad server also appends a second redirect (10) back to itself with a query string to fetch a 1x1 pixel for tracking (11) after the ad content has been called. When the browser fires this last redirect, calling a 1x1 pixel from the marketer’s ad server, the ad server knows the ad was successfully downloaded and it finally counts an impression in its own database. In many cases, the browser has to make at least four calls for site served ads and six in the case of third-party served ads (if not more) for the process to work. This should not take more than a second, regardless of the number of parties involved.

To visualize the process explained above, please see the Ad Ops Insider diagram in 4.1—302 redirects are highlighted in blue, and the ad creative is highlighted in red

Adding the Player to the Ad Selection Process 

When adding the video player to the ad serving process, a publisher ad server is asked to pull a video asset and show it in a publisher video player as a continuous stream of images and sounds. The player is the interface between the video content and the end user, running the ad and communicating with the page. It also has the ability to pass user data, record engagement information, and coordinate with content on the page to run companion ads. Additionally, the video ad can interact with the video player, ad server, and ad source.

A video ad server will deliver an ad response that has multiple formats for the ad creative. It is important that the video player technology can determine the most appropriate format to play and has the ability to render that ad. The player should choose a creative file size based on the user’s available bandwidth to ensure a quality user experience, especially on mobile. 

While the video ad is playing, the player technology is responsible for requesting tracking pixels to capture impressions served, time spent, and various other important events. Once the ad has finished playing, a video player must be able to seamlessly transition to playing the content the viewer was expecting to see in the first place. This content can be anything from a video stream to a video-on-demand asset that is hosted on a CDN or is syndicated.[17] Just like the ad, the video player requests the content file and makes decisions on the files to be played. When the content ends, a video player can provide recommendations targeted towards the user’s ad preferences. This is usually provided as a service from vendors and can be turned on from a video content management system (CMS), or by adding additional scripts to the page.

Advanced video players are not only able to identify the absence of creative, but can also add an additional layer of optimization that maximizes yield and fill rate. An optimized video player not only reduces the risk of a creative not showing, it also helps to maximize prices, drive publisher revenue growth by improving yield and fill rate update with ‘not showing’, and create an optimization loop. 

Video Ad Server 

An ad server is a web based tool used by publishers, networks, and advertisers to help with ad management, campaign management, and ad trafficking. An ad server also provides reporting on ads served on the website.

There are numerous parties involved in digital video ad serving. Determining whether a party is first, third (or fourth) is based on the technical concept of internet delivery (and not who the party is), or who contracted with the party. First party, third party (and fourth party) essentially refers to the sequential number of internet round trips required to execute all elements of an ad delivery transaction, including calling to ad servers for delivery of creative assets, and calls to measurement providers.

IAB defines third-party ad servers as independent outsourced companies that specialize in managing, maintaining, serving, tracking, and analyzing the results of online ad campaigns. They deliver targeted advertising that can be tailored to a consumer’s declared or predicted characteristics or preferences.

Third-party ad servers can also be used for:

  • Tracking/counting impressions
  • Filtering for GIVT (general invalid traffic)
  • Choosing the appropriate ad content for each site
  • Reporting, verification, and auditing
  • Creative rotation, frequency capping by and sequencing
  • Targeting
  • Optimization

Video Tags: VAST and VPAID 

The video ad serving protocols VAST and VPAID may seem complex at first glance, but they are analogous to something familiar: The original VHS video tape format.

In the early days of video cassette recorders, there were two competing tape formats: VHS and Beta. A Beta cassette was smaller than VHS. Initially, movie companies had to manufacture and distribute two sets of cassettes for each format for the same movie. The bifurcation was expensive, not scalable, and resulted in a fragmented industry. Ultimately, the consumer electronics and film industries picked one format as the standard: VHS (Video Home System). 

The advertising and media industries faced a similarly fragmented landscape for the delivery of digital video content. Initially, publishers created their own custom implementations for video content and ad serving, making it un-scalable and expensive for advertisers. The industry needed a “create once, run everywhere” solution. In response, IAB developed a standard template for video players with protocols guiding actions when an ad is received and after the ad is played. VAST (Video Ad Serving Template) and VPAID (Video Player-Ad Interface Definition) advance the video advertising ecosystem by providing a standard interface between video players and ad units.

VAST, is a standard protocol or set of XML code used by advertisers to instruct their ads how to work with any VAST-compliant video player.

DVD was the next step in video playback standards, enabling users to skip different chapters, access bonus features, turn on subtitles, and change language settings. This is analogous to functionality added by VPAID, or Video Player Ad Interface Definition. Advertisers can, through standard VPAID functionality, program interactive features into ads, such as sharing ads through social media channels, enabling user registration within the video ad, inserting a survey, and more. Just as in VHS, where it wasn’t able to handle interactivity as DVDs were, VAST too was not equipped to handle the more complex communication with the video player. Therefore, IAB built upon VAST to create a standard called VPAID that supports greater interactivity.

Layering VPAID onto VAST offers an enhanced solution. It enables the executable ad unit to expect and rely upon a common set of interactive functionalities from the video player. This is significant as advertisers using VPAID ads can provide rich ad experiences for viewers and collect ad playback and interaction details that are just as rich as the ad experience. With VAST and VPAID both being utilized widely, it is common to assume that a video player is both VAST and VPAID compliant. The reality is most players are VAST compliant and some are also VPAID compliant, but it is not safe to assume that every VAST compliant player also supports VPAID, especially in the mobile world. Broadly speaking when an ad request is made from a video player for a video ad, information about which protocols are supported are passed with the ad request, informing advertisers of the type of ad the player can support. Without this information, the assumption is that the video player does not support VAST or VPAID.

It is important that advertisers understand the requirements of the standards to which they’re building creative assets as it impacts the potential audience they can reach. Simply put, in the same way that video playback standards have evolved from the early days of VHS to support greater interactivity and scale, so too have VAST and VPAID standards, supporting more complex forms of video advertising and engagement.

Evolution of IAB Video Standards 

Video advertisers have two important execution goals for the delivery of their video ad campaigns: to provide viewers with a rich ad experience, and to capture ad playback and user-interaction details that report on the viewed ad experience. To achieve these goals in a world without common video player functionality, advertisers would have to develop multiple specialized versions of their ad creative for every unique video player—an expensive proposition that doesn’t scale well.

VAST kick-started an industry-wide standard solution to these issues in 2008, and IAB has since released several new versions of VAST, VPAID, VMAP, OpenRTB and DAAST

The latest update to the VAST standard was VAST 4.0, released in 2016, aims to ensure smooth communication between video players and ad servers by making multiple improvements in delivery and measurement. A list of the main updates and challenges are summarized on the adjacent graphic.

VAST 4.0 enables advertisers to send variants of a creative file, from high quality mezzanine files (viewable by high-resolution TV screens) to standard MP4 and interactive (VPAID) ads. With this update the video creative file is handled separately from the interactive API (Application Programming Interface) file, so publishers across multiple platforms can now choose the right format of ad on the fly to deliver to the right device and application. 

The focus of this new update has been on improving the quality of video ads by adding support for features like Server Side Ad Insertion, Mezzanine file support, and “UniversalAdId,” which is used to provide a unique creative identifier that is maintained and tracked across all systems. As part of the VAST 4.0 requirement for the UniversalAdId, Ad-ID is considered the registration authority for advertising in the United States.

Using the UniversalAdId feature as the creative identifier ensures that an individual video ad will have a single unique identifier across publishers and campaigns. Having a unique identifier creates efficiencies in workflows and allows the creative to be consistently tracked by enabling all data associated with the creative to follow it across systems. Tracking the creative streamlines data collection and provides more accurate reporting and “real-time” measurement when running cross-platform campaigns. The UniversalAdId can also be used for identifying and tracking ads in ad-stitching processes.

To find out more about Ad-ID please go to the following link.

For a list of the benefits of using Ad-ID for advertisers, agencies, media and vendors, please access the following link.

With VPAID, IAB aims to address the following market inefficiencies for publishers, advertisers, and vendors:

  • Increase common video ad supply technology so that video publishers can readily accept video ad serving from agency ad servers and networks.

  • Provide common technology specifications for advertisers to develop against, decrease the cost of creative production and increase business ROI.

  • Improve video ad supply liquidity as cost of integration decreases.

VPAID was originally developed to support interactivity in video ads but its use has evolved, and there have been issues with complexity. VPAID 3.0 is therefore being developed to provide better separation of media files from interactive creative and verification/viewability code, reducing implementation complexity while offering enhanced OTT/Smart TV support.

The Digital Video Technical Working Group within IAB Tech Lab is currently working on updates to VAST and VPAID. IAB Tech Lab members who would like to participate in the working groups should contact [email protected]. For those interested in the latest on VAST/VPAID, please visit the recently recorded webinar: “VAST4 and Server Side Ad Insertion—Technology and Best Practices.

To learn more about VAST & VPAID, please watch this short video on understanding IAB Digital Video Suite. Additional IAB Tech Lab resources of note for this section include: 

The below table summarizes V-Suite functionality and the evolution of the standards:

This timeline shows the evolution of IAB video standards:

Video Player Technologies 

Until relatively recently, the predominant way to decode and render streamed or downloaded video files on the web was through a browser plugin (Flash player). Adobe released the first version of its Flash player in 1997. There were other web-based players, but they required a full-blown software installation. The Flash player was both easy to install by the user, and frequently came pre-installed with browsers.

The emergence and penetration of mobile quickly flagged a need for an alternative: the HTML5 player. HTML5 offers critical benefits, studies show that on average, a Flash video will take up 17 percent more battery life than HTML5 video on a desktop and 12 percent more on a tablet. HTML5 is supported on all mobile devices, while Flash is not. Developers prefer HTML5 since it does not have as many versions as Flash, and HTML5 allows for better user experience since it does not require the user to install a video player plugin. The HTML5 player comes as a native part of standard HTML code that the browser understands. Finally, unlike Flash, HTML5 technology utilizes the ubiquitous JavaScript scripting language.

So why is Flash still present? The Flash browser plug-in technology was released by Adobe in 1997, and was widely adopted long before work on the HTML5 standard had begun. While changes in technology are continuous (and often rapid), industries move more slowly, and so while HTML5 support for video within the browser has been available as a replacement for Flash for a while, some companies and agencies are still producing creative using Flash (despite the fact that browsers not longer support Flash). For the sake of the consumer experience, it’s time everyone in the ecosystem stops using Flash and migrates to HTML5. Transitioning to another video player technology would mean requiring the conversion of millions of websites. HTML5 also allows video ads to be streamed in connected TV/Smart TV with built-in browser capabilities, while Flash doesn’t. Flash only supports flash proprietary video formats (.flv and .f4v). HTML5 supports multiple video formats including popular formats such as mp4.

The following table provides a comparison of Flash and HTML5 technologies:

Technology Support

All of the major browser vendors have been announcing plans to restrict the use of Flash, and replace it with HTML5 as the default media playback option. Some of the changes announced have a direct impact on video ads and will require the video advertising community to move from Flash to HTML5/JS based technologies.

IAB Tech Lab has been working with members of the Digital Video Technical Working Group to determine the best approach for publishers and agencies to orchestrate this transition.

References to Flash in all IAB technical standards and guidelines (including VAST, VPAID, OpenRTB, Ad format guidelines) should be considered as “deprecated” as of January 2017. The goal has been the complete elimination of Flash video ads by July 2017. IAB has released checklists for agencies and publishers on how to transition to HTML5


Captions and accessibility for the hard of hearing are an important aspect of player technologies, especially with regard to publishers or broadcasters who need to be FCC (Federal Communications Commission) compliant. The basic formats are WebVTT, SRT, and DFXP. It’s also useful to know that captions can be used as separate text files and can be included in an HLS (Adaptive Bitrate) manifest. 608 and 708 caption formats are also relevant, as they were/are standards for TV broadcasts.

To learn more about captions, visit Adobe’s “Introduction to Closed Captions.

Digital Rights Management 

Digital rights management (DRM) is a systematic approach to copyright protection for digital media. The purpose of DRM is to prevent unauthorized redistribution of digital media and restrict the ways consumers can copy content they’ve purchased. DRM products were developed in response to the rapid increase in online piracy of commercially marketed material, which proliferated through the widespread use of peer-to-peer file exchange programs. Typically, DRM is implemented by embedding code that prevents copying, specifies a time period in which the content can be accessed or limits the number of devices the media can be installed on. DRM helps you protect your content. Some DRM providers of note are Apple FairPlay, Microsoft PlayReady, Google Widevine, the open Clear Key standard, and AES 128-bit encryption.

Event Tracking 

Improved user experience and effective targeting enabled through the use of data are critical qualities in an optimized ad campaign. In order to acquire reliable analytics on all activity generated by a campaign, event tracking is implemented. This table shows the commonly tracked events that appear either directly in the ad server, or third-party analytics tools. Some of these are specified and others are events that are fired by a rich-media (VPAID) creative itself.

User session related metrics (such as video view quartile tracking) is slowly beginning to take precedence over click-through rate (CTR) as one of the most valued metrics. Instead of simply tracking clicks on the ad, session based duration metrics measure the amount of user engagement generated by the impression.

While CTR is a performance metric that represents a clear one-to-one relationship between the ad being viewed and action being taken, engagement is becoming more desirable to advertisers in some cases as a way to assess their branding, and forge new relationships and connections with their audience.

The number of trackable events continues to grow as clients demand more ways to assess the effectiveness of their campaigns. Some more custom metrics are valuable to certain clients such as downloads, number of shares of a video, scroll tracking, conversions to a purchase, and number of interactions with a VPAID ad.

VAST Error Guide 

Spearheaded by Rubicon project, together with JW Player, Brightcove, Radium One, The Trade Desk, publishers, and other DSPs, this group has put together a video creative troubleshooting guide. The goal is to create a repository to help solve the many video creative issues that plague the industry.

To access the VAST error guide, please visit IAB Tech Lab’s Video Tech FAQs. If you are interested in joining IAB Digital Video Technical task force, please contact Amit Shetty at [email protected]

Digital Video Container Format/Creative Format 

Have you ever heard of rich media creative format, media files, video container format or streaming protocols and wondered what they were? Another important decision in the life cycle of a video ad is format: rich or non-rich media?

Rich Media 

Rich Media Creative formats: VPAID-js (.js) / MRAID (.js) / VPAID-flash (.swf) are like giving an artist a blank canvas and telling them to paint it however they want using whatever they want. They could even paint a different picture for each user or interact with the user in other ways. If a creative is not rich media and there is nothing dynamic about the playback, the player will show every user the same thing.

Rich Media Creative format capabilities depend upon a player supporting their technologies. If the player doesn’t support VPAID or MRAID, it cannot play the files.

VPAID-js (.js) and MRAID (.js) require HTML5, whereas VPAID-flash (.swf) requires Flash.

Media Files

  • (.js) Similar to .swf, this is a JavaScript file. This is the <media> type used for VPAID-js.

  • (.swf) Is a Flash video file format. It contains additional Flash scripting logic that can allow the file to render its own player and take its own measurements. A normal industry player just loads it up and calls play() on it. These files are typically VPAID-enabled wrappers, but don’t have to be. Despite the fact that Flash video file format will no longer be supported, advertisers continue to send flash video creative, risking the ad not being executed on desktop or mobile.

With the migration to HTML5 .js VPAID will likely completely replace .swf VPAID. Google provides additional details on Interactive Media Ads (IMA) Flash Software Development Kit (SDK) Version 3.
On June 1, 2017, Google ceased support for the IMA SDK for Flash and Flash VPAID ads in the HTML5 SDK. We strongly encourage all publishers using the Flash SDK to migrate to the HTML5 SDK. We also strongly encourage advertisers trafficking Flash VPAID ads to migrate those ads to JavaScript VPAID. 

Non-Rich Media 

Non-rich media creative formats (solely video with no extra logic or functionality):

  • Streaming Protocol (how the video is transmitted): HDS, HLS, MPEG-DASH, RTMP

  • Streaming Protocols are often handled by the internal ActionScript or JavaScript of the player (developed by the player’s author), although in some cases Streaming Protocols can be handled directly by Flash or the browser (ex. MPEG-DASH)

  • Non-streamed plain files over HTTP

  • Video Container Format: The envelope and packaging that holds the video and audio when transmitted

  • Examples: .flv, .mp4, .wmv, .mov, .webm

    • (.flv): is the container format used by Flash, like .mp4

    • (.mp4): Type code: MPG4, File extension: mp4 is the container format used to store video

    • (.wmv): Type code: ASF is Microsoft’s advanced systems format; video container format for streaming

    • (.mov): Type code: MOOV is a multimedia file format for Apple’s QuickTime

    • (.webm): Open graph video codec

For all videos (streamed and otherwise):

  • Video Codec is the compression and encoding of the video; the “language” the video is written in:

    Sorenson Spark, On2 VP6/VP7/VP8, Google VP9, MPEG-4 H.263/H.264

  • Audio Codec is the compression and encoding of the audio; the “language” the audio is written in: AAC, MP3, Vorbis

  • Video Container Formats and Video/Audio Codecs must either be supported by Flash or the browser to play

Here is a snippet from a VPAID-enabled VAST response showing the .js response type returned and .js response types returned (not based on real links). Most VAST responses in the industry today follow a similar format:

      <MediaFile delivery=”progressive” width=”400” height=”300” type=”application/javascript” apiFramework=”VPAID”>
        <![CDATA[]]> </MediaFile>

A player that supports VPAID will ‘in principle’ select either the .js or the .swf based upon whether or not Flash is installed or if the player prefers one type over the other. This is the ideal goal but is not guaranteed. After it loads the appropriate file, it calls the VPAID unit method handshakeVersion () to determine the VPAID protocol version to use.

Both the player and the media file determine the highest version they both support, then use the VPAID interface to call back and forth to one-another to play a creative. Media format support is determined by the player at runtime based upon the browser/native device’s installed plugins or built-in media. As such, it’s not consistent even from one device to the next.

It’s worth noting that a VPAID-enabled creative does not, itself, have to play a video file. The VPAID creative could just be a wrapper with additional logic to make more VAST calls and load more VPAID wrappers until eventually a wrapper plays a creative. You can end up loading several VPAID wrappers before getting a creative. Each wrapper is likely doing its own waterfall or bidding scheme to select what to play and what not to play. Each of these layers of wrappers takes a lot of time and network bandwidth, resulting in latency and high abandonment rates, which result in wasted impressions for the publisher and a poor user experience.

For more information on HTML5 codec/container support by browser, visit MDN’s “Media formats supported by the HTML audio and video elements.” 

Adaptive Bitrate Support 

Adaptive streaming is a technical process that adjusts the quality of a video delivered to the client/video player of a connected device based on changing network conditions, video buffer status, and CPU utilization to ensure the best possible viewer experience. The video quality is determined and set by real time detections of a user’s available bandwidth (throughput), video buffer capacity and CPU utilization. Based on these conditions the bit rate is adjusted in real time to ensure the best possible quality.

A simplistic example: “When you watch a movie that is streaming from your mobile device while travelling by train, network conditions are changing all the time. In order to ensure the best user experience, buffering and adaptive bitrate streaming occur.”

How? Adaptive bitrate streaming splits a video into multiple, separate video files with different bandwidth requirements and provides the ability to switch seamlessly between those different files during playback. Normally, without adaptive bitrate streaming, when network congestion occurs and the video file cannot be delivered as quickly as is required to play it, playback of that video will work off of a buffer of the video that had been pre-loaded. When this buffer runs out, the player will pause while the player pre-loads a new “buffer” of content from which to play. With adaptive bitrate streaming, the player can start requesting a different video segment with either higher or lower bandwidth requirements to match conditions. This can avoid a rebuffering condition. However, it is important to note that a rebuffering interruption can still occur even with adaptive bitrate streaming. For example, if the network drops out entirely (such as the train going through a tunnel) or if the network is slower than the lowest bitrate file that was encoded rebuffering will still occur.

Adaptive bitrate streaming enables the quality of the video to adjust on-the-fly without the interruption of having to pause the video and rebuffer a new video at a different quality. 


An inline frame—more commonly known as an iFrame—is an HTML document embedded inside another HTML document, like creating a box full of HTML code as its own compartment within a webpage.

Why are iFrames used?

Both publishers and advertisers may choose to have content served into an iFrame to avoid disruptive behavior and potential security risks in serving ads and other third-party content in line with the page. Using an iFrame ensures that elements such as CSS styles[19] and JavaScript libraries of different versions don’t interfere with those being utilized by the ad. This prevents a collision between advertiser code and publisher code.

Depending upon the type of iFrame that is used, content can be completely sequestered within
the iFrame and be unable to access information about the main HTML document within which it is embedded. This prevents an ad from doing things like expanding over the content of the page without permission, but it can also prevent the ad from interacting with the user in dynamic ways. Since this happens on both sides, the main publisher page is also prevented from accessing information inside the iFrame and the ad content within the iFrame cannot expand outside its borders, move around the page or slide into and out of view from the bottom of the page. This can also prevent collection of data that might be necessary to determine ad effectiveness, such as viewability.

Why do iFrames come into play even more with video?

Video represents some of the most complex interactivity on a webpage. Therefore, to isolate each component as much as possible to simplify its implementation and maintenance, video is sometimes placed within an iFrame. Additionally, when rich media video advertisements are involved, such as VPAID or MRAID, the entire player may be wrapped within an iFrame to sequester any third-party code an advertisement may execute.

Types of iFrames

IAB defines two different types of iFrames: “Friendly IFrame” (FIF) and “SafeFrame.” A FIF is typically used as a simple container in which to push HTML. A FIF allows full access to the parent page’s code. This type of usage is only recommended where the publisher trusts the advertiser and vice-versa.

A SafeFrame is different in that it loads the frame’s content from a URL at a different domain from the parent page. This is referred to as “cross-domain iframe.” Doing this makes the browser block access to the parent page by the code in the frame. Likewise, it blocks the parent page from accessing the frame’s code.

Additionally, a technology called cross-document messaging allows both the parent page and the SafeFrame’s code to communicate on a limited basis. Without the SafeFrame specification, a standard cross-domain iFrame has no communication. 

The Player 


Home-Built vs. Third-Party Video Player Companies 

Players can be home-built by digital content providers (i.e. Hulu) or provided by third party companies such as Brightcove, JW Player, and Ooyala. In both cases, the player provides the controls for the consumer to manage the video experience (i.e. play/pause, full screen, closed captions, etc.). It also must make run-time decisions about the environment it sits within (i.e. web vs. mobile browser, mobile apps, smart TVs), and determine what’s possible and optimal given the capabilities or limitations of any given environment (i.e. small screen size, Flash is disabled, device is Dolby 5.1 audio capable).

The player must then render the video content the best it can, performing an ongoing balance of providing the best video quality possible for a given (and often changing) network connection speed (adaptive bitrate streaming) without forcing the viewer to wait (video buffering). Finally, it must seamlessly fetch and serve ads when and where desired by the content publisher, typically as pre-roll, mid-roll and/or post-roll videos. 

Player Impact on Ad Playback 

When it comes to actually displaying an ad, several variables are taken into account. Standard VAST linear ads interrupt content playback.

Interactive Media Ads (IMA) HTML5 SDK renders VPAID creatives in a cross-domain iFrame by default, which limits VPAID creatives access to the page DOM. As a result, some creatives may not work properly. Most VPAID ads expect friendly iframe access to the page DOM in order to work properly.

Additionally, the IMA SDK team calls out standard vs. custom ad playback and the pros and cons of each in a recent blog post

Standard Rendering 

If you’re using the HTML5 SDK you probably have a web page playing your content in a <video> element. In standard rendering, the SDK will create another <video> element and render it in the ad display container you provided, which should be placed on top of your video player.

The ads will then play in this SDK-owned video player on top of your content player. To the user, it looks like one video player switching from content to an ad, but in reality it’s another video player appearing on top of your content to play an ad and then disappearing. The main benefit to this standard rendering involves buffering. Using a separate video player to render ads allows us to preserve your content buffer while ads are playing. If you’re playing a pre-roll, you can start loading your content when the ad starts and buffer the content the whole time the ad is playing. For mid-rolls, the separate player allows you to preserve your content buffer while ads are playing; if your viewer has buffered ten minutes of your content, and you play an ad at the five-minute mark, they won’t lose the content in the buffer for 00:05:00-00:10:00. 

Custom Ad Playback 

Per Google, the recommendation is to always pass your content video element as the custom playback element. The HTML5 SDK will intelligently use custom ad playback only when it deems necessary, as described below. When it’s not necessary, it will use standard ad playback.

When the SDK decides to use custom playback mode, it renders video ads in the same player as
your content. This means you lose the buffer-related benefits of standard rendering. If your viewer has buffered 10 minutes of your content, and you play an ad at the 5-minute mark, they will lose the content in the buffer beyond the ad. Certain ad formats (such as AdSense) require an SDK-owned player and can’t play in your content player.

So then why use custom ad playback? Simply put, some platforms do not support multiple, simultaneous, active video elements. On those platforms, the SDK can’t create its own ad player because the one allotted video player slot per page is already occupied by your content player. If the SDK tries to play an ad in a second video player, it will either fail to play (freezing the player) or make it impossible for the content to restart after the ad is finished (again freezing the player). Thus we must show the ad and video content in the same player. Custom ad playback is sometimes referred to as single player ad-serving.

For client-side ad insertion (CSAI), single-player opportunities typically exist where the content publisher also controls the ad inventory all within a common infrastructure. This provides more direct-control of the end-to-end consumer viewing experience by a single entity, reducing a lot of the variables that can impact the viewing experience quality related to ads. The ads and main content can operate through a common CDN. The ads can be processed and streamed in identical formats compared to the main content, and there are fewer network hops and less run-time logic compared to automated ad scenarios.

Another single-player scenario is with server-side ad insertion (SSAI). With SSAI, the ads are stitched into the same stream as the main content, and continuously played through by a common player. There’s no need for the player to pause and either hand-off playback to another player for ads or switch streams in the single-player CSAI scenario. SSAI has the significant advantage in that it’s impervious to ad blockers (the main video content and ads look the same to ad blockers), and there are few variables that can degrade the user-experience during ad transitions. SSAI can also be particularly attractive in low- bandwidth environments such as 2G or 3G mobile networks, as it can achieve much higher fill-rates due to eliminating ad timeouts commonly seen with CSAI under these environmental conditions. The downside of SSAI includes limitations on supported ad formats (e.g. SSAI typically cannot support interactive ad formats, such as VPAID) and that ad analytics are built around CSAI and don’t work as well with SSAI. 

Ad Playback Capabilities and Limitations 

Because of the different technologies involved with browsers, video players and ad creatives, certain combinations can’t be supported. For example, given VPAID ads’ interaction with the player, Flash (.swf) VPAIDs typically don’t work with HTML5 players.

Workarounds exist, such as the above-mentioned IMA situation where a second video player is layered on top of the base player. This allows the primary player to be HTML5 with the player on top to use Flash and successfully play a Flash VPAID, including use of the interactive functionality.

Latency can also impact ad playback. Latency is the delay between request and display of content and an ad. Latency sometimes leads to the user leaving the site prior to the opportunity to see. In streaming media, latency can create stream degradation if it causes the packets—which must be received and played in order—to arrive out of order. Typically, the balance between latency, time to first frame, ad timeouts, and other functionality on the page including tracking and analytics is one that anyone employing a video player with ads must focus on to ensure optimal viewer experience. Lightweight and otherwise performance-focused players aim to ensure ad playback is not impacted by these other variables.

Ad pods are another scenario where the player can impact ad playback. When electing to play a
Pod of ads returned by the ad server, the video player should play the ads in the Pod in
the prescribed sequence and should play as many of the ads as possible. The player may elect not to play all of the ads (truncating the Pod from the end) if either, the ads cannot be played because they cannot physically fit into the stream (such as when time is limited in a live stream) or if the entire Pod of ads returned by the ad server violated any limits specified by the calling video player (i.e. number of ads to return, or maximum Pod duration). When an Ad Pod is the result of following a VAST <Wrapper> the same impression and tracking Uniform Resource Identifiers (URIs) in the VAST <Wrapper> are called as each ad is played in the pod. Should an ad in a pod fail to play after a “no ad” response from a secondary ad server, the video player should substitute an unplayed standalone ad from the response. See section of the VAST spec for further details on a “no ad” response. 

Video Ad Server: Minimum Recommended Requirements 

When selecting an ad server, we recommend that you have these minimum requirements: 

  • MRC accreditation

  • Ability to support all IAB recommended tag types (VAST, VPAID, etc.)

  • Easy integration with your video player, or ability to create integration

  • Support IAB specifications for ad units (including companion ads) per the guidelines issued in IAB New Ad Portfolio

  • Be able to deliver across multiple platforms (mobile, desktop, etc.) with on-the-fly transcoding to customize video assets to inventory requirements

Ideally, your ad server should also be able to offer customizable and near real-time reports that are easy to read, include geo-targeting capabilities, thorough vetting of the vendors they serve, and allow for flexible setups to customize across sites. 

Digital Rights Management (DRM) Cross-Platform Capabilities 

Planning for cross-platform compatibility is a mission-critical sill in digital video advertising. If your video use case requires DRM and you know the budget and time investment involved, understanding the support in various browsers is critical. Most DRM technologies are proprietary and are only supported on Original Equipment Manufacturer (OEM)-specific products. For example, Apple FairPlay is only compatible with Apple’s Safari web browser and other Apple products. 

Here is a list of DRM technologies that are supported and which browsers support them (used with permission from JW Player).

1: The Nielsen Company, Monitor Plus (Standard Calendar, Total includes B2B, National Internet (Display only), FSI Coupons), Oct. 2016
2: IAB/PwC 2016 Internet Advertising Revenue Report
3: To view the Top 10 Video Content Properties by Unique Viewers, see comScore’s monthly release of their Video metrix data.
4: Business Insider: “The US Digital Media Ad Revenue Report: The path to $100 billion in annual revenue by 2021.”
5: IAB/PwC 2016 Ad Revenue Report
6: Business Insider: “5 video advertising trends that will change your business.”
7: PwC: “2017-2021 Global Entertainment and Media Outlook.”
8: Forrester Research, 2016
9: Pathak, S. (2017). “Why digital advertising is experimenting with blockchain.” Digiday, 4 Apr 2017
10: Gross Rating Point: Measured by the % of households that tune into to a particular show or network and have the opportunity to see an ad.
11: Reach: Represents the total number of people exposed to the media plan or ad over a certain time period, based on the total size of the target audience.
12: Frequency: Is a measure of media repetition.
13: IAB’s Digital Video In-Stream Ad Format Guideline.
14: IAB Deep-Dive on In-Feed Ad Units: A Supplement to the IAB Native Advertising Playbook
15: Herrmann, J. & Isaac, M. (2016). “The Online Video View: We Can Count It, but Can We Count on It?” The New York Times, 2 Oct 2016
16: Cloud Servers: A cloud server is a logical server that is built, hosted and delivered through a cloud computing platform over the internet. Cloud servers possess and exhibit similar capabilities and functionality to a typical server but are accessed remotely from a cloud service provider.
17: Syndication is a term that is used in both print and broadcast media. It indicates content that for instance is purchased for use by a local newspaper, TV, or radio station. It is not produced by the media company’s owner but through an outside source.
18: XML: Extensible Markup Language (XML) defines a set of rules for encoding documents in a format that is both human/machine-readable
19: CSS: is the language for describing the presentation of Web pages, including colors, layout, and fonts. It allows one to adapt the presentation to different types of devices, such as large screens, small screens, or printers. CSS is independent of HTML and can be used with any XML-based markup language
20: Audience segments are subsets of user data signifying specific facts, interests and other attributes. Audience segments, and the techniques
21: URI is a string of characters used to identify a resource. Such identification enables interaction with representations of the resource over a network using specific protocols. Schemes specifying a concrete syntax and associated protocols define each URI. The most common form of URI is the Uniform Resource Locator (URL), frequently referred to informally as a web address.
22: Making Measurement Make Sense (3MS) is a cross-industry initiative founded by the American Association of Advertising Agencies (4A’s), the Association of National Advertisers (ANA), and Interactive Advertising Bureau (IAB). The Media Rating Council (MRC), an independent body, is responsible for setting and implementing measurement standards.
23: IAS 2016 year-end survey results
24: An “affiliate” is an entity that controls, is controlled by, or is under common control with another entity. Control of an entity means that one entity (1) has significant common ownership or operational control over the other, or (2) can exercise a controlling influence over the management or policies of the other entity. In addition, for an entity to be under the control of another—and thus be treated as first party under these entity’s policies.Principles—that entity must adhere to online behavioral advertising policies that are not materially inconsistent with the other
25: Deloitte. “2015 Global Mobile Consumer Survey: US Edition. The rise of the always-connected consumer.”
26: Mobile Spearheads Digital Video Advertising’s Growth.” eMarketer, 22 Feb 2016.
27: comScore Inc., Nielsen, and ZenithOptimedia
28: Nielsen Q2 2016 Comparable Metrics report.
29: Q2 2016 Comparable Metrics report.
30: AARP.
31: Nielsen Q2 2016 Comparable Metrics report.
32: Mobile Spearheads Digital Video Advertising’s Growth.
33: ANA reports 7.2B lost in Ad fraud
34: Snapchat internal data
35: The continued evolution of enhanced mobile experiences that overlay digital information on top of the physical world
36: Duffy, F. (2017). “Turner Takes on eSports in a Big Way.” NCTA Platform, 6 Jan 2017.
37: The waterfall model is a sequential process in which progress is seen as flowing steadily downwards (like a waterfall) through the various phases, in this case, the potential demand sources or buyers
38: IAB Programmatic Revenue Report 2014 Results. July 2015
39: IAB Transparency is the Key to Programmatic Success
40: WTF is header bidding?
41: Thomvest ventures
42: Programmatic TV definition per IDC
43: Lotame Bridge the TV ad gap & PWC Media forecast 2015, agency reports, front row advisory analysis
44: eMarketer More OTT Time Means More Ad Time
45: eMarketer’s Connected TV and Over-the-Top Video: The Living Room’s Place in the US Digital Video Ecosystem report.
46: Frank N. Magid Associates study
47: comScore 2016 U.S. Cross Platform Future in Focus report.
48: Nielsen’s first-quarter 2016 Total Audience Report.
49: Adobe U.S. Digital Video Benchmark 2Q15; adobe primetime; TV connected devices=apple TV, Roku, gaming console, amazon fire TV,smart TV, other
50: Based on 2016 total viewers Broadcast - Source: Nielsen. Prime time total viewers, Live+7; Broadcast data: 12/28/15-12/4/16
51: Based on 2016 total viewers Cable - Source: Nielsen; Live+SD numbers from 12/28/2015-12/18/2016
52: Based on 2016 TV household coverage. Networks supplied coverage percentages, except for Create TV, which came from Across Platforms consltancy
53: IDC
54: Video Landscape Report
55: IAB TV 20/20 Webinar, 2016. Videology % estimates from Nielsen, eMarketer trend data; Time spent data calculated by Videology from Nielsen and KPCB data. Highest rated programs based on Nielsen A18-49 Live+7 data.
56: “2016 U.S. Cross-Platform Future in Focus,” comScore
57: IAB Digital Video Landscape report
58: Any Given Minute Comparable Metrics Report, VAB 2016
59: IAB: The Programmatic Supply Chain: Deconstructing the Anatomy of a Programmatic CPM)
60: Ghostery, Inc. Interview with Ghostery CEO Scott Meyer. IAB Annual Leadership Conference. January 26, 2016.
61: IAB/EY Study released on Dec-15. Estimates are for the U.S. Market only. Industry-wide collaboration under the auspices of TAG is needed in order to forestall these criminal activities