SpringServe Publisher Latency Controls

There are two core tenets of running a successful web property:

  • Deliver a great user experience
  • Create revenue via advertising to help pay for great content

However, sometimes these goals are at odds with each other — these worlds collide when it comes to advertising. Occasionally, the best-paying advertisements add a significant amount of latency to the loading of content (or so you are told). This can have serious effects on your user experience and can negatively impact your revenue from other channels.  Google, for example, takes page load time into account within their algorithms.

A big culprit for user-impacting latency is video advertisements. Everyone has experienced clicking on a video, waiting for 20 seconds just to see if an ad will load, then waiting for the ad to play, then finally getting to the content.

What can a publisher do about this? We suggest three simple steps to improving your user experience:

  1. Understand the source of the latency
  2. Measure and understand the relationship between latency and revenue
  3. Control how much latency you allow at the tag and demand partner levels

Understanding the Source of Latency

There is a lot of confusion around how a video ad is actually delivered. The source of latency isn’t necessarily one tag, it’s what that tag’s tags are doing that can keep your spinning wheel-a-spinning.

Vast and VPAID:

It all starts with VAST and VPAID. These are two specs created by the IAB that define how a video ad server and video ads can speak to a player. They allow for a ton of flexibility in how your ad is delivered, displayed, and interacted with.

Digital Video Ad Serving Template (VAST) 3.0

Digital Video Player-Ad Interface Definition (VPAID) 2.0

Much like in display, this flexibility has been used to increase your overall demand pool in interesting ways. Some of these ways provide actual value to the publisher, while others create a ton of unnecessary latency and provide no additional revenue.

These specs are lengthy and relatively technical, but worth a read if you want to understand everything that is happening under the hood.

Below I’ll briefly describe how they have been used to create “waterfalls” and “broadcasts” of demand tags. This begins to look like the daisy chains of old in the display world, or the new world of daisy chained ad exchanges (a whole ‘nother topic).

Brief Summary:

It all starts with the Video Player. When it loads on the page, the first thing it does is make a request out to an ad server asking for VAST. VAST is an XML specification that can communicate to the player information about what ads are available to play, what assets they have (mp4, flv, vpaid), what sizes they are, etc.

Video ad serving Vast (latency)

From this list of possible ads in the VAST response, the player will choose one.

Most ad servers respond with a VPAID asset. A VPAID asset implements a Flash or Javascript API that allows it to communicate back and forth with the player. These VPAIDs play a crucial role in allowing a publisher to reach out to multiple demand partners, providing unique measurement metrics, etc.

However, they can also be the biggest source of controllable latency. Let’s take a look at how they work:

When the player loads the VPAID Unit, it initializes it. During this initialization phase, the VPAID reaches out to different demand partners in search of ads to fill your video opportunity.

Video ad serving VAST and VPAID (latency)

Eventually, one (“filled impression”) or none (an “error”) of these partners will have an ad to fill your valuable video impression.

Doesn’t sound that great to wait all of that time and have nothing to show for it. But how do you know if the latency is worth it?

Measure and Understand:

I’ve always believed that you can’t fix something you can’t measure. First, let’s define a few metrics that are crucial to being able to measure and understand.

VPAID Window: The amount of time the VPAID is open in the player trying to fill the impression

Demand Tag Response Time: The amount of time for the demand tag to respond with an impression
Sounds pretty simple and straightforward. If you can look at these two metrics, then you know everything you need to know about the source of the problem.  Good luck trying to find this information, but when you do it will probably come in the form of averages. Averages don’t really tell you the full story though. Let’s look at an example:

Here is some real data from the SpringServe platform showing Demand Tag Response Time for a single demand partner (We have the same metrics for overall VPAID Window as well).

Latency response distribution

If you looked at an average, you would see that it’s around 7-8 seconds. What that doesn’t tell you is what the distribution looks like and when you should cut the tag off. But, what it doesn’t show you is that really long tail.

After about 10 seconds, you basically never get any incremental fill, but this demand tag doesn’t really care and it will keep on searching well into the 20 seconds mark. After 17 seconds you are providing absolutely NO additional value to yourself, and having a BIG impact on user experience.

Take Control:

Now that you can see the impact and know what action to take, it would be nice if there was a platform that allowed you to easily do something about it.

Luckily, SpringServe lets you do exactly that. You have the ability to set timeouts on both the Demand Tag and VPAID level.

Latency timeout vast waterfall

By providing the right understanding, insights, and control, SpringServe allows a publisher to positively impact revenue without negatively impacting user experience.

David “Dave” Himrod


Leave a Reply

Your email address will not be published. Required fields are marked *