The traditional client-side approach to VoD ad insertion (CSAI) typically goes like this:
It used to be an effective and straightforward way of injecting advertising media into VoD content — up until the ad blockers came along. A simple browser addon installable with a few clicks makes it possible to easily block all requests to ad servers.
According to PageFair 2017 Adblock Report, as many as 615 million devices globally use ad blocking, with over 50% of them on mobile. As PageFair points out, the primary reasons behind the rise of ad blockers are fear of exposure to malware, interruption, and page load speed.
Armed with extensive URL blacklists and supported by entire communities, modern ad blockers, such as Adblock Plus or uBlock Origin, can effectively render CSAI useless.
That leaves advertisers and publishers scrambling for a better solution.
The SSAI (also known as server-side ad stitching) approach gives publishers a way to circumvent ad blockers by hard mixing ad media chunks with VoD content right on the server.
For HTTP-based VoD streaming (with HLS and MPEG-DASH being the most popular technologies), the flow begins with a client-side player requesting a VoD playlist and includes the following steps:
(*VPAID does not work here as the standard does not allow getting a direct URL of the ad media source.)
It’s a truth universally acknowledged that adverts are nothing without well-established and nuanced tracking. Currently, there are two ways to process tracking events in SSAI.
We could try using a custom client-side player add-on to handle instructions from the proxy server in a custom format. It’s a fail-safe tracking method, since the add-on can precisely trace the required user actions mapped to the VAST document’s tracking events.
On the downside, this arrangement requires a unique add-on for every popular frontend player out there. With the variety of players that different publishers utilize, this additional burden severely undermines the flexibility of SSAI integration.
Since we are playing HTTP-based streams, we can also track server requests to corresponding chunks or playlists, as well as calculate user behavior that needs to be tracked. Currently, this approach to tracking seems to be universal, and our adtech professionals have tested it in a number of projects:
When generating a mixed SSAI MPEG-DASH playlist, this feature allows injecting as many HTTP requests from the client-side player as needed to reach the required tracking precision.
In tracking these requests, the server needs to utilize predefined logic while translating the necessary tracking events from the previously parsed VAST document (such as quartiles, midpoints, etc.)
Typically, ad targeting data is kept in cookies that store user IDs for a specified ad platform. Personal information is collected and logged every time a user visits a website with injected elements from that platform.
In SSAI, when making an ad request from a proxy server, we have to also transfer the cookie ID to maintain the relevance of user statistics. It is possible to store the IDs for every unique visitor in a database and use them with all requests to the corresponding ad platforms.
The limitation here is that user history collected this way includes nothing but the proxy server’s ad requests. This lack of detailed user behavior data can have an adverse impact on personalization-related advertising parameters.
After viewing an injected ad, a user can rewind the video and view it again, start viewing the ad from the middle, or perform other actions outside of the traditional client-side flow. In such situations, server logic must be carefully crafted to avoid tracking multiple views for one requested ad and skewing the viewing stats as a result.
MPEG-DASH remote elements with the onRequest property can provide additional flexibility around tracking multiple views, but keep in mind that any ad injection requires time for transcoding new media.
That’s why a streamlined SSAI implementation must identify the already transcoded ads and pull them directly from local storage. This method would serve well for pre-rolls and other critical cases when there is no time for transcoding before the playlist is transferred to the client.
Early 2016 saw the release of VAST 4.0, the upgraded version of the IAB’s standard that facilitates SSAI implementation out of the box. The support for such features as raw mezzanine files and Universal Ad IDs makes it possible to request the highest-quality video file for further transcoding as well as easily identify the already transcoded ads.
Despite its advantages, the adoption of VAST 4.0 remains a relatively tentative process. Many advertisers and publishers stick to its popular predecessors, VAST 1.0 and VAST 2.0, waiting for each other to pick up the new standard first.
Even so, things have been moving in the right direction: OVP vendors — such as Brightcove and Kaltura — are actively promoting SSAI while DoubleClick announced VAST 4.0 support in May 2017. All in all, there is little doubt that SSAI is here to stay.
Do you think ad stitching is the way to go? Does the threat of ad blocking warrant drastic measures for advertisers? Share your thoughts below!
Presales Specialist at Oxagile