The amount of video accessed online, particularly by mobile devices, is expanding exponentially. As a result, there is a need to maximize the monetization opportunities by delivering ads across multiple devices and platforms with a uniformity of presentation and minimum of overhead, regardless of the platform type or content type.
Server-Side Ad Insertion (SSAI, or dynamic ad insertion) 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 normalization” that is built into SSAI. “Ad copy normalization” is a process through which ad content is encoded with the same bitrates, frame rates and audio levels as those of the original content, therefore ensuring a smooth transition between primary and stitched content and vice versa (with the same CDN being loaded for both content and ads).
CLIENT-SIDE AD INSERTION
SSAI technology is already being used with increasing success by broadcasters to deliver a seamless, engaging Live experience. However, the principal means of monetization 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. For a broadcaster with both Live and VoD, it makes sense for a single advertising workflow to be applied across all content.
It is, of course, possible for broadcasters to deliver a near-seamless experience using the CSAI model, by preloading 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, providing 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.
Click here for more on server-side ad insertion for live and VoD streams.
David Springall is the founder & CTO at Yospace.
