SSAI: What Marketers Need to Know About Server-Side Ad Insertion
SSAI is one of the crucial innovations that has allowed over-the-top (OTT) video to become a viable industry, because it opens up paths to monetization and helps to both absorb infrastructure costs and create profit centers where cost centers have existed. But while technologists are bullish on SSAI, some vendors and content publishers are a bit more cautious. This article takes a look at the state of SSAI, both its successes and the challenges it still faces, including scaling to large audiences and privacy concerns.
According to a recent Interactive Advertising Bureau study called "Live Video Streaming: A Global Perspective" 70 percent of consumers watch digital video once a day, 67 percent have live streamed content, and more than half (52 percent) prefer free, ad-supported content. Stream stitching and SSAI allow ads to be inserted directly into the programming stream, making for a more seamless viewing experience.
"If you can stitch ads in on the server-side and make sure the VAST [Video Ad Serving Template] impression pings associated with the individual ads are properly tracked, then all of a sudden you can send out one integrated stream," says Chris Xiques, senior director of video infrastructure at CBS Interactive. "There's no buffer wheels where you're waiting for the ads to load in the middle of the stream. It looks more like television."
And if SSAI makes viewers happy, it's making content publishers and distributors even happier. "The move to SSAI has opened up significant live and linear OTT inventory," says Allen Klosowski, senior vice-president of the advanced solutions group at ad serving platform SpotX. SSAI has simplified video on demand (VOD) as well, because the same technology can be deployed across all media assets. "This has quickly driven scale in multi-platform distribution and monetization for our clients," he says.
What Is SSAI?
"SSAI seamlessly inserts ads into streaming video content, allowing monetization on any device that can play video," says Andrew Broadstone, director of product management at Brightcove. SSAI works with both Live or VOD and is really the only way to have live advertising (more on that later).
Previously, ad stitching came about because of device fragmentation in which some viewing devices lacked client-side capabilities. The crux of the problem is that most current ad technologies, including programmatic trading, viewability, measurement, and interactivity, were first created for the client-side ad serving and weren't supported by SSAI. This is no longer true.
SSAI creates an individualized media stream for each unique viewer, in which different viewers get different ads. The ad break communicates with an ad decision server, which decides what to serve each particular viewer, based on information such as viewing history, demographics, and geographical location. All of this takes places on the server side.
"The thing to know about server-side ad stitching is that the video chunks for the ads and content are not literally being stitched together. All you're really doing is knitting text files together," says Xiques. "You're basically taking manifests that point to ad segments and the manifest that points to content segments and creating a new manifest that points to them both."
Defeating the Ad Blockers
"SSAI is the only way to show ads on many of the growing diversity of connected TV devices, where it is difficult or impossible to build custom clients for every device," says Broadstone. "These platforms represent a significant area of growth among our media customers. Traditional web publishers also are using SSAI more to avoid ad blockers and to improve the user experience."
"Ad blockers work by detecting ad calls that are made in the client. However, with server-side stitching, the ad call and ad stitching are performed before the stream reaches the client, meaning the ad blocker doesn't detect an ad call and therefore is unable to block the response," says David Springall, founder & CTO of Yospace, which provides server-side dynamic ad insertion for live and VOD streaming.
Preventing ad blocking is one benefit of SSAI, since the stream can't be detected as coming from a known ad-serving URL. Another benefit is being able to replace and personalize ads already embedded in a stream.
Balancing Personalization and Privacy
Magnus Svensson, media solution consultant at Eyevinn Technology, helped Bonnier Broadcasting, MTG, Discovery Networks Nordics, and Telia Co. develop a technical specification for SSAI. The broadcasters were not able to monetize online streams when distributed by an operator, since it was sending out content with the original broadcast ads with no ability to measure ad views. To start selling online advertising, they needed to make changes in the distribution workflows. "The trend in the Nordic region and in Europe now is definitely moving away from client going to server side," Svensson says.
The project eventually was extended to include all the major broadcasters in Sweden together with the operator and distributors agreeing to start doing server-side ad insertion. "We developed a technical specification highlighting how this should be done between a broadcaster and an operator starting with Sweden, but since most Swedish broadcasters are across the Nordics, it's all now starting to spread there."
Svensson says he spent an equal amount of time addressing data privacy as he did the technical requirements to implement SSAI. Telia is now able to offer ad personalization and frequency capping while anonymizing data to follow new General Data Protection Regulation (GDPR) guidelines. Telia is targeting based on approximate geographic area (since the exact area is considered personally identifiable information), content, screen size, and device type. The specification document can be found online.
"There's no real logical reason to stick to doing any client-side [ad insertion]," says Svensson. "The only thing remaining is to agree on some kind of ad tracking server side as well, because today the only way of doing proper tracking is done doing client-side insertion." The same tracking can now be done on the server side, but the measurement organizations are less comfortable with this. He adds, "The measurement institutes and ad agencies don't really trust server side, because it's opened up a little bit more for fraud that you can actually manipulate the data."
The fear of leaving ad dollars on the table was enough motivation to get the Scandinavian groups to work together. So what are the technical issues that anyone implementing SSAI needs to look at?
Handling Ad Breaks
The first step is identifying how the video player knows what's an ad and what is content. Broadcast content generally has a SCTE (Society of Cable Telecommunications Engineers) marker embedded as part of the stream, which includes information about when an ad break starts and how long it is. Traditional broadcast has two types of SCTE markers—104 for baseband (HD-SDI) and 35 for IP video. These markers are "read" and translated to OSMF cuepoint messages that are passed between server and player for content/ad stitching via discontinuity signals. But not all content has SCTE markers.
In order to support SSAI, the client needs to be able to handle HLS DISCONTINUITY tags or MPEG-DASH manifests containing multiple periods. In SSAI, you don't start and stop a stream as you do in client-side ad insertion (CSAI). Instead, the segments are delivered in a continuous stream server-side, with ad segments stitched into the manifest. DISCONTINUITY tags (or, for MPEG-DASH, multiple periods) are used to inform the player that the upcoming segments have different characteristics. The presentation time stamp (PTS) reset is one clear example; changes in frame rate end encoding are other differences that might occur between the original video and the ad segments.
"Because of how the SSAI component can in a scalable way create the virtual streams it is also required that the video player is capable of playing HLS with DISCONTINUITY tags and MPEG DASH containing multiple periods," Jonas Birme´, solution architect at Eyevinn Technology, wrote in a blog post. "These are the mechanisms in the streaming formats that makes it possible to replace video chunks in the original media stream with the ad video chunks."
The packager chunks the video stream into encrypted video file segments according to the different DRM systems and also creates the streaming format manifests. "To signal where an ad break start and ends in the case of HLS it can use the tags EXT-X-CUE-OUT and EXT-X-CUE-IN, and for MPEG DASH it creates a new period," Birme´ notes. "The SSAI component then fetches the HLS-and MPEG DASH-streams from the origin and parses the streaming format manifests to be able to create a personalized and unique virtual stream for the viewer. The virtual streams also contain the necessary information that the DRM decryption module needs to be able to acquire a license from the DRM system.
"[T]o be able to have server-side ad insertion and DRM protection you need a DRM provider that can handle more than one DRM system and an SSAI component that can handle both HLS and MPEG DASH," Birme´ concludes. "If you don't have the DRM requirement it is sufficient with an SSAI component that handles only HLS as most devices can handle HLS as long it is unencrypted."
Another Use Case
Every video publisher and distributor will have unique requirements when it comes to SSAI, and not all applications support SCTE markers.
"I work at a media company and we have rules about users not being able to skip ads, not playing an ad more than once, and requirements to do third-party tracking of ad playback. That means that there are components in our player that need to know exactly when an ad is on the screen so that seeking can be disabled in the UI and video click-through can be passed to advertiser's web sites," says Xiques. "There's no standard way of interpreting SCTE-35 markers on the 15 different application platforms that I support.
"For VOD content, some media companies incorporate a client-side ad SDK provided by the ad stitching service. The SDK typically provides an API that allows the application to know when individual ads start and end. In addition, these SDKs provide metadata about each ad that can be used for third-party ad tracking," Xiques continues.
"In the absence of an SDK, you need some sort of marker. SCTE markers can be either included in the stream itself or the SCTE markers can be included as text in the manifest. Some application platforms don't support SCTE natively. In these situations, if you are streaming HLS, ID3 tags which are native to HLS can be used," notes Xiques. "In some cases, you may need service at the encoder to translate SCTE to ID3 tags before the stream is sent to the client."
The Other AI
While there are a number of ways to find where to insert ads, advertising technology company Amagi has an ad insertion platform that programmatically identifies breaks for content that does not have SCTE markers. "We have an AI engine that can automatically identify where the ads are and replace them with a personalized ad," says Srini KA, co-founder.
"[The machine learning system] is looking at video and audio changes, and saying ‘OK, is this something I identify as an ad?' It takes an audio and video fingerprint of every frame, compares it against a fingerprint database, and says, ‘This is an ad that I already know,'" says KA. "The system learns by seeing thousands of ads and starts to distinguish ads apart from the content."
How accurate is this? "Typically the system would miss the first or second instance of the ad," says KA. "After it sees the same ad twice, then it knows it's an ad because it follows a bunch of parameters." These parameters include whether the content repeats multiple times, possibly across different channels, whether it is it short form (6 to 60 seconds), and whether the content ends with text or logos on screen.
After the content plays, the video player may refresh the user interface, take away the scrub bar, and put an ad countdown timer on screen. "When certain segments start to play, the player needs to say, ‘I'm not tracking content anymore, I've got to track these ads, and there's certain ad metadata that I need to get a hold of then and send this out to Nielsen or ComScore or whomever you're using to track this,'" says Xiques.
SSAI can take care of most of the data management and measurement attribution. What this means is that you can have a really light client and still monetize your content. That's important for platforms and devices like Roku, Xbox, and PlayStation, where "you don't want to be writing a bunch of client side code to be making just-in-time ad calls and parsing the VAST data and doing third-party tracking," says Xiques.
"It's important to view SSAI as the technique of stitching ads into content for delivery, and that there will always be complementary processes like measurement which support certain outcomes like sale of inventory," says Tim Armstrong, senior product manager for server-side ad insertion at online video platform Switch Media. It has a product called AdEase for SSAI. "Some of the encountered problems come from large tech vendors who haven't yet caught up with new solutions such as SSAI."
"While we offer server-side tracking, client-side tracking is still currently the preferred method for this," says Springall. "However, over the longer term, we predict a shift away from client-side tracking as the direct interaction be-tween device and some third-party end-points gives rise to some user privacy concerns."
The ability to target both content and advertising is one of the biggest factors differentiating OTT from broadcast and cable. "There are no technical limitations on what you can do server side; it's more what are you allowed to do for privacy reasons," says Svensson. "It's up to the operator how much data they want to reveal to do more targeted advertising."
"SpotX can do the same audience targeting with SSAI that can happen in client-side ad rendering. That includes using first- and third-party data to identify, value, forecast, and transact on defined audiences. We are integrated with over 15 different SSAI solutions," says Klosowski. SpotX claims to handle frame-accurate, data-driven ad insertion in more than a billion ad break opportunities each month in live and linear programming alone, not counting the additional VOD inventory. "For us, there isn't a big difference in targeting abilities between client side or server side, because we have similar information available in either environment," he says.
"SSAI permits the same one-to-one addressability as CSAI, but crucially gives the media owner greater control over what audience information is shared with the ad decisioning ecosystem," says Springall. In CSAI, software in the client must be integrated that directly communicates with the ad decisioning ecosystem. "This raises two issues: The first means that your client software is tightly coupled with your ad tech ecosystem. If you want to make changes to your ad decisioning vendor, you have to make changes to the client applications," he says.
"The second issue is that with so many devices that media owners need to provide support for, the cost of maintenance of implementing the solution for each device is becoming too high. That's why we're finding that media owners that have implemented SSAI for live are now turning to SSAI for their strategic AVOD [ad-supported video-on-demand] services."
SSAI is well-suited for live video because of the lower latency it offers for delivering ad loads. But how can SSAI keep up with providing unique streams in large-scale live events? "Earlier this year we reported concurrency across all our customers of over 1.5 million, with each viewer receiving their own stream," says Springall. "It's not possible to request individual ad breaks for this number of users all at the same time, so our platform paces these requests ahead of the breaks to avoid overloading the ad decisioning ecosystem (for both first and third-party ad sources)." It's safe to say, large scale personalization is not yet an option, but where is the industry moving on the ad standard side?
The VAST Horizon
The Video Player-Ad Interface Definition (VPAID), which is used mainly for desktop viewing and covers perhaps 10 percent of total video ad inventory according to Armstrong, is being phased out, and VAST has progressed to version 4. "The main change with VAST 4 has come with additional error codes, mezzanine file support, universal ad ID, a viewability node, and also supposed support for interactivity. VAST 4 also is the first time that SSAI has been included in a standard," he says.
Updates to upcoming standard VAST 4.1 should help standardize ad requests through the use of macros to propagate context more easily, says Klosowski. In SSAI, there is no VPAID ad inventory. "While VPAID will continue to be used in the near future, VAST 4.1 takes the first steps to officially deprecate its use, significantly simplifying video ad execution and improving consumer experience," he says. Also gone will be support for Flash ads. Other updates include the following:
- A required AdServingID field has been added to simplify comparing data about a video impression across the various systems involved with the delivery and tracking of the impression.
- VAST 4.1 introduces the concept of interactive templates, which work without ads being delivered with executable code, especially in mobile and OTT environments.
- Standardized delivery of closed captioning files
Simplifying Ad Delivery at Scale
As mentioned earlier, SSAI drastically reduces the need for specialized, client-side development work to ensure the best playback experience from device to device. CSAI needs to be incorporated into the client code, and this isn't a very scalable approach when the amount of devices being supported keeps growing. "[With SSAI] you can spend less time as a media owner developing custom technology for each individual platform. We have customers that support upward of 200+ types of devices and it's very difficult to develop a client-side SDK for all of those environments," says Klosowski. "All long-form content will be SSAI-enabled soon if it's not already."
Aside from the development challenges of supporting each and every variation of platform out there, CSAI just doesn't work on some platforms. "With client-side ad insertion, the mobile device needs to load two video players at the same time in memory, and additional network requests (and potential round-trip latencies) for the communication with the ad server are added. On a thin device such as a Chromecast dongle, it is not possible to load two video players in memory at the same time," says Xiques.
What's Not to Love?
Finally, on the encoding side, a single adaptive bitrate feed works with a wide variety of device data requirements for HLS and DASH. "One of the key requirements for the system to work seamlessly is to be able to transcode in [close to] real time and deliver the right bitrate based on who's watching, on what screen, what sort of bitrate are they getting, and what sort of aspect ratios and profiles they have on that device, so it looks exactly the same as the rest of the content," says KA.
So server-side ad insertion combats ad blocking, requires fewer development resources, allows for a single adaptive bitrate (ABR) feed, and enables targeted online ad delivery and better personalization at lower latency. While SSAI has found the most use as a method for ad insertion into live content, it's now gaining traction for VOD content as well. No matter whether it's live or VOD, though, SSAI is better for both viewers and publishers.
[This article appears in the September 2018 issue of Streaming Media magazine as "The State of Server-Side Ad Insertion."]
Nadine Krefetz's article first appeared on OnlineVideo.net
Companies and Suppliers Mentioned