The world is moving towards online video services consumption at a very fast pace. Consumers’ expectations are varying with the available gamut of digital assets. With the emergence of OTT in the digital era, consuming video services over the internet has become a very popular trend which provides reliable and truly mobile experience. The percentage 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 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 turned out as a technology solution that can deliver a consistent experience similar to TV at the same time as opening up sizable advertising opportunities. This uniformity is a by-product of the “ad-copy normalization” which is built into SSAI. “Ad-copy normalization” is a process through which ad contents are encoded keeping the bitrates, frame rates and audio levels same as original content, therefore ensuring a smooth transition between primary and stitched content and vice versa.
SSAI technology is already being used with increasing success by broadcasters to deliver a seamless, engaging Live experience. Many broadcasters of VoD streams who have an existing CSAI (Client-Side Ad Insertion) solution in place are finding it increasingly hard to maintain, so there is a growing interest in the SSAI approach. This is partially triggered 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 have an edge over CSAI:
Implementation:
The code is decoupled from the ad server and the work on stitching and interfacing to the ad server being performed by the backend SSAI platform which provides overall flexibility in that the inventory and the decisioning engine is abstracted from the actual delivery. SDKs have also been developed, which means that there is effectively a middleware layer, with the interaction among SDKs, backend, and Ad server making it possible to reciprocate the ad server without changes to the SDKs.
Control:
There could be a single point for all ad insertion calls across Live and VoD, a single interface which provides access to a single Broadcast Stream, Promotions and VoD assets, and a single API which would provide real-time analytics.
Interactivity:
The aforementioned SDKs can support the use of clickable linear content and dynamic overlays, and also allow broadcasters to customize the instances when skipping, seeking and pausing are allowed.
Ad-blockers:
The stitching used by SSAI means that adblockers are unable to decrypt where the call to the server is being made, and so difficult to differentiate between an ad and the content itself, making SSAI highly repellent 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 massive security benefits, In brief: With SSAI, the preceding 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 as well. The first party ad server might involve the use of multiple third-party servers and expose the same viewers to being tracked by undisclosed companies, to the possible detriment of a broadcaster’s commercial model.
With the correct deployment, there is no significant reason why broadcasters should not consider SSAI when deploying VoD streams. As OTT audiences for both of Live and VoD continue to sustain, providers are more likely to seek a joined-up SSAI strategy, and by doing that, not only safeguard their current ad revenues but also enhance them.
