A Mobile-First Banner Spec

After years of consideration, the IAB is finally updating the banner specs! Hooray! All of the Flash specs will be deprecated and replaced with HTML-based recommendations that will more accurately reflect the current landscape. File sizes will increase and best practices will be documented in just a few weeks.

At a glance, the familiar 40k file size limitation will increase to 200k for standard HTML units and in-banner video ads are allowed an additional 1.1 megabyte of video, keeping the traditional 15 second duration.

I’m currently participating in the IAB committee charged with designing the new spec, and while the guidelines for image based ad units are extremely important, the in-banner spec is of most interest to me as Addroid is primarily an in-banner video product. The current in-banner spec for a Flash based unit can be found on the IAB’s website, but I thought I’d publish here my personal opinion of how the spec could be modified to work in a mobile-first world.

I’m looking forward to your thoughts and feedback, and would be happy to share them with the committee.

Issue #1: Streaming vs. File Loaded (Progressive Download)

The current Flash spec is bisected into two categories: Streaming and File Loaded. As we transition into HTML based units a quick bit of research uncovers that streaming video is something that only works on iOS via Apple’s HTTP Live Streaming (HLS) and the very most recent version of Android 5.0. Additionally, these video streams will only play in the device’s native player thus, in-banner with streaming video is actually not possible.

The real question is, In 2015 do we even need streaming video for a video banner? In this day and age, streaming video is really more of an appropriate solution for Netflix or Hulu—i.e. long form video. With 90% of people having a minimum of a 5 Mbps connection on their mobile device and 80% having a 10 Mbps or more connection, a relatively small 300 Kb to 1 Mb file will download in about 1 second—less time than it would take to negotiate a streaming session with the device. To add some perspective, keep in mind the average Vine video is 600 Kb and the average Instagram video is over one megabyte. Both of these, along with countless SnapChat videos, are progressively downloaded and not streamed.

The only consideration for a best practice to properly compress a H.264 video is to make sure that the “Fast Start” option is selected during compression. This puts the meta data in the head of the file as opposed to the tail; enabling the browser to calculate a good time to start the file playback before the entire video file is loaded. “Fast Start” enables faster video playback. As an example, on YouTube the progress bar under the playback position is a visual indicator of this process in action.

My thoughts: All video specs should be listed as progressive downloads.

Issue #2: Polite Loads

Polite loads were something that was relatively simple to execute in a Flash environment however in HTML they are generally accomplished with some type of code installed by the publisher: i.e. a third party SDK or custom code hosted on the site. Because of the proprietary nature of HTML polite loads, the concept of having an initial load followed by a subsequent payload isn’t going to work as a broad standard. The passive polite load that I’m speaking to is not to be confused with files loaded after user interaction—something that is quite simple in HTML.

My thoughts: Make the file size recommendations in one bucket and not bifurcated into initial and polite loads.

Issue #3: Max Video Lengths

After some extensive A/B testing at Addroid we came to the conclusion that in-banner ads vs. static ads showed a lift in interaction/CTR;  however, 15 second video banners vs 30 second video banners showed no measurable performance difference. Seeing that this is an autoplay spec, a shorter duration means faster loads and better performance.

My thoughts: Consider scaling back the recommendation of a 30 second duration to a 15 second maximum for initial videos (prior to interaction).

Issue #4: Minimum Required Controls

I’m just gonna say it, you don’t need any controls.

When was the last time you saw a 40K Flash banner with a play/pause button? My point is that video is simply the animation medium. With in-banner you are replacing the idea of clipping out images of a product and animating them around in a 2D space with full motion video. Of course the audio is always user initiated and the duration will be 15 seconds like any other banner.

My thoughts: Video controls should not be required just as they are not required for a 40K standard banner today, nor any HTML5 standard banner in the future.