This website uses cookies to help improve your user experience
The traditional client-side approach (CSAI) to VoD ad insertion typically goes like this:
It was an effective approach to inserting ads into VoD content, but this changed with the widespread adoption of ad blockers. With just a browser extension installed in a few clicks, users can block all requests to ad servers.
Ad blocking is now common across mobile and web environments as users increasingly prioritize privacy. According to industry analytics, approximately 16–17% of ad traffic in the US is affected by ad-blocking technologies1.
While publishers keep looking for sustainable monetization and privacy regulations tighten control over client-side tracking, server-side ad insertion (SSAI) has evolved from an ad blocker workaround into a standard approach to video ad delivery.
Key takeaways:
The SSAI (also known as server-side ad stitching) approach gives publishers a way to circumvent ad blockers by hard mixing ad media chunks with VoD content right on the server.
For HTTP-based VoD streaming (with HLS and MPEG-DASH being the most popular technologies), the flow begins with a client-side player requesting a VoD playlist and includes the following steps:
(*VPAID does not work here as the standard does not allow getting a direct URL of the ad media source.)
Currently, SSAI workflows increasingly rely on cloud-based architecture, with dynamic manifest manipulation occurring at the CDN edge. This significantly reduces latency and enables real-time ad decisioning even for high-traffic events or personalized ad experiences on live streams.
Moreover, many modern OVPs now support SSAI-aware SDKs on both web and CTV platforms, resulting in smooth, secure, and standards-compliant playback aligned with VAST 4.2 and Open Measurement 2.0. These capabilities let publishers deliver SSAI ads seamlessly across devices and networks, supporting consistent monetization even in ad-blocked or limited-tracking environments.
At a high level, SSAI moves ad insertion from the player to the server side. Instead of requesting and rendering ads separately, the player receives a single continuous stream where ads are already stitched into the content.
When a user starts playback, the request goes through a server-side component. It determines where ads should appear and selects the creatives. The server then prepares a modified stream, inserting ad segments directly into the video timeline before sending it back to the player.
From the player’s perspective, there is no distinction between content and ads. Both are delivered as part of the same media stream, with ad playback more resilient to ad blockers and less dependent on client-side execution.
While the concept of stitching ads into video streams may sound simple, the actual architecture behind SSAI is made up of several interconnected components working in real time. Understanding this flow helps clarify where personalization, tracking, and optimization occur in the pipeline.
Depending on the streaming setup, these components can be run in a centralized cloud environment or distributed closer to the user via edge computing. The flexibility of this architecture makes SSAI suitable for both VOD and live scenarios, especially in high-demand contexts like sports or prime-time shows.
We built a platform that brings together ad inventory management, targeting, and analytics to help publishers and advertisers get better results from video advertising.
Reliable and accurate tracking is essential for measuring advertising performance. In SSAI, tracking events are typically handled in two ways.
We could try using a custom client-side player add-on to handle instructions from the proxy server in a custom format. It’s a fail-safe tracking method, since the add-on can precisely trace the required user actions mapped to the VAST document’s tracking events.
On the downside, this arrangement requires a unique add-on for every popular frontend player out there. With the variety of players that different publishers utilize, this additional burden severely undermines the flexibility of SSAI integration.
Today, some vendors attempt to reduce this complexity by offering SSAI-aware SDKs that natively support tracking event injection into existing AdTech analytics workflows. However, these SDKs are not yet universally adopted across major HTML5 and CTV players, which means the need for custom integration work still persists in many cases.
Since we are playing HTTP-based streams, we can also track server requests to corresponding chunks or playlists, as well as calculate user behavior that needs to be tracked. Currently, this approach to tracking seems to be universal, and our AdTech professionals have tested it in a number of projects:
The structure of the HLS VoD playlist file only allows tracking requests to ad media chunks. In practice, this means tracking is largely limited to buffering-related requests from the client, with most events inferred from these interactions. As a result, advertisers receive only an approximation of ad performance.
For these reasons, modern SSAI implementations use server-side beaconing, hybrid tracking, and SSAI-aware analytics platforms to improve measurement accuracy.
The latest versions of the MPEG-DASH standard include a playlist tagging feature, which allows transparent server-side tracking by leveraging the remote element functionality.
When generating a mixed SSAI MPEG-DASH playlist, this feature allows injecting as many HTTP requests from the client-side player as needed to reach the required tracking precision.
In tracking these requests, the server needs to utilize predefined logic while translating the necessary tracking events from the previously parsed VAST document (such as quartiles, midpoints, etc.)
Our research on MPEG-DASH server-side tracking under various conditions showed mixed results. While the native Android player performed well with all the instructions, support varies across players, and although modern SSAI implementations incorporate hybrid tracking approaches, achieving consistent measurement accuracy remains challenging.
It seems, therefore, that until popular JavaScript players provide more complete MPEG-DASH specification support, proper SSAI tracking will remain a challenging task.
In recent implementations, some platforms combine both tracking methods, injecting server-side beacons and synchronizing them with limited client-side logic using event bus mechanisms or cloud-based analytics. This hybrid model improves precision while keeping the client code minimal and compliant with privacy regulations.
Another growing trend is the use of SSAI event logging via CDN edge functions, which can intercept and log HLS or DASH manifest and segment requests in near-real time, reducing backend load and improving ad viewability estimates.
Ad targeting typically relies on persistent user identifiers linked to behavioral and contextual data. In server-side dynamic ad insertion, ad requests are made from the proxy or stitching server — not directly from the end user’s device, which creates challenges in maintaining accurate user profiles.
To preserve relevance, unique user IDs can be stored in a backend database and used in proxy-initiated requests to ad platforms. However, this setup limits visibility into user behavior across multiple sessions and touchpoints.
Modern SSAI workflows address this with advanced ID resolution techniques and context-aware targeting models. These include the use of first-party identifiers enriched by customer data platforms (CDPs), as well as probabilistic or deterministic matching mechanisms that operate within privacy-compliant frameworks.
In cases where user-level targeting isn’t feasible, advertisers often rely on contextual signals, such as device type, content metadata, or geolocation, to optimize ad selection. While this may reduce the granularity of personalization, it improves compatibility with privacy-first architectures and ad delivery at scale.
We build SSAI-powered video platforms with advanced monetization and analytics.
After viewing an injected ad, a user can rewind the video and view it again, start viewing the ad from the middle, or perform other actions outside of the traditional client-side flow. In such situations, server logic must be carefully crafted to avoid tracking multiple views for one requested ad and skewing the viewing stats as a result.
MPEG-DASH remote elements with the onRequest property can provide additional flexibility around tracking multiple views, but keep in mind that any ad injection requires time for transcoding new media.
That’s why a streamlined SSAI implementation must identify the already transcoded ads and pull them directly from local storage. This method would serve well for pre-rolls and other critical cases when there is no time for transcoding before the playlist is transferred to the client.
Some modern SSAI platforms implement media fingerprinting and ad delivery caching mechanisms to further prevent accidental double-counting. By assigning a persistent ad ID to each unique impression and tracking it across rewind, pause, or seek events, they maintain data accuracy while improving user experience.
Additionally, real-time deduplication layers at the analytics backend help reconcile tracking signals and prevent repeated playback of the same ad within a short session window from inflating campaign metrics.
The release of VAST 4.0 in 2016 significantly improved support for server-side dynamic ad insertion, introducing features like raw mezzanine files and Universal Ad IDs. These standards allow for higher-quality transcoding and more reliable ad identification across workflows.
Today, VAST 4.x is well established in CTV and FAST environments, while VAST 3.x persists mainly as a legacy fallback in some ecosystems. Adoption is largely mature in premium video, though fragmentation remains across ad tech platforms and vendors.
Leading OVP vendors, such as Brightcove and Kaltura actively support SSAI. At the same time, Google Ad Manager (formerly DoubleClick) support VAST 4.x and server-side ad delivery workflows, helping drive standardization.
Since then, VAST 4.2 and related standards such as OM SDK 2.0 have expanded measurement capabilities in SSAI environments even further. Key industry players now treat SSAI advertising not as a workaround, but as the default approach for scalable, privacy-respecting video ad delivery, especially in CTV and FAST channels.
Major streaming platforms, ad servers, and measurement providers have built native support for SSAI event signals and impression deduplication. Tools like SCTE-35 markers, Open Measurement-compatible analytics, and SSAI-ready creative templates are making ad stitching smarter and more interoperable across the ecosystem.
All in all, there is little doubt that SSAI is here to stay.
Turn SSAI into a reliable monetization engine with AdTech platforms built on 20+ years of online video experience across VoD, CTV, and FAST.
1. Global Insights for Adblock Usage — Adblock Analytics
CSAI delivers ads separately from the video stream, and the player is responsible for requesting and rendering them, which allows detailed tracking and interactivity but exposes ad calls to blockers.
Server side ad insertion SSAI inserts ads on the server before the stream reaches the player, so playback happens as a single continuous stream, and tracking and targeting are handled differently.
SSAI is harder to block because ads are delivered as part of the video stream than through separate requests, so common browser-based blockers have fewer signals to detect. Network-level filtering and platform restrictions can still affect delivery in some cases.
SSAI removes client-side ad requests, which are the main target for blockers, so there are fewer opportunities to detect and filter ads. It also reduces playback issues because the player does not depend on loading ads separately.
The server does not have direct access to user actions such as play, pause, or seek, which limits tracking accuracy, and in HLS most events are inferred from segment requests. MPEG-DASH supports more precise tracking, but player support varies, especially in browsers, and additional challenges include latency, transcoding, and targeting without client-side identifiers.
The impact depends on the platform and audience, but industry analytics shows that in some markets around 15-20% of ad requests are affected, which reduces impressions, lowers fill rates, and directly impacts ad revenue.
