Ad Tracking in Server-Side Ad Insertion (SSAI)

Sanjeev Pandey
5 min readApr 30, 2020

In this post I will be explaining the workflow of tracking of ad playback and user-engagement with ads by Server-Side Ad Insertion providers.

If you are looking for a place to start with understanding Dynamic Ad Insertion I recommend you read this great article by Eyevinn Technology.

Different types of Ad tracking tags in VAST Ad manifest

The need of Ad Tracking

To allow advertisers to serve different ads to individual viewers, DAI providers need to gauge audience insights and ad campaign performance, which enables the ad server to take decisions and make adjustments to optimize campaign performance in real-time. This gauging of behavior is done through a direct feedback-loop known as ad tracking — and it lets the ad server perform the function of an ad decisioning system.

What is tracked during an ad playback?

The first thing any publisher/ advertiser would like to know if their ad was delivered to a system, and if yes then secondly did it play successfully or not?

In current times when playback is based on chunk-based streaming, led by HLS and MPEG-DASH, the ads inserted are also in form of either of these two formats and hence have chunks (aka segments) of media stitched between the content playlist.

Since the digital video ad insertion practices are derived from IAB guidelines and they use the ad manifests formats standardized by the same, the tracking of ads also follows IAB’s Video Ad Measurement Guidelines (VAMG).

Under VAMG, ad trackers are placed within the ad manifests itself and are parsed by the Manifest Server during ad resolution.

A simple VAST 2.0 Ad Manifest

The ad manifests has the following events and interactions to be tracked during playback:

For VAST Ad Manifest:

Ad Impression: Tracker is fired when the first segment of ad is downloaded from server

Ad Start and complete: When ad starts to play and when it completes playing

VAST: Ad Interaction and Playback Tracking

Ad Quartiles (Played %): Fired at 25, 50, 75 and 100 % of ad playback completion

Ad Interaction: Pause, mute, collapse, expand, resume, rewind, close, acceptInvitation, ad click (clickThrough or clickTracking)

Ad Extension: Additional beacons added by publisher under ‘extensions’ XML tag

For VMAP Ad Playlist: Start and end of an ad break

As we can see, an impressive lot of real-time feedback is collected to make the ad viewing experience more personalized and engaging for viewers.

Modes of tracking: How does ad tracking work?

The ad trackers (aka beacons) sent to ad server, beside helping the ad server make optimizations, also power up ad analytics dashboards required for making informed business decisions by ad ops teams and executives. This makes role of ad tracking critical in video streaming business and that is why there can be no discrepancy between the story told by the tracked data and the consumers of this technology — viewers and advertisers.

Ad analytics & impression data affect the click-through rate (CTR) and ultimately the CPM (Cost per Mile i.e. Cost per thousand impressions) for the publishers.

Some cases of discrepancy where manifest server is firing the ad trackers:

The impression beacon is fired by manifest server to ad server/ other 3rd party analytics server as soon as the first segment is downloaded by the player, but the player may or may not have actually finished downloading and have played the ad.

Another case is when a midpoint (50% playback complete) quartile event tracker is fired by server when half of the ad segments are downloaded but player actually did not play the segment due to network conditions.

Both of the above situation lead to firing of an event tracker when the event didn’t actually occur, this leads to discrepancy in data. So, to make sure the ad tracking captures the data accurately ad insertion providers support different modes of tracking:

  1. Server-side tracking: Server fires the trackers by identifying the events
  2. Client-side tracking: Client fires the beacons based on playhead position
  3. Hybrid Tracking: Client lets the server know when to fire a beacons and server fires it

Server-Side Ad Tracking

Manifest server obtains the ad manifest and it knows which event will occur at what time by resolving the ads and cue-markers in asset playlist. Server makes HTTP/s calls to the URLs listed for the events on event triggers. Note that for a given event there can be one or multiple beacons to be fired.

Client-Side Ad Tracking

In client-side ad tracking the player is responsible for firing the tracker. In SSAI, the player only gets the combined (ad stitched) playlist and will not have the ad manifest which contains tracking data. So, in order to fire trackers from client, the player gets the list of tracking URLs from manifest server as a sidecar file.

The sequence of HTTP calls between player and manifest server looks like this:

Client-Side Ad Tracking: Sequence of calls to obtain sidecar with tracking data (Reference: Adobe Primetime)

Once manifest server returns the tracking data sidecar file, a JSON or XML, with ads stripped and a flattened timeline e.g. containing start and end time of playback, giving list of tracking URLs to be fired at different times, player can fire these beacons based on playhead position and reading from the tracking data timestamps.

Hybrid Ad Tracking

Hybrid ad tracking combines the best of both, server-side and client-side ad tracking, where client sends HTTP signal on actual events to server to let it know when to fire the trackers.

Thanks for reading! To know more about Dynamic Ad-Insertion and video streaming/ engineering related topics, or collaborate on new Ad Insertion integration and Ad systems development project, feel free to drop a note.

You can clap up to 50 times per post! If you liked the article, please support it with claps 👏. Cheers!

--

--

Sanjeev Pandey

Co-Founder of <indvideotech> community for Video Engineers in India. Solution Architect, Full-Stack Developer, Ad Insertion Evangelist, and Think Tank.