Over the past few months we’ve spoken in detail about the importance the role server-side ad insertion plays in an online video platform. This is comprised of two main focus areas: the delivery of an optimal user experience and the generation of advertising revenue. We’ve also discussed how advertisers require validation to show their advertising has been delivered and explained how a client-side software development kit (SDK) helps to facilitate this by measuring impressions.  In this blog we’ll dig a little deeper.  

Advertisers have a range of ever-increasing needs and the information they derive helps them support return on investment. However, with the growing fragmentation of platforms and capabilities as part of the digital age, there is a selection of other metrics that, when measured correctly, significantly aid advertisers. One of these metrics is “viewability”. Before we proceed any further let’s define the term “viewability”.  

Governed by the Media Ratings Council (MRC), viewability is the measure of whether an advertisement was “actually” viewed. According to the IAB Ad Impression Measurement Guidelines, to count as a viewable video ad impression, two continuous seconds of the video advertisement must be played, meeting the same pixel requirement necessary for a viewable display ad. The measurement of viewability has become a very important accompanying requirement when advertisers look to run advertising campaigns. After all, if an ad isn’t viewed then it’s of no benefit to the advertiser. For example, if an agency ran a campaign with a publisher and had an issue with low viewability, their issue would not be valid unless it was substantiated by a viewability vendor that is accredited by the MRC.    

Viewing measurability has been an ongoing challenge. In the early days, the simplest and most effective way to measure was via a 1×1 JavaScript pixel. This method wasn’t necessarily the most effective but created a best effort solution in a web-based environment. Unfortunately, it didn’t work in an application environment and most OTT services are application based. This meant that when an advertiser’s campaign ran on both web and application services, only the portion of the campaign on the web could be measured. This resulted in each individual vendor proceeding to develop their own SDK.  One thing that we have identified time and time again through engagement with the market is that development teams are tired of the number and frequency of SDK deployments required across their suite of platform/device applications. 

In an industry that operates on several standards, protocols and guidelines, there was a need to simplify and provide consistency in the methodology used to measure viewability.  To achieve this, the IAB Tech Lab, along with several vendors, committed to a collaborative initiative.  The outcome was the introduction of the IAB Open Measurement SDK (OM SDK). This initiative aimed to provide a single, centralised SDK that offers common code and libraries for facilitating third-party access to measurement data.  

Essentially this means publishers don’t have to have an SDK for every single vendor implemented on their application. They just have one application implemented with an API that each of the different vendor SDKs can simply plug into. However, the Open Measurement SDK is still evolving and does not yet cover all environments, such as connected TVs and Chromecast etc. Although for these examples viewability shouldn’t be such an important or relevant measure as there should not be any instances where the ad is not viewable. 

Where does VAST compliance fit in? 

At this point you may be thinking this is all well and good, but what is the link to server-side ad insertion? This is where VAST compliance fits in. When it comes to VAST, the industry is still predominantly using version 3, which is three iterations behind the most recently published VAST4.2 version.  

To leverage the full benefits of VAST you need to ensure that each piece of technology in the workflow supports the same version of the standard. This means that the publisher needs to go through their workflow and ensure each component is compliant and compatible with the standard; the primary ad server, the server-side platform, the demand-side platform, the video player, any measurement vendors etc. Herein lies the challenge, some technologies may be compliant, while others aren’t, meaning the workflow defaults to the lowest common denominator, which may be VAST3 for example. 

VAST4 includes support for server-side ad-stitching features around tracking, viewability, verification and performance. We therefore appreciate its value in optimising server-side ad insertion. At Switch Media, this is front and centre.  However, we also need to be aware that not everyone is supporting VAST4 and adjust accordingly. This is managed on a case by case basis.  

At Switch Media we are diligent about making sure businesses, their customers and advertisers get maximum benefit from digital ad insertion. The support of an SDK is necessary to facilitate requirements such as measuring viewability and consequentially drive optimal outcomes for advertisers.  

The open measurement SDK assists with this, although adoption of the latest VAST version is very slow. Currently, in order to avoid integrating an SDK or a pixel to measure viewability then support for VAST4 and above is required, for both client-side and server-side ad insertion.

Digital ad insertion has amazing potential when orchestrated well. Here at Switch Media, we make it our business to do just that. We keep at the forefront of the most up to date technology, ecosystems and compliance guidelines to ensure our clients can generate optimal advertising revenue and a seamless user experience in this ever changing and sometimes challenging digital world.