In Part 1, I introduced the problem of ad holes and some of the common errors that cause them. Now, I will explore issues that lead to ad holes that aren’t necessarily errors, but rather incompatibilities between distinct systems.
SYSTEMATIC AD HOLE ISSUES
Wrappers: Some widely-used ad servers do not respond to ad requests with VAST in-line ads; they return VAST wrappers that are a separate VAST call to a third-party ad server. The SSAI system makes a separate call to the third-party ad server and inserts whatever creatives it receives. When the third-party server has no demand to serve, no ad is inserted.
The first ad server thinks it returned and used a slot for an ad. However, the ad was to be filled by the third-party ad server. The first will report whether an ad was delivered or not by the subsequent call, which can make it look like something is broken or fills are not converting to impressions, when everything is actually working correctly.
The solution in this case is to not return wrappers—a good ad server will make the third-party call itself and check if it returned an ad, avoiding wasting a spot on empty demand.
Read the manual: Every ad server has a list of recommended and required parameters to be included in the VAST call, and often these are not set up correctly, resulting in poor responses.
What if every time was your first: The most common format for creatives is mp4, which can be delivered to SSAI systems as downloadable files. But in OTT delivery, the creatives must be transcoded into multiple bitrates/resolutions and into a streaming delivery format, which is not usually done ahead of time; it’s done when the ad creative is encountered for the first time in a VAST response. How is the SSAI system, which is typically responsible for the transcode, to recognize the creative in order to avoid transcoding it again?
One option is the creative ID, an identifier returned in the VAST response, which should be unique and static for each creative. Unfortunately, these are either omitted, changed for every response or not unique. The URL of the creative could be used as the key to recognizing ads that have been seen before and transcoded, but this too is often dynamic, with timestamps and other data that change with each response included in the URL.
There’s an effort to create a universal ad ID and a VAST 4.0 specification to clarify usage, but today, without a robust “creative normalization” scheme, the same creative may look new every time it’s returned. It’s transcoded for placement the next time it’s seen, which never happens; the next time, it looks new again. This can be a major cause of impression loss.
Timing: Timing issues also plague the ad delivery ecosystem. Different servers respond with different timeouts (or don’t respect their published or configured timeouts). This results in calls that take too long to finish for the ad splice to happen.
Another issue involves the time window for beacons signaling an ad view. Most servers will accept beacons within 30 minutes of the ad response, and some for as long as two hours. In rare situations, beacons may not be sent out within those time windows, or the window is shorter. This results in rejected impressions, which are technically ad holes.
Plain not getting along: Issues such as SSL incompatibilities occur, and the SSAI system just can’t fetch an ad response or a creative.
Mitigations for these issues involve manual investigation, typically by an experienced ecosystem partner with visibility into the resulting low impression rates.
MISUNDERSTANDINGS: WHEN AD HOLES AREN'T REALLY AD HOLES
In some cases, what looks like an ad hole turns out to be a misunderstanding of what inventory is really fillable.
Fake views: Some inventory looks wasted, when it’s really not accessible for filling. For example, in OTT viewing applications with multiple channels, many users view channels for very short amounts of time as they traverse content. The generated ad requests that never have a chance to become impressions lead to returned ads that appear to be thrown away. This can account for 10 to 30% of returned ads.
This problem can be mitigated by avoiding making ad calls when users join a channel during an ad break. A very small amount of real inventory is not used, but since most new channel joins are fleeting, the wastage is minimal and unusable calls are reduced.
Even with this mitigation, a significant number of users join just before an ad break, stay to make the ad call and then leave. It’s harder to suppress these users’ ad calls, which account for about 12%, though the actual value is channel dependent. For example, a channel that’s near a popular channel in the lineup may experience more users who channel-zap through.
That bad filling: Some inventory is not fillable due to unusual break durations or ads that don’t fit. For example, even with ad breaks that are strictly multiples of 30 seconds, an SSAI system may end up with a 30-second creative that can’t fit into a 15-second slot. A 60-second break that returned three ads of 30, 15 and 30 seconds, may fill the first two only, having no room for the third and wasting 15 seconds. On average, we find that this issue accounts for 5% of unfilled inventory. Splicing ads not in their returned order can mitigate this issue, though it can lead to violated demand prioritization.
Understanding the hurdles to yield optimization is the first step in overcoming them. Selecting a knowledgeable and experienced partner to uncover and resolve problematic ad holes can help publishers easily maximize revenue. In many cases, issues between the multiple partners in the ecosystem can only be fixed through a central entity, as there are no direct relationships between those partners. Working with a knowledgeable ad yield expert is the difference between “monetizing” and “monetizing well.”
Yuval Fisher is senior vice president, technology for Wurl.
Future US's leading brands bring the most important, up-to-date information right to your inbox
Thank you for signing up to TV Tech. You will receive a verification email shortly.
There was a problem. Please refresh the page and try again.