Yuval Fisher - January 28th 2022
(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 adserver 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 (e.g. 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 holes like this happen, the solution is as simple as 1,2,3:
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.