An Insider’s Look At The Future Of Zero-latency Video Ads

Asynchronous Ad Serving and You!

Remember LMFAO? WTF happened to those guys?

As far as I’m aware, I’ve never coined a term before. Yet, as far as I can tell, I am about to!

Admittedly my neologism is not particularly exciting for the average human. It’s a fairly complex and technical term, with an equally complex and technical definition. But even if my baby is ugly, I must admit a certain level of pride in my creation.

Drumroll please, my new word is… “Asynchronous Ad Serving”.

Now I know what you’re probably thinking, “But that’s not a new word. It’s just three old words put together!”

You’re right, and I’m sorry. I tried to roll it up into a nice tight portmanteau like “Branjelina” or “Mansplain” but I lack the linguistic dexterity of an entertainment writer and “Adsynchroserving” was just too tough to say. I stuck with Asynchronous Ad Serving, so for brevity’s sake let’s just call it “AAS”.

I must also mention that while I may have coined the term AAS, I didn’t invent the process it describes. That monumental task was accomplished by my colleagues at VIDCOIN where our team of mobile video experts has spent most of the past 4 years hacking away at the problem of video ad latency on mobile. Thanks guys! ;-)

What exactly is AAS?

Asynchronous Ad Serving is an OpenRTB compliant process for serving video ads — in app and on the mobile web — that eliminates all possibility of ad latency, both in terms of video loading and page loading speeds.

Put more simply, it’s an end-to-end technology solution to make mobile video ads a little more bearable for all of us, by ensuring they launch instantly regardless of the demand source and the connection quality of the device.

The goal of AAS is to build a mobile-first approach to serving video ads that takes the best of programmatic protocols like OpenRTB and the yield optimization tools of header bidding and blends them with technologies that ensure that video ads launch instantly and in HD quality every time.

The process was design to be simple for publishers to integrate into existing programmatic ad stacks while the pre-bidding element makes it attractive as a yield optimization tool. The end result is a mobile user experience that is just a whole lot faster than current systems.

How Asynchronous Ad Serving Works

AAS works by taking a fundamentally different approach to serving video ads on mobile. To accomplish this the classic ad serving stack must be virtually turned inside out. Let’s take a look, step-by-step, at the differences between the classic and asynchronous ad serving models.

In the classic model, the process of an ad auction, serving and loading the video ad only starts when a user arrives at or near an opportunity to see an ad.

The classic example of this is in a “pre-roll” video ad that plays before video content. A user clicks to watch a video on a publishers’ site and then has to wait for the entire bidding and ad serving process before the video ad will start. The system has been sitting around waiting on the user to arrive at that “opportunity to see” before it initiates the process to show the ad. This lack of hustle means that the classic system is forever trying to catch up with the user’s navigation.

There are plenty of spot-fixes available today that attempt to reduce ad latency inside the classic ad stack by solving one problem or another. However, none can claim to eliminate latency entirely.

Asynchronous Ad Serving on the other hand, takes a more proactive approach and can indeed eliminate latency.

The Preemptive Ad Call

The biggest difference between AAS and classic video ad serving is that the AAS process starts before the user arrives at an opportunity to see an ad. In fact AAS actually “creates” an opportunity to see an ad on a site or in-app only after the bidding and ad loading process is already 100% complete. This is how it can guarantee true zero latency from the perspective of the user.

The process begins with what we call a preemptive ad call in which the site or app generates a single ad call to the server when the user starts a session. This single server call contains data that is used in the next step of the AAS process to conduct a predictive analysis based on the user profile and other site level data.

Predictive Analysis

Instead of waiting for the user to arrive at an opportunity to see the ad, the AAS system anticipates their arrival. Once the server receives the initial ad call, it analyzes the likelihood that the user in question will have an opportunity to see a video ad during their time on the site or in-app. The analysis is happening while the user is browsing the site or consuming other content.

The system uses machine learning based on data sent from the site to build probabilistic user profiles. This allows the system to estimate not only if the user will see an ad, but also how many opportunities to see an ad the user will encounter within their time on site. The data being used includes things like, average time on site, where the user came from, average number of ads seen per session, user profile data etc…

Based on this analysis the server then decides first, whether or not it should launch the bidding process; if there is a low probability the user will see a video ad during the session then the server will not launch bidding. If however it does decide to launch an auction it may also decide how many pre-bidding auctions to launch based on the probability that the user will see more than one ad during the session.

Server Side Pre-Bidding

Once the predictive analysis indicates that the user will likely arrive at an opportunity to see a video ad, then a pre-bidding process is launched from the server.

This “server side pre-bid” process is very important and it represents an entire sub-topic of it’s own. I recently touched on a few aspects of it in my article, Taking the ‘Header’ out of Header Bidding which explains it in some detail.

For our purposes it is important for publishers to understand just two things about Server Side Pre-Bidding:

  1. It enables certain processes which are necessary to ensure zero-latency
  2. It also accomplishes the same yield optimization functions as header bidding; without slowing down the page!

This means that with AAS, publishers are not only able to eliminate video ad latency on their sites and apps, they are also ensuring the higher ad yield they have been seeking with header bidding. In fact because the auction is happening on a server and not on the page, an AAS system can actually call more demand sources faster, to better optimize yield compared to what is possible in the page header.

Publishers should bear in mind that header bidding was originally just a “hack” to get around what they saw as opaque elements of the RTB process (we’re looking at you DFP). Server side pre-bidding takes the best of that hack and puts it into a cleaner package that has little if any impact on the UX of the page where the video ad will be seen.

Server Side Optimization

Once the server side pre-bidding auction has been run the winning bid response is returned to the server. This is another advantage of AAS over header bidding, because when the winning bid comes into the server, the system is able to see and analyze the creative associated with the bid before it tries to load the ad on the page.

This means that AAS can sort out many possible errors or problems with the ad creative before trying to load it on the page or in the app. At the very least this means that all those wrappers and tags “waying down the ad” can be unpacked on the server first without slowing down the page.

If there are actual errors, the AAS system will anticipate it before trying to load the ad. For example if a demand source returns a winning bid response with a piece of creative that is outside the parameters of the device, the page or any other constraint, then the system can reject the bid ex-ante without having to re-run the auction. In such a case the system will just reject the faulty creative and call the second place bid response in its place.

If this same process were to be executed on the page, like in many header bidding scenarios, it could cause huge issues in both load speeds and the stability of the page itself.

Pre-caching The Ad

The next-to-final step in the AAS process is pre-caching the video ad.

A quick side note on pre-caching; I hope by now it is obvious that there is a lot more to the AAS process than just pre-caching. I need to point this out because I’ve already received criticism from folks saying “pre-caching has been around for years”. Let me clarify that I’m not claiming to have invented pre-caching. But as far as I am aware, no one has coupled pre-caching with predictive analysis and server side pre-bidding to make an end-to-end zero-latency solution that is compliant with programmatic protocols and few if any are able to do it on the mobile web… but I could be wrong, if so, please feel free to flame me in the comments.

For those of you unfamiliar with pre-caching the concept is pretty simple. Most video ads today run on the same streaming technology used to show video content. The problem with streaming however is that it is essentially trying to load the video, while the user is trying to watch it. On mobile, that is often not ideal. Buffering anyone?!

Pre-caching works differently from streaming in that it loads the entire ad before the user starts trying to watch it. The effect is that by the time the user starts the video it’s already loaded up and ready to play. This means that higher quality video can be loaded for a faster and more crisp experience.

Pre-caching can be done in several ways whether in-app or on the mobile web and each deployment may be a little different (in-app cache, on page pre-load, local storage in browser etc…).

Finally, pre-caching should be differentiated from the notion of “Pre-fetching” where a streaming video is partially buffered in the player before the user sees it. If you’ve ever tried to watch a video in your feed on the Facebook app with a poor wireless connection, you’ve seen videos that will only play the first 3 seconds or so… that is pre-fetching.

Pre-caching is actually calling the entire video file from cache and is the only way to guarantee that the whole video will play through to the end without interruption regardless of connectivity.

Pre-caching and Enhancing the Content Experience

A final advantage of pre-caching, particularly as part of a pre-roll format, but really with any video ad format the comes before content, is that by pre-caching the video ad, the ad will launch instantly and uses no bandwidth while playing. This means that the publisher can use the time that the user is watching the ad to begin pre-buffering the streaming content that will play following the ad. So not only does the ad launch instantly, once the user completes the video ad their content will also launch instantly and have a lower probability of running into streaming issues. So it’s both a faster ad experience and a more seamless content experience.

Closing the Loop

As the ad is playing tracking pixels are firing as they would with any video ad and tracking data is being sent back to the demand source. In fact, from the demand side the entire process looks exactly like any other video ad view from streaming technologies. The only difference of course being the potential performance advantages in terms of more people sticking around to watch the ad and less negative priming towards the brand for creating delays.

Final Considerations

So there it is, a long and complex definition for a technically complex solution. Hey, no one said the future looked simple! Of course from the user’s perspective it should in fact look very simple and that is what Asynchronous Ad Serving is all about, simplifying the user experience.

I’ve tried to be more or less exhaustive in my description of AAS, but there is no way I can address all of the potential questions that the process evokes.

I often hear questions about data usage, cache storage requirements and user workflows. I’d be more than happy to answer those questions in the comments if people care to leave them.

In closing, I would say that the adoption of more intelligent mobile video ad delivery technologies is long past due. We as an industry need to be exploring how we can improve the user experience of mobile video ads. AAS represents one of the most comprehensive solutions for one of the most troublesome yet lucrative corners of the advertising environment, mobile video.

By adopting smarter technologies like AAS digital publishers can push the limit of what is possible in terms of mobile UX. I hope you’ll join me in further exploring the possibilities of technologies like Asynchronous Ad Serving because the future of the digital ad industry is just out there waiting on us to do so.

Grant Gudgel is a co-founder and CSO of VIDCOIN, where our crack team of digital ad engineers are hacking the programmatic ecosystem to make zero-latency programmatic video the new standard for delivering quality video ad experiences to mobile users. Grant lives in New York and works with top digital publishers to improve the user experience of their digital video ad inventory across all devices, both in-stream and out. #UXMatters

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.