The traditional client-side approach to VoD ad insertion (CSAI) typically goes like this:
- The browser sends a request to an ad server.
- The ad server responds with a VAST or VPAID document containing the link to an ad creative.
- The client-side player shows the ad in a specified position on the video timeline.
It used to be an effective and straightforward way of injecting advertising media into VoD content — up until the ad blockers came along. A simple browser addon installable with a few clicks makes it possible to easily block all requests to ad servers.
Today, ad-blocking technology is no longer just a desktop browser issue — it has reached mobile, CTV, and even in-app environments. According to Statista, over 900 million devices globally are now equipped with ad blockers, with CTV ad blocking becoming an emerging concern for AVOD and FAST platforms.1
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 to a strategic technology at the core of modern video ad delivery.
That leaves advertisers and publishers scrambling for a better solution.
What is server-side ad insertion?
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:
- Redirect all VoD playlist requests to a special proxy server.
- From the proxy, request the VoD playlist from the VoD server.
- Determine the number of ad insertions needed and request a VAST* document from the ad server. (This step should include the retransfer of the targeting data from the client side, which will be discussed in more detail below.)
- Get the VAST response from the ad server, parse the instructions, and find the URLs of ad media sources.
- Transcode the media files into the format of the VoD stream and push them to a CDN.
- Mix the original VoD playlist with the newly created playlist containing ads.
- Send the new playlist to the client-side player.
(*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, ensuring that playback is smooth, secure, and compliant with new advertising standards such as VAST 4.2 and Open Measurement 2.0. These capabilities enable publishers to deliver SSAI ads seamlessly across devices and networks, ensuring consistent monetization even in ad-blocked or limited-tracking environments.
Server-side ad insertion architecture overview
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.
- Ad Decision Server (ADS)
Evaluates each ad opportunity based on predefined rules, user identifiers (if available), and contextual signals. Returns a VAST response with suitable creatives.
- Manifest Manipulator
Intercepts playlist requests (HLS or MPEG-DASH) and dynamically rewrites manifests to insert ad segments in the correct positions.
- Transcoding Layer
Takes mezzanine or high-quality ad files and transcodes them into the exact format, bitrate, and resolution required by the main content stream.
- CDN and Edge Delivery
Delivers both stitched content and ad segments with minimal latency. Some setups allow real-time manifest rewriting at the edge for scalability.
- Analytics Connector
Handles the generation of tracking beacons, event logging, and reporting — often across both client and server sides.
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 a strong fit for both VOD and live scenarios, especially in high-demand contexts like sports or prime-time shows.
The uphill struggle of tracking ad usage events
It’s a truth universally acknowledged that adverts are nothing without well-established and nuanced tracking. Currently, there are two ways to process tracking events in SSAI.
Client-side player add-on
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 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.
Server-side tracking of stream consumption
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:
- HLS streaming
The structure of the HLS VoD playlist file only allows tracking the requests to ad media chunks. In practice it means tracking nothing but buffering requests from the client and basing all tracking events on buffering actions. What advertisers get as a result is merely a rough approximation of ad usage numbers.
- MPEG-DASH streaming
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.)
Having researched MPEG-DASH server-side tracking under various conditions, we were not particularly encouraged by the results. While the native Android player performed well with all the instructions, the support for remote elements in popular JavaScript players leaves much to be desired.
It seems, therefore, that until the popular JavaScript players provide full-fledged MPEG-DASH specification support, proper SSAI tracking will remain a daunting 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.
Limitations in ad targeting
Ad targeting typically relies on persistent user identifiers linked to behavioral and contextual data. In server-side 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 ensures higher compatibility with privacy-first architectures and ad delivery at scale.
Multiple impressions and media reuse
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 ensure that repeated playback of the same ad within a short session window does not inflate campaign metrics.
Industry support and the future of ad stitching
The release of VAST 4.0 in early 2016 brought support for server-side dynamic ad insertion. New features like raw mezzanine files and Universal Ad IDs enable high-quality transcoding and easy identification of ads. The support for such features as raw mezzanine files and Universal Ad IDs makes it possible to request the highest-quality video file for further transcoding as well as easily identify the already transcoded ads.
Despite its advantages, the adoption of VAST 4.0 remains a relatively tentative process. Many advertisers and publishers stick to its popular predecessors, VAST 1.0 and VAST 2.0, waiting for each other to pick up the new standard first.
Even so, things have been moving in the right direction: OVP vendors — such as Brightcove and Kaltura — are actively promoting SSAI while DoubleClick announced VAST 4.0 support in May 2017.
Since then, VAST 4.2 and related standards such as OM SDK 2.0 have expanded server-side capabilities even further. Key industry players now treat SSAI not as a workaround, but as the default 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.
Oleg Gubin
Presales Specialist at Oxagile
Sources
1. Statista — Number of devices using ad blockers worldwide from 2013 to 2024.
