Timeouts… in the Ad-Stack Chain

(Nam Ly is contributing author for this post.)

The more things change, the more they stay the same. 

If you put your hand on your brother’s face, you’re going to get a time out!

Yuval,

(to his children, more years ago than he wants to admit)

If you don’t handle response time limits on the ad server you face, you’re going to get a timeout!

Nam,

(to demand partners, fewer months ago than he wants to admit)

It may seem obvious that it’s important to set response-time limits on chained components that must yield a result within a fixed period of time, but it doesn’t always happen. For ads delivered into linear OTT video, response time configurations in the ad-stack chain can cause problems. Let’s review the timing requirements in the data chain.  

In a typical server-side ad insertion (SSAI) flow, ad requests are made when an ad break is encountered, and responses (carrying ads) need to be returned within a few seconds, so that the ads can be processed, inserted, and delivered. The delivery chain looks like:

In this flow, the SSAI component discovers an ad break and asks the Service Ad Server for an ad. This ad server then asks upstream components for ads. Those upstream components can be multiple other ad servers (i.e., belonging to the content provider or the streaming platform which each provide ads), multiple upstream SSPs that aggregate available ad breaks, and multiple upstream DSPs that aggregate available ads. 

Generally, the SSAI step needs to have a response back in about 3-5 seconds. That means each step (A, B, C in the diagram) requires timing adjusted to ensure this requirement is satisfied. SSPs and DSPs typically respond within 250mSec, so they are generally not problematic. But places where response aggregation happens are, as well as exchanges and SSPs that don’t return ads but instead return VAST wrappers. These are basically references to other ad servers that may deliver actual ads, and wrappers add additional latencies. 

If the Service Ad Server is set to respond to the SSAI component within 3 seconds, but the Content Owner Ad Server time limit (A) is set to 4 seconds, the response from the Content Owner Ad Server may arrive too late to be included in the Service Ad Server response. D’oh! In that case, from the content owner’s point of view, there was a response and none of it converted to impressions: the content owner’s use-rate is bad, while the Service Ad Server use-rate might be just fine. 

When ad gaps like this happen, the solution is as simple as 1, 2, 3:

1. Set response time limits in the various ad servers in the chain, and set them in a way that each successive ad server has a bit more time than the previous ad server  in order to do its aggregation
2. Set limits to the number of VAST wrappers an ad server will follow to minimize the additional latency from excessive redirects
3. When managing demand waterfalls, fine-tune stricter timeouts for slower demand, as one slow partner can increase the overall response time 

While fixes are simple, discovery depends on either “the angry phone call” process or having an ad server that captures timeout conditions on demand sources and making sure these conditions are monitored. We prefer the latter. 

If you missed the previous posts in the series about unfilled ad slots – or ad gaps – check out the previous posts describing what ad gaps are and the impact CTV viewing:

• Intro to Ad Gaps
• Bad VAST Response
• Changing Ad ID and Ad Transcoding Issues
• It’s Not All Bad News – Some Ad Gaps Aren’t Real!
• When the Ad Gaps Are Your Own Darn Fault
• The Trouble with Beacons
• The Impact of Content Ad Gaps
• Zombies! (Really?)