The amount of video accessed online, particularly by mobile devices, is expanding exponentially.  As a result, there is a need to maximise the monetisation opportunities by delivering ads across multiple devices and platforms in the most efficient way possible.  In this post I discuss why applying SSAI across all content is the most logical way forward.

Server-Side Ad Insertion (SSAI, or dynamic ad insertion) can deliver a consistent experience akin to TV while opening up addressable advertising opportunities. Consistency comes in part from the ‘ad copy normalisation’ which is the process of transcoding ad content with the same bitrates, frame rates and audio levels as the underlying stream, ensuring a smooth transition between programme and ad and vice versa (with the same CDN being loaded for both content and ads).

SSAI technology is already being used successfully by broadcasters for live streaming.  However, the principal monetisation technique for VoD remains Client-Side Ad Insertion (CSAI), where, at the start of every ad break, the primary player is stopped and an ad player put on top, with the primary player having to be resumed at the end of the break.

For a broadcaster with both Live and VoD, it makes sense for a single advertising workflow to be applied across all content.  

It is possible for broadcasters to deliver a near-seamless experience using the CSAI model for VoD, by pre-loading the ad player and buffer in the background and swapping the players over at the exact moments when an ad break starts and ends. However, there is always the risk of playback issues caused by inconsistent encoding of the ad copy.  Also, considerable effort is required in terms of implementation, with code having to be continuously duplicated from one device type to another, and from one environment to another, with the inevitable testing and maintenance overhead to achieve this result consistently across devices.

Many of those broadcasters of VoD streams who have a working CSAI solution in place are finding it increasingly hard to maintain, so we’re seeing a growing interest in the SSAI approach.  This is partly driven by positive experiences of SSAI for live (where CSAI is not an option owing to the strict requirements around ad break timings). But there are a number of other reasons why SSAI should appeal to broadcasters over CSAI:

• Implementation. The code is decoupled from the ad server, with the work on stitching and interfacing to the ad server being performed by the backend SSAI platform, giving an overall flexibility in that the inventory and decisioning engine is abstracted from the actual delivery. SDKs have also been developed, which means that there is effectively a middleware layer, with the SDKs talking to the backend, and the backend talking to the ad server, making it possible to swap out the ad server without changes to the SDKs.
• Control. There can be a single point for all ad insertion calls across Live and VoD, a single interface providing access to a single set of Broadcast Streams, Promotions and VoD assets, and a single API providing real-time analytics.
• Interactivity.The aforementioned SDKs can support the use of clickable linear content and dynamic overlays, and also allow broadcasters to customise the instances when skipping, seeking and pausing are allowed.
• Ad blockers. The stitching used by SSAI mean that ad blockers are unable to decipher where the call to the server is being made, and so cannot differentiate between an ad and the content itself, making SSAI highly resistant to ad blocking.

Besides being able to deliver SSAI at scale and to provide all of the existing benefits of configurable user interactivity, SSAI has enormous security benefits, which cannot be totally covered in this article. In brief:

• With SSAI, the aforementioned middleware layer affords control over the systems with which viewers are interacting. By contrast, with CSAI, the viewer’s device is touching the ad server and presenting its IP address (and potentially other information). The first party ad server might, in turn, involve the use of multiple third party servers and expose the same viewers to being tracked by unknown companies, to the possible detriment of a broadcaster’s commercial model.

With the correct deployment, there is no logical reason why broadcasters should not consider SSAI when deploying VoD streams. As OTT audiences for Live and VoD continue to thrive, providers are increasingly likely to seek a joined-up SSAI strategy, and by so doing, not only safeguard their current ad revenues, but also enhance them.

Read more on server-side ad insertion for live and VoD streams here.