Sold on SSAI

This article originally appeared in FEED Magazine, Issue 12.

Server-side ad insertion is becoming a more valuable way of delivering advertising – and with cloud-based tools, one that’s becoming easier to implement

The great benefit of targeted advertising is the ability to offer the viewer something that is going to be attuned to his or her interests useful. Cloud-based technologies are enabling better methods for targeting messaging and for making sure that messaging gets to the right person.

The difference between traditional and targeted ad delivery environments is the shift from the collective viewing experience of broadcast TV to one centered around the viewer and their personal devices. The personal experience is highly tuned to the time and place the individual determines is right for them rather than the scheduling system of the broadcaster.

Poor implementations of ad-targeting, with a bad quality of experience (QoE) and poor video quality, degrade that personalised experience. For linear TV, the rise of DVRs created a generation of ad-skipping consumers. In the internet world, there is a cat and mouse game between video providers and consumers, with viewers finding ever more creative tools for circumventing ads, including ad-blockers.

The goal is to devise an architecture that enables the management of premium-priced targeted advertising within individual video delivery paths, which can provide clear delivery metrics, protect against ad blocking and maintain a consistent quality of experience for the consumer. This provides a higher QoE for audiences, as well as relevant ad content so less incentive to block. There are a host of technologies enabling this transformation being refined all the time.

ANATOMY OF AD INSERTION

Insertion markers: adverts are rarely hard-coded into a programme’s source video. Instead, the video includes markers that indicate where advertising can be placed. A special splicing marker is inserted into the compressed video information to signal the start and stop points for an ad break, based on a standard called SCTE 35. These markers are designed to be preserved through each successive step in the video processing workflow and enable frame-accurate splicing between video stream sources and ad material.

Adaptive Bitrate (ABR) Streaming: ABR divides actual video stream into a series of short segments described by a distinct manifest file. Each segment is complete in itself and made available in a range of bit rates to create different segment file sizes. The consumer’s video player’s actions are driven by interpretation of the manifest file and the relationship of available video delivery bandwidth to the bit rates of the video segments. The power of this approach comes from the additional information that can be included in the manifest file, opening the possibility for playing alternative video segments at the insertion markers – and without breaking the integrity of the video rendering.

Ad decisioning: the video stream’s insertion markers become the triggers to not only insert ad content, but evaluate what content should be inserted. This evaluation role is designated to a service external to the video processing architecture, known as an Ad Decision Server (ADS).

The ad insertion marker initiates a protocol exchange defined by a standard known as video ad serving template (VAST). This is complemented by the video multiple ad playlist (VMAP), and the video player ad-serving interface definition (VPAID) protocol. These ad serving protocols are all maintained and published by the Interactive Advertising Bureau (IAB).

When an insertion mark is detected in the stream, available client information is sent to the ADS to determine which ad to insert. Parameters used for ad selection could be as basic as the location of the requesting device, determined by its IP address, or could be far more detailed and personalised if the viewer happens to be signed in on a client device or has prior tracked web activity. The ADS responds with the ad information and with tracking beacons for reporting ad impressions.

Cloud DVR and Trick Play: audiences expect advanced features from OTT providers, including time-shifted, start-over and catch-up TV. This offers advertisers prolonged content availability and opportunities to refresh targeted advertising so ads remain relevant. An ad for a promotion that ends on a specific day of the month, for example, runs the risk of becoming irrelevant. It is important that video operators have the ability to replace this specific ad when the new month starts, to ensure relevance and to continue generating revenue.

Delivery reporting: the business end of digital advertising depends upon counting ‘impressions’, discrete consumer views reported from the client to the player.

If there is no way to positively confirm that an advertisement has been played on a specific device, then no money is due from the advertiser to the service provider.

In fact, the more detail that can be collected on the viewing profile of a given advert, the more potential value the impression will command. Reporting mechanisms depend on beacons generated in the video playback process that indicate partial or completed viewing of the advert. The triggers for the beacons are part of the data inserted into the stream by the ADS. The beacon process is designed to be transparent to actual video viewing.

