The amount of video accessed online, particularly by mobile devices, is expanding exponentially, and there is an associated need to maximise the monetisation of the streams by delivering ads across multiple device types with a uniformity of presentation and minimum of overhead.

Server-Side Ad Insertion (SSAI) has emerged as a technology solution that can deliver a consistent experience akin to TV, at the same time as opening up addressable advertising opportunities. This consistency is a by-product of the 'ad copy normalisation' that is built into SSAI, providing  ad content that is encoded with the same bitrates, frame rates and audio levels as those of the original content, and ensuring a technical compatibility between primary and stitched content (with the same CDN being loaded for both content and ads).SSAI technology is already being used with increasing success by broadcasters to deliver a seamless, engaging Live experience. It therefore makes sense to use it for VoD streaming as well.

However, the principal means of monetisation for catch-up remains Client-Side Ad Insertion (CSAI), where, at the start of every ad break, the primary player has to be stopped and the ad player put on top, with the primary player having to be resumed at the end of the break.It is, of course, possible for broadcasters to deliver a near-seamless experience using this model, 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 resumes.

However, there is always the risk of playback issues caused by inconsistent encoding of the ad copy. In addition, 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 there is 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. There are a number of 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.
• 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 AVOD 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.

You can read some examples of the impact of a joined-up live and AVOD SSAI strategy with DIRECTV in the USA and TV 2 in Norway.