The traditional client-side approach to VoD ad insertion (CSAI) typically goes like this:
- The browser sends a request to an ad server.
- The ad server responds with a VAST or VPAID document containing the link to an ad creative.
- The client-side player shows the ad in a specified position on the video timeline.
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.
What Is Server-Side Ad Insertion?
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:
- Redirect all VoD playlist requests to a special proxy server.
- From the proxy, request the VoD playlist from the VoD server.
- Determine the number of ad insertions needed and request a VAST* document from the ad server. (This step should include the retransfer of the targeting data from the client side, which will be discussed in more detail below.)
- Get the VAST response from the ad server, parse the instructions, and find the URLs of ad media sources.
- Transcode the media files into the format of the VoD stream and push them to a CDN.
- Mix the original VoD playlist with the newly created playlist containing ads.
- Send the new playlist to the client-side player.
(*VPAID does not work here as the standard does not allow getting a direct URL of the ad media source.)
The Uphill Struggle of Tracking Ad Usage Events
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.
Client-Side Player Add-on
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.
Server-Side Tracking of Stream Consumption
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:
- HLS streaming. The structure of the HLS VoD playlist file only allows tracking the requests to ad media chunks. In practice it means tracking nothing but buffering requests from the client and basing all tracking events on buffering actions. What advertisers get as a result is merely a rough approximation of ad usage numbers.
- MPEG-DASH streaming. The latest versions of the MPEG-DASH standard include a playlist tagging feature, which allows transparent server-side tracking by leveraging the remote element functionality.
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.)
Having researched MPEG-DASH server-side tracking under various conditions, we were not particularly encouraged by the results. While the native Android player performed well with all the instructions, the support for remote elements in popular JavaScript players leaves much to be desired.
It seems, therefore, that until the popular JavaScript players provide full-fledged MPEG-DASH specification support, proper SSAI tracking will remain a daunting task.
Limitations in Ad Targeting
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.
Multiple Impressions and Media Reuse
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.
Industry Support and the Future of Ad Stitching
The release of VAST 4.0 in early 2016 brought support for server-side dynamic ad insertion. New features like raw mezzanine files and Universal Ad IDs enable high-quality transcoding and easy identification of ads. 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. SSAI ads are here to stay, offering a promising way forward in combating ad blocking. 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!
Oleg Gubin
Presales Specialist at Oxagile