CSAI TO SSAI

Initial implementations of targeted advertising were built substantially around client player functionality. This is client-side ad insertion (CSAI). Incentives to adopt this approach were the increasing sophistication of client video players, the scalability of the solution and the potential for enhanced interactivity.

More recently, video services have shifted their focus to added functionality in server-side subsystems – often cloud-based. The impact of this change on advertising is a new consideration of the merits of server-side ad insertion (SSAI). Unlike the CSAI model, in SSAI the call to the ADS is done upstream of the CDN and delivery to the client. The ADS call is triggered by the same ad insertion markers, but these markers are detected by the server-side video pipeline.

SSAI processing creates a single, packaged stream that contains program and advertising content deliverable to clients, with each client seeing a personalised manifest file. This format simplifies the requirements of the player at the target device, which enables lighter-weight apps and reduced demands on web players. This, in turn, means a service can be deployed faster because there is no need to develop and maintain player technology for each and every platform and operating system.

Typically for SSAI, it becomes the responsibility of the video service to create the reporting and metrics on delivered advertising. There are some nuances to this in individual implementations, but overall the approach can prove less vulnerable to ad blocking.

SSAI WORKFLOW

Amazon Web Services provides support for complete ad insertion workflows. For SSAI, AWS Elemental processes content for delivery in a mezzanine format. At this stage, the source video should have the SCTE 35 ad insertion markers added by the source content provider embedded in the feed. If it does not, these insertion markers can be programmatically inserted at this stage by AWS Elemental using an API interface.

The compressed mezzanine stream is sent to AWS Elemental MediaLive, which compresses the live video to the adaptive bitrate streams designed to play back on client devices. MediaLive uses ad cue markers to ensure the output streams have manifests that retain the start and end of the potential ad breaks. MediaLive uses the ad cue markers to put an instantaneous decoder refresh (IDR) frame into the encoded output after the ad break is complete, so audiences get a broadcast-like experience when streams switch between ad and primary content.

The ABR encoded streams and the manifest with ad markers are published to AWS Elemental MediaPackage, a just-in-time packaging and origination service that prepares video for delivery over the internet. AWS Elemental MediaPackage creates a templated manifest for the personalisation and monetisation service AWS Elemental MediaTailor.

These templated manifests include discontinuity tags at the start of ad breaks to identify start and duration of the potential insertion. AWS Elemental MediaTailor is then brought into the workflow as the origin point for the personalised manifests, receiving targeted information from a client device at each ad break, which it uses to make a request to an ADS. The ADS responds with the ad selection for that particular viewer at that time, as well as information tracking how impressions will be measured and reported for that ad insertion.

The ADS response includes a reference to a high-quality mezzanine version of the ad that MediaTailor can use as a source to transcode to ABR segments that match the format, resolution and bit rate of the viewer’s primary content. This ensures audiences don’t see any jarring transitions in quality or aspect ratio when switching to and from ad content.

Pointers to the compressed ad content are stitched into the final manifest file. Even though the ad segments are not originated from AWS Elemental MediaPackage like the primary content stream, they are delivered using the same CDN host names. MediaTailor ensures the manifest contains both content and ad video references that are structured in the same way and play back without buffering discontinuities.

Reporting ad impressions is a vital part of monetisation. AWS Elemental MediaTailor offers server-side ad impression reporting by default, using Amazon CloudWatch logs and Amazon metrics to determine impressions. An API enables clients to determine where ad breaks occur and supports client-side reporting, as well as any advanced playback features such as ad timer countdowns or disabling scrubbing for ads with on-demand content.

Targeted advertising offers huge benefits over static advertising with a cost per thousand impressions valued many times greater than static advertisement. Both CSAI and SSAI have been deployed successfully, but the potential for SSAI to improve QoE and mitigate blocking issues makes it an attractive alternative to prior technologies.