Key concepts

Discover the terminology and set of features related to DAI services at a high level

Different ad insertion service types

A DAI Service is defined by two uniquely identified sources:

  • a content source : either live or asset catalog type
  • an ad server source (ad server type) that will return VAST or VMAP files.

Depending on the type of source, you can set different ad insertion service types:

Ad insertion typeBehaviorSource type
Pre-roll onlyInsert an ad break before the content starts playing. This ad insertion type requires the ad server to return a VAST payload that lists the ads to insert.Live source or Asset catalog (VOD)
Pre-roll, mid-roll and post-rollInsert ad breaks before, during and at the end of the content. It requires the ad server to return a VMAP payload to identify the ad break placement and list the ads to insert, or the use of the Ad Proxy.Asset catalog (VOD)
Ad replacementIdentify ad break opportunities in a live stream thanks to SCTE35 markers and insert alternative ads provided by VAST requests to an ad server.Live source with SCTE35 markers

Live pre-roll and live ad replacement are compatible and can both be activated within a same service, i.e. a single video stream.

You can find more information about the three types of ad insertion in the Use cases section. The rest of this article presents some key concepts that are necessary to understand in order to fully benefit from DAI services.

Ad Server

An Ad Server is the service/component that programmatically decides which ads and which pod (sequence of ads) should be returned when receiving a request from a Server-Side Ad Insertion (SSAI) service like An Ad Server is generally part of an SSP (Supply Side Platform) and typically communicates with a DSP (Demand Side Platform) to match offers from advertisers. communicates with Ad Servers through protocols standardized by IAB. This does not depend on the ad server used as long as this ad server can interface through the API using VAST (in the case of a live or pre-roll for asset catalogs) or VMAP (in the case of a VoD asset catalog).

Ad Decisioning

It is important to understand that ad decisioning is the remit of the ad server, not the SSAI solution. The ad server will use data from multiple sources, including data that transits through from the players.

A typical data flow looks like the following:

Programmatic Advertising Targeting (11)..png
  • The playback request comes from the player/app (bottom right). The request comes with headers (such as IP address, user agent, etc.) and optionally with query parameters (with metadata such as identifiers for content, user, device and/or any other contextual data).
  • The request goes through the CDN to Those headers and parameters must be retained and forwarded by the CDN.
  • uses information from headers and query parameters and maps them to headers and/or query parameters that are sent to the Ad Server on the VAST call. Additional information extracted from the source content (in particular from SCTE markers) can also be added to this mapping. The mapping is configurable in the service (see below).
  • The ad server uses the information to evaluate its targeting rules, perform the ad bidding (if using programmatic) and essentially determine which ads to serve. It is common for the ad server to retrieve and/or use additional data acquired from DMPs (usually for audience segmentation) and from the CMS (typically content metadata). The way it obtains that data is generally specific to each ad server.

In such a typical flow, the SSAI is only responsible for the mapping and transit of data that it receives from the client-side. No decisioning is made about whether to insert ads or not, what type of ads, or even which SSP to send requests to.

Ad Tracking

Regardless of whether the ad campaigns are sold through Direct or Programmatic, the SSP is also the service/component which collects the ad tracking beacons (typically quartiles from 0% to 100%) to collect ad impression metrics.

Configuration in

Within, an ad server is defined as a source with the Ad server type. Here is an example of an Ad Server definition:


Pre-integrated Ad Servers

You will soon be able to select some pre-integrated Ad Servers. In this case, the corresponding queries will already be filled in as a default template so that you will not have to worry about this part. Stay tuned!

In the meantime, if you cannot find the appropriate query parameters in the Ad Server documentation, feel free to contact our Customer Success through the chatbot, for instance. We will do our best to impress you (and your ads of course ;-)).


IP Whitelisting

For security and ad fraud reasons, some Ad Servers require the SSAI service (here, to be whitelisted to access their backend API. If so, don't forget to add the IP addresses specified in this section to unlock communication.

Passing information to the ad server

The ad server query parameters shown in the screenshot above are optional. They can be static or dynamic. They are typically used to ensure that the VAST or VMAP request can be properly identified and processed by the ad server, and that relevant data for ad targeting coming from the playback environment can be passed to it.

Query parameters sent by the end user client are a defined set of parameters attached to the end of a URL behind the ? mark and separated by the &. They are extensions of the URL that are used to help define specific contents or actions based on the data being passed.

Several types of query parameters can be used with

  • Hard coded query parameters : they have always the same value. These values can be set directly in the Source configuration in E.g.: w=1920&h=1080 or app_bundle=588207
  • Dynamic query parameters from client: these parameters come from the request coming from the client player or app, as headers or as query parameters from the request URL and are typically used to pass user and content metadata. E.g.: ua=$http_user_agent or content_id=$arg_video_id
  • Dynamic query parameters from those are generated by our platform, with system values, for instance cb=$MMVAR_CACHE_BUSTER will append them in the VAST or VMAP request sent to the Ad Server.

The following streaming URL shows one of the simplest query parameters that can be used to stream a service :

More information on these options can be found in this article

Ad Proxy

There are times when the payload returned by the ad server does not fully meet the requirements of your use case. provides functionality to tune the integration with the ad server.

AVOD Scheduling

Ad insertion in AVOD scenarios generally require the ad server to return a VMAP payload, which essentially contains a schedule telling the system in charge of inserting the ads (in this case, at what point in the asset timeline to perform the insertion.

However, not all ad servers are able to return such a payload. If your ad server returns a VAST payload, it will only be used as a pre-roll.

Luckily, the Ad Proxy feature can be used to dynamically generate such a schedule of ad opportunities and interact with the ad server’s standard VAST tags to fill them. You will find more information on this feature in Ad Proxy for AVOD ad scheduling

Transcoding option

An ad insertion service is a combination of a VOD or Live source and an ad server that indicates ads to insert. For the insertion to be effective, the encoding of the source and that of the ad must be compatible. allows you to specify optional transcoding settings for creatives that are not encoded yet. A transcoding profile will detail the way a mediafile should be encoded: layers, resolution, bitrate, codecs, etc.

When creating an ad insertion service, you have the choice to activate the transcoding option and choose a relevant transcoding profile (see here to check how to create a transcoding profile).

  • If deactivated, will fetch the already prepared ads using the ad creative URL returned in the Ad Server response. This typically matches the ad inventory Direct Sales mode.
  • Conversely, if activated, transcodes all new ad creatives with the transcoding and packaging settings specified in the transcoding profile.

Transcoding ad creatives gives you the confidence to maximize and control end user QoE. This is an important feature in the case of Programmatic ad sale, as ad creatives are selected on the fly through real time bidding exchanges or market places without any guarantee in terms of quality or consistency with the ABR profiles used by your streaming services.

Ad breaks and gap filler

Ad replacement is a service type currently only available for live streams. The principle of ad replacement is to insert ads during time periods identified in the live source manifest. Streaming standards are using SCTE35 markers for such identification.

When an ad replacement happens, requests to the ad server an ad sequence that matches the duration of the breaks. Often, inserted ads can not perfectly match the duration of the ad break. The remaining seconds between the end of the last ad and the end of the ad break can be filled by a Gap Filler.

The gap filler is based on a Slate source already declared in You may use promotional content such as a logo to leverage and promote your brand or any other service package.

Server-Side Ad Tracking

Ad tracking with can work with a Client-Side Ad Tracking system, which uses a tracking link between the player and the Ad server. In this case, the platform won't be part of the ad tracking workflow.

But if players can not handle ad tracking, provides an Server-Side Ad Tracking (SSAT) system that can be activated when creating any ad insertion service. In this case, the platform sends beacon requests to the ad server to declare which part of the ad has been returned to the player: impression, start, 25%, 50%, 75% and complete.