Bullets to rocketscience
Online video advertising used to be reasonably straight-forward – Load, aim at the target and fire!
Your video ad could be loaded into the ad server (a server that was typically designed to deliver banner ads, but now, instead of a JPEG you put in a .flv video file or .mp4); the targeted websites were programmed in and pulling the trigger put the campaign live.
On the publisher’s website, the Flash player loaded and played through the preroll ad (firing off tracking events as it did so, every quarter of the video – ‘quartiles’) and then the main programme video started seamlessly.
At certain points in a longer video programme, the Flash player paused the main programme and played back a midroll video ad.
Clicking on the ads (a clickthrough) took you to the advertiser’s website.
And then the universe became more complicated, with Apple’s iOS ; HTML5 and Android …. It’s now no longer as simple as firing a gun …
Now it’s almost rocket science.
The aim of this article is to outline the current state of play in online video advertising – what can you do and what can’t you do, when it comes to delivering to multiple devices.
Understanding video players, codecs and HTML5
There are 3 types of players, by function:
i) Plug-ins e.g. Flash Player, Silverlight
ii) Browser’s own HTML5 player e.g. Chrome’s HTML5 player (not so much a stand-alone player, as part of the browser that implements the <video> element in HTML5)
iii) Native player e.g. the Media Player on iPhones and iPods
Historically, on desktops, it was common to create plug-ins for each browser, to ensure that a player could behave identically on each different browser.
HTML (the language that web pages are authored in) was updated to HTML5 and this recognised the growing use of media, especially video, in web pages. Browsers that support HTML5 understand that a <video> element points to video content that should be played back in the browser without requiring a plug-in. However, different browsers require different video formats. Not useful!
On small IOS devices, Apple sensibly took a design decision to play back HTML5 video in fullscreen mode in the Media Player.
So what are some key points to understand about video playback:
Video playback on iOS – points to note
- On small devices (iPhone, iPod) as mentioned above, the video only plays back fullscreen. More here from Apple.
- On iOS devices you cannot programmatically set the volume control
- Only a single video stream can be played back at once.
- Video does not automatically play back because users may be on cellphones and paying per GB delivered. Instead, a placeholder graphic is shown (Apple’s default is shown below but you can set your own programmatically). Click this and the video starts.
Video playback with HTML5 – points to note
One size doesn‘t fit all – different browsers require different formats of video. While most browsers can playback H.264/AAC encoded video in HTML5 markup, not all of them can (Mozilla and Opera require webM wrapped VP8/Vorbis, at the moment. More here from Mozilla).
In practise, using an OVP (Online Video Provider – see list here) should make it simple to deliver video to multiple devices. Simply upload your master file, and the OVP encodes multiple versions, and provides a single embed code that automatically creates a Flash or HTML5 player linking to the appropriately encoded video.
Understanding VAST and video advertising
VAST is a standard. The IAB created VAST to ensure that video players from different vendors could receive video adverts from different ad networks and play them back consistently.
VAST supports prerolls, midrolls and postrolls – video ads that are played back inside the video player.
A video player is given a VAST ad tag. This is a URL to an ad server, which responds back with a VAST response in XML. The XML lists the video ad(s) to be played, and provides tracking data so that the ad network can record the video ad being played back (and how far the ad is viewed, as quartiles – 25%, 50% ..).
VAST also supports an ad network calling out to another ad network. If an ad network doesn’t have an ad, it can ask a connected ad network ‘Do you have an ad I can show?’ In case of a string of empty responses, a default failover ad can be programmed in the player (although not strictly provided by VAST).
So what does this mean for video advertising on multiple devices?
Understanding that different devices require different players with different video formats, and that the video player requests what ad to play using VAST, what is the overall experience on each device?
Video ads on a desktop, using a Flash player
- Full flexibility for video ads – prerolls, midrolls, postrolls
- Click-throughs (to advertising sites)
- Tracking events e.g. ad quartiles – 25%, 50%, 75%, 100% of ad played
- Impressions (a URL that is called when the ad starts playback)
Video ads on a desktop, using an HTML5 player
- Pretty much full flexibility
Video ads on an iPad
- The HTML5 video player can be embedded inside the page and must be manually started by a user-click
- A video pre-roll can be played
- Limited tracking is possible (e.g. instead of tracking individual quartiles, with HTML5 you typically fire off all quartiles once the ad has completed)
- As the video player can only play back a single stream, after the pre-roll ad the player needs to load the main programme. This can result in a small delay.
- For a mid-roll ad, the player needs to pause the main programme; remember where it got to; play the mid-roll and then reload the main programme and jump to the place it had got to. This will cause a delay in resumption of playback.
- The video player has restrictions such as no programmatic control of volume and no auto start.
Video ads on an iPhone/iPod
- The HTML5 video is shown as a placeholder graphic in the webpage
- If the placeholder is clicked, the video plays back full screen
- A fullscreen preroll ad can be player back followed, after a small delay, by the main programme
- It is not possible to send tracking events during the ad playback, although an impression can be fired off when the preroll ad is loaded (and with some ad servers, when the ad is actually played)
Video ads on an Android device
- On older devices that have Flash installed, Android will behave like a small desktop using the Flash player (embedded video players are often so tiny that they are useless, although if you have dainty fingers you may be able to double click the player to go full screen!)
- Modern Android devices require HTML5 video. However there are multiple Android devices (phones, phablets and tablets) so a one-size fits all solution is not reality. Instead the OVP and/or Ad platform will recognise the device and deliver the appropriate video ad version.
- As with iPhones/iPads, it is not possible to send tracking events during ad playback
There is no longer a simple way to monetise video online. What was previously relatively straight forward (load, aim, fire), and allowed a video publisher to string together a video file, a preroll ad and a flash player together, has now evolved into a much more complicated process where careful thought needs to be given to the entire chain – from a technical and commercial perspective.
Jukwa provides, at no charge, an online video strategy planning template. To receive one, please contact us here.
Thanks to Tom @ Videoplaza for clarifying a few questions as I wrote this