The most commonly listed complaints in our ‘Buy-Side View’ series is confusion around terminology. Video and OTT advertising are awash with acronyms, and all of us have probably been guilty at one point or another of throwing these acronyms into conversation without really understanding what they mean.
We want to help tackle this industry bugbear by giving an in-depth look into what exactly these different terms actually mean. Today we’re starting with Server-Side Ad Insertion (SSAI).
The Concept
SSAI (also known as Dynamic Ad Insertion of DAI), is a way of stitching a video ad directly into a piece of video content.
It has emerged as an alternative to Client-Side Ad Insertion (CSAI). With CSAI, ads are delivered by a separate third-party ad server directly to the client (the browser or device a viewer is using).
CSAI was developed to allow video ads to be personalised and targeted to the user. But it can cause problems with buffering and latency, since the video content and the ads played alongside it are separate files. It is also vulnerable to ad blocking.
SSAI also allows ads to be targeted and personalised. But by stitching ads directly into the video content, these buffering and latency issues are eliminated.
The Technical Detail
When a viewer watches a piece of video or OTT content, the video itself is streamed via a Content Delivery Network (CDN).
With CSAI when the viewer reaches an ad break, the video stops streaming content from the CDN. The client sends out an ad request, and will receive an ad in return which is delivered by a third-party ad server. Once the ad (or ads) have played, the video player continues streaming content sent by the CDN.
With SSAI on the other hand, when the viewer is about to reach an ad break, a separate ad insertion server (the SSAI server) puts out an ad request to a third-party ad server. The third-party ad server chooses which ad to show the viewer, and then sends back a video ad to the SSAI server. The SSAI server then stitches this into the video content the viewer is watching. This is passed back to the video player via the CDN, meaning the video player receives the video content and video ad in one continuous stream.
From the user’s perspective, the main difference between the two is that the video they are watching transitions seamlessly from content to ad, and back to content, without having to load ads separately.
But while the ads are included as one continuous stream, SSAI vendors will usually have ways of ensuring that viewers can’t simply skip past the ads they’re shown (like they would be able to skip any other part of the content).
Take an example where a viewer is watching a TV show where an ad break is set to play after 15 minutes. Since the video is delivered in one continuous stream, theoretically the viewer could completely skip past this ad break. But usually an SSAI vendor would instruct the video player to automatically run the ad break if the viewer tries to skip past the 15 minute mark. And while an ad break is playing, video players will usually disable users controls either partially or completely, to prevent viewers from jumping to the end of the ad break.
The Pros and Cons
SSAI vendors will often talk about providing a ‘broadcast like experience’, and this is one of its key advantages over client-side ad serving. SSAI avoids black screen pauses or loading icons between the break starting and the first ad playing.
This is particularly important for live broadcasts, like sports events. If ad breaks lead to buffering, viewers can end up missing important moments in the live broadcast.
CSAI can also lead to variable video quality between content and ads. A lot of streaming video today will be delivered using adaptive bitrate technology. Adaptive bitrate technology assesses a viewer’s bandwidth and CPU capacity at any given moment, and delivers the highest possible quality of video to fit those limitations. It’s designed to provide a continuous stream without pauses.
But with CSAI, when a video player switches between different servers to play an ad, there will likely be a change in bandwidth, leading to sudden changes in quality.
SSAI also helps protect against ad blocking. With CSAI, a viewer’s device is explicitly told which parts of a video stream are ads, and ad blockers can use that information to skip those ads entirely. With SSAI, because the SSAI server is given instructions about where ads are played, rather than the viewer’s device, ad blocking is much more difficult.
But measurement has so far been a problem for SSAI. Because the SSAI server is responsible for stitching in the ad, rather than the viewer’s device, it is also responsible for passing on information to the buy-side about how a user engaged with an ad.
This has opened up opportunities for fraudsters. Several schemes have been uncovered where fraudsters have used SSAI servers to pass on entirely false information, generating fake CTV traffic. White Ops earlier this year uncovered a scheme called ICEBUCKET which created 1.9 billion ad requests per day using this technique.
But this issue isn’t unsolvable. Since there are a limited number of SSAI providers, it should be possible to authenticate legitimate ad insertion servers. Industry bodies the IAB and the MRC are working on industry standards for authenticating servers.
And several ad tech companies have client-side solutions (i.e, solutions which run on the viewer’s device) which run in parallel to the stitched ad. CTV platform Roku for example has an integration with Nielsen, whereby app developers insert a piece of code to let Nielsen measure ad impressions delivered through SSAI.
