More than ever, publishers are feeling pressure to really understand and deliver on their video inventory in mobile. It’s widely held, and upheld by one study after another, that mobile video consumption has risen dramatically in recent years: eMarketer says that through 2015, 105 million U.S. users watched video on their smartphone once per month, and 95% of millennials did so at least once every week. Cisco predicts that by 2020, 75% of mobile data traffic worldwide will be chalked up to video viewing. Industry analysts figure users will be encouraged to watch more video via mobile devices as devices become more powerful and better at rendering video, wifi access becomes more prevalent, and the decreasing cost of data access leads data plans to grow in size. We could go on for a while.
Trends in user behavior naturally have publishers scrambling to demystify mobile video. The problem with demystifying mobile video is, it can look like there’s an awful lot of mystique there. The ad experience can vary greatly, depending on factors like what kind of device is in play, whether the user is on wifi or data, whether the user is on mobile web or in an app. The good news is, publishers who have devoted attention to mobile video have come away with insights and advice, which they’re willing to share with their peers.
Let’s get started with one of the biggest, most obvious issues publishers face in mobile video: delivering the right creative for the user’s experience.
The Right Creative
An ad creative that works for desktop may not work for mobile. The ad might play for too long—mobile users want immediacy and have short attention spans—and the file might be too heavy for the connection to load smoothly. As a publisher, you and your ad server need options in a mobile environment.
With cross-platform delivery becoming normalized, video ad files now tend to come with creative optimized for high, medium and low bit rates, plus a large, high-quality mezzanine file. Ideally, the video player communicates the device and optimal bit rate to the SDK or ad server, which in turn fetches the appropriate creative. That helps all parties involved avoid a situation where a user of a wifi-enabled OTT device sees a lo-res video on their screen, or where a 3G user on a smartphone gets a huge ad file that buffers interminably.
It’s a clean system on paper, but publishers need to make assurances that their players are delivering the right creative for the right experience. Some publishers might feel entirely confident in their ad servers to make the best choice and to encode files properly. Others may want to put in extra precautions so, as one publisher put it, an ad-serving failure isn’t so severe that it makes the user close out the session.
What kind of precautions? Advertisers should have your updated specs, for one thing. Even if the advertiser has your specs, there’s still a chance someone along the chain could swap out the “right” file in the creative for a much heavier file. A publisher might want to implement a process of screening out bad files. At the very least, advertisers should know your specs for small, medium and large files. Some publishers are asking for a greater variety of file sizes than that.
One problem a publisher source told us about is, if the publisher doesn’t take measures to prevent it, the extra-large mezzanine file might get picked up and served. The ad server could possibly encode that file for the right device, and through VAST 4.0, the mezzanine file should be called out specifically to the player, so the player won’t pick it where it’s not supported or necessary. But until VAST 4.0 itself is more widely supported, mezzanine files are still getting served improperly, and it may be up to product and tech teams to try to prevent that from happening.
So if it’s important to plan for different video files to be transcoded for different viewing environments, what does that mean for these files’ bitrates? IAB-recommended in-stream video specs call for 500-700 kbps at the low-res end–but people active in mobile might be inclined to tell you 500 kbps is still too high for a lot of mobile scenarios. If you’re serving the ad to a smartphone with a decent data connection, 75-150 kbps might be more in the ballpark. With a strong wifi connection, 300-600 kbps might be more appropriate. In that case, 300 kbps would be a safe maximum size for much mobile video. For reference, consider the IAB’s suggested formula for determining target bitrate: [target bitrate] = [width]x[height]x[frame rate]x
Some publishers have reported they’re still getting Flash creative from advertisers. As basic as this is, publishers should be clear in their specs that mobile ad creative really needs to be in HTML5, with the file format being .mp4.
There are other factors publishers might consider in their mobile specs, like video length and screen orientation. At this point, there’s broad consensus that 30-second (or longer) spots are bad for the mobile experience, and that 15 seconds is the preferred maximum length for the format. As it stands, a lot of entities are pushing in mobile for ads 10 seconds or shorter. Consider the seven-second ad—maybe call it the “Vine standard.” And by the way–publishers would be advised to include a “skip ad” option. Would you want anything less while you’re trying to watch a video on your smartphone?
Publishers are definitely going to want to plan for their mobile inventory to meet advertisers’ expectations and accepted industry standards. For video, that means at least 50% of pixels in view for at least two seconds, per the MRC’s guidelines. Keep an eye on the MRC’s announcements on the subject. The organization has been promising to release a document with comprehensive specs for mobile video before the end of Q1 2016. In any case, for mobile web, viewability is assured via HTML5 Javascript VPAID tags. We’ll get into a little more detail in a few paragraphs on how VPAID works as a communication layer.
Some industry experts point to trends toward viewing mobile video vertically rather than horizontally—consider the rise of Snapchat—and toward watching more mobile video with the sound off—consider the growth of video in Facebook. These are factors publishers should consider in the QA process for mobile video ads, depending on the environments in which their users will be viewing.
Understanding the Standards
This is a good point to touch on VAST, VPAID and MRAID. Publishers need to understand how these standards work with their mobile inventory and the expectations or demands of their advertisers. Some publishers might find that with the kind of inventory they have, MRAID compliance isn’t necessary. Furthermore, some publishers find VAST and VPAID have certain limitations in interactivity and reporting functionality.
MRAID, or Mobile Rich Media Ad Interface Definitions, is the IAB’s standard of a common command set for developers. Basically, it allows the creative in an ad to interact with an operating system in an app environment. This differs from the mobile web environment, where ads run in iframes. In iframes, the ad and the browser speak to each other in Javascript and HTML5. In an app, the ad container needs an extra layer—MRAID—to communicate. Through MRAID, the ad creative can pick up information about factors about how it should be sized and positioned on the screen. About half of MRAID’s functions have to do with changing the size of the creative. Note that MRAID only works in-app, not on mobile web.
MRAID does present some challenges for mobile video, though, in a fragmented mobile landscape. When you use MRAID, the video launches in the mobile device’s native player. That player is not a web page, so it doesn’t support clicks. The same goes for full-screen iPhone and iPad videos—but not necessarily for Android.
VPAID can be layered onto VAST to allow for communication between the video player and the ad unit, which in turn provides greater interactivity on the user’s end. A lot of advertisers like VPAID (VPAID 2.0 in particular) because it enables reporting on things like viewability and verification in an array of environments, and as such they ask publishers for VPAID compliance. However, some publishers find VPAID has some shortcomings too. One shortcoming is, again, that VPAID might launch the device’s native video player, which can’t be clicked through. Server-side ad insertion can also be a challenge in VPAID. And Google doesn’t support VPAID yet in mobile apps.
Many publishers are banking on VAST 4.0, which in theory will solve a lot of problems—it will facilitate server-side ad insertion for more fluid and device-optimized ad experiences, and it will deliver the reporting tools advertisers want. However, they’ll need to wait for VAST 4.0 support to become widespread. As it stands, a lot of digital entities chose not to support VAST 3.0 and are still relying on 2.0.
One of the more heralded aspects of VAST 4.0 is that it stands to make server-side ad insertion a standard. While not everyone agrees server-side insertion will necessarily make for better ad experiences than good client-side insertion, the promise of server-side insertion, or stitching, is that it will allow for even the heaviest creative file to be encoded for the screen where it will be displayed.
On and Off Track With Tracking
If VAST 4.0 turns out to be the standard we’ve been promised, it should clear up some of the opacity publishers have observed when it comes to verification. As it stands, publishers have a fair number of issues they’d like standards to improve.
A source told us they’ve had tracking and impression counting discrepancies arise by not being able to see, with VAST redirects, where they can add third-party pixels or tags. They also reported that sorting out which of those pixels belongs to a billable source, and which to a measurement source, can be a challenge. Not having VPAID access may limit enhanced measurement and tracking, including viewability in some cases.
In mobile display, tracking beacons are served by the device. In video, they’re served by the player, sometimes in conjunction with the ad server SDK. The player knows where the ad starts and when to fire the start beacon, 50% beacon and so on. One publisher source explained that when beacons are fired by the cloud, rather than by the device, without accessing the browser, it can produce discrepancies in tracking and attribution.
Where to Go from Here
Mobile video is in demand and growing, and there’s a lot of hope for its future. But it’s evolving, and doing it right can require a lot of oversight from publishers.
QA is key. Publishers need to make sure they have the right creative coming through the door to support the mobile video content their audiences are consuming. In some cases, that might mean limiting the number of partners they work with programmatically, to assure they’re working with partners who can deliver what they need. Pubs should flag errors and communicate with partners to assure specs are being met and errors are kept to a minimum. Sales teams should be educated so they can set reasonable expectations with clients. Ops should look into QA tools, which are available from Google and elsewhere, and be proactive rather than simply reactive.
Advertisers are hungry for mobile video inventory, but publishers should be aware of what they’re capable of delivering and what kind of participation they’ll need from their advertising partners. Meanwhile, the industry at large is moving toward standards that promise to make the process cleaner and more streamlined for both the buy side and the sell side. There’s good reason to be optimistic as the mobile video marketplace expands and moves forward.