In our last blog post we covered a 360 view on fill rate.
Now, theory aside, let’s dwelve on how parties try to achieve this. We covered in previous posts video ad serving protocols. We focused on VAST and VMAP mainly. While VAST has amazing capabilities, it cannot do all things at once. The extent of user interaction, the ad unit allows, is limited in VAST.
VPAID was introduced by IAB to enable the ad unit, itself, to communicate with the video player. VPAID is focused on allowing a rich interactive user experience with video ads. VPAID allows code logic to control the video player. This enables a lot of flexibility (eg. advertisers can measure a rich set of user interactivity metrics).
The catch. VPAID can also be used to implement waterfalling. And this is where problems appear. VPAID implementing algorithms to improve fill-rates are known as VPAID wrappers. Or VPAID shims. Hearing, or searching, these terms will definitely yield “slow loading” associations all over.
VPAID was intended for interactive, beautiful ad experiences. Instead, some say, VPAID shims abuse the protocol to inject logic to search basic ads. Or add tracking pixels. Or some other unrelated logic, etc. Have you seen a forever loading spinner before video start? One may assume the player is slow to load. But that is not necessarily the case. Most likely, the player gave control to a VPAID Wrapper that went daisy chaining/waterfalling. In its quest to leave no stones unturned, searching for an ad, light years can pass by.
How do you prevent it? The answer is: time outs.
We tested various VPAID Wrappers and seen timeouts reaching staggering values of 1 minute. To put this into perspective, the average content length is between 30s and 90s.
The VPAID Wrapper runtime greatly depends on the number of ad sources in waterfall configuration. And quality of implementation.
Why use VPAID Wrappers to return basic ads? Why not use VAST?
Why are we even talking about this? Simply put: supply and demand. Publishers would like to improve fill rate. Waterfalling improves it. To improve their offering, SSPs do various partnership with other ad networks/SSPs to sell their remnant inventory. Such partnerships create chains in the waterfall and improve publishers fill rate no matter of the targeting.
Moreover, to sweeten the deal for advertisers, SSPs may include extra code to check interactivity, viewability, etc. But how are SSPs trying to achieve all of that?
Meet VPAID Wrappers.
Containing jack of all trades logic. Everything stitched together in one or more large files. Of course, you guessed it, usually in Flash. This is another problem waiting to nuke. Then, with a marketing paintjob, publishers and advertisers think they have the best possible solution.
They pass along the ad request from ad network to ad network. Each with its own intricate jack of all trades logic. In the same chain, other ad networks can return another VPAID Wrapper. And so on.
The video advertising ecosystem is complex. Every party wants to add its holy grail logic promising ungodly returns. How do they enter the scene? Using VPAID Wrappers, of course.
Yet another link added to the chain. Every link does it’s own logic. Duplicate logic, of course, is rampant. Number of scripts and SWF files added to the page is hard to estimate. Imagine what that does to your page load times, and, the overall experience of the party caught in the middle: your audience.
Is there an alternative to limit all this weight?
Yes, it is. Do not abuse VPAID. Use the good old VAST as intended.
- VAST returns an ad as fast as possible.
- VAST allows passing an ad request to another network using VAST 3.0 Wrappers.
Sure, there were people out there who realized all this. Then, they searched for a solid VAST 3.0 implementation. As some of our blog post showed, in the current market, there are none. Question is why? VAST 3.0 was released in 2012. Implementing VAST is challenging. A player even more so.
To resume. What publishers need? A fast/reliable waterfall and revenue optimization solution.
Many jumped at the opportunity to fill this business need. But their approach using a VPAID Wrapper will never yield the desired results. What is the right approach, then?
Well, if it were easy, everybody would do it. The answer is: create a new player designed from the beginning to address all pain points of the industry. This all sounds marketish. Is it possible? Yes! How?
Create simple, reliable, custom components for every problem to integrate beautifully in a single player. Wow, that’s a mouthful. Back to how to do it.
- Create stellar VAST/VPAID/VMAP components implementing all IAB features to the letter.
- Create revenue optimization and fill rate improvement algorithms using above components.
- Keep total player size to the minimum
The way of Varrando is: Use ad networks returning VAST responses . No VPAID wrappers. VAST is way faster to load, interpret, deliver and run an ad.
It’s safe to assume publishers have several ad network accounts/tags. These multiple ad networks use VAST. Varrando allows publishers to put ad tags into competition using waterfall or broadcast.
- Waterfall calls every ad network in parallel. And use CPM price to select the winning ad.
- Broadcast sends a parallel ad request to ad networks tags. The first in x second wins the bid
No VPAID Wrappers whatsoever. Everything runs lightning fast. Our whole player size, with advertising and playback, is way smaller than any of those VPAID Wrappers.
However, should VPAID Wrappers are still in need, we offer the tools to control their behaviour using granular timeouts.
To conclude, to deliver ads faster shorten the chain by using Varrando. See a demo.