This playbook explains how to configure SpringServe as a VAST ad decision server (ADS) in a broadpeak.io Dynamic Ad Insertion (DAI) workflow for Live content.

You’ll learn how to:

• Configure SpringServe as an ad server source.
• Determine how to map the SpringServe macros.
• Validate ad insertion and tracking in a live stream.

Prerequisites

Before you begin, ensure you have:

• A broadpeak.io account, and access to the Web App
• A SpringServe VAST tag

  • This may have been provided to you by a colleague or a content partner

  • However if you have your own SpringServe account, you can easily get one from the SpringServe console, which provides a handy interface to be able to choose macros and export the URL

    

Overview: Live DAI Flow

• SCTE-35 markers in the live source signal the start of an ad break.
• broadpeak.io detects the cue and calls the SpringServe VAST tag URL, substituting macros.
• SpringServe returns a VAST response with the appropriate creatives.
• if necessary, broadpeak.io transcodes and packages the ad creatives
• stitches ad segments into the live stream manifest.
• playback resumes seamlessly after the ad break.

Configuration

Step 1 - Create an Ad Server source

In the broadpeak.io WebApp:

• Go to Sources → Create new.

• Choose Type: Ad Server.

• Fill in:

  • Template: Custom
  • Name: SpringServe VAST for Live Ad Replacement

• URL: paste the SpringServe VAST URL

At this point, a table will be pre-filled with all query parameters from that URL. When working with ad servers and VAST tags, those are usually known as macros.

Mapping macros

The main task now is to correctly map the macros by modifying that table, which entails determining

1. what macros to include, and
2. where their values will originate from.

There is no single answer to both of these questions - much will depend on your individual circumstances, how your SpringServe account is connected to the supply side, the type of devices your users will play content on, and many other factors that broadpeak.io does not control.

In the remainder of this page, we will document a standard set of macros that are usually found. For each of these macros, we provide the typical configuration of the mapping that you can apply in the aforementioned table.

The most common ones are:

• w and h - width and height of the player, primarily used in modern streaming to provide an indication of the aspect ratio of the content (rather than exact dimensions for the creatives).
  • In most circumstances, they can be set as a static value
    → type:Custom & value: 1920 and 1080 respectively for typical 16x9 content.
• cb - cache buster, a random value to prevent caching of the VAST response
  • broadpeak.io will ensure that a random value is sent on each request
    → type:From Variable & value (from dropdown): Random value (to prevent caching of request).
• ip - IP address of the end-user
  • This information comes in the headers of the streaming request. broadpeak.io will forward that header automatically, which means this macro is not strictly necessary. However it can also be surfaced in the query parameters
    → type:From Variable, value (from dropdown): IP address of the client (end-user) device
• ua - User agent of the end-user's device
  • This information comes in the headers of the streaming request. broadpeak.io will forward that header automatically, which means this macro is not strictly necessary. However it can also be surfaced in the query parameters
    → type:From Header, value: User-Agent

There are a number of macros that control the number and duration of the ads returned by SpringServe

• pod_max_dur - Used to set the maximum duration of the ad pod returned by the ad server (in seconds)
  • In a Live Ad Replacement scenario, this should be the duration of the ad break, which broadpeak.io can dynamically fill
    → type:From Variable, value (from dropdown): Duration of the ad break (in seconds)
  • For Live Pre-roll and AVOD scenario, it is up to you whether to use it to apply a constraint, in which case you will probably want a static value
    → type:Custom, value: 90 (for a maximum of 1 min 30s of ads)
• pod_ad_slots - Generally used to set the maximum number of ads returned in the pod.
  • It's rarely necessary to set this macro, but tends to appear by default in the VAST tags exported from SpringServe. You can therefore remove it, or set it to a custom value.

You usually also need to provide information about the site or app that the request comes from. There are a number of typical macros used for this

• url - For web players, this is typically the domain name of the website, though sometimes you need to pass the full URL to the page containing the player.
  • In typical circumstances this can be set as a static value
    → type:Custom, value: mywebsite.com (adapt as necessary with your own)
• app_name, app_bundleand app_store_url (and sometimes appVersion) are used for mobile and CTV applications
  • Again, you likely will want to set static values for those
    → type:Custom, values: myvideoapp, com.mine.myapp, https://play.google.com/store/apps/details?id=com.mine.myapp&hl=en_US respectively (adapt as necessary with your own)
  • In more complex scenarios, such as if you have multiple apps using the same ad server endpoint, you may want to pass them from equivalently named query parameters present on the streaming request from the player. The easiest way to do this is to establish a forward rule:
    → name: app* & type:Forward

Next, you need to pass macros that identify the main content. Here again, there are a number of options possible, depending on the circumstances

• For Live channels, you typically would pass
  • channel_name with the name of the live channel, which would typically be configured as a static value
    → type:Custom, value: mylivechannel
  • content_livestream with a static value of 1 to indicate that it is a live stream
    → type:Custom, value: 1
• There are also a series of IAB recommended macros to pass, such as content_id, content_episode, content_title, content_series, etc. Those are more typically used in VOD scenarios, but can also apply to live content (in particular in catch-up scenarios). Those values are normally provided by the player as query parameters in the streaming request, and the simplest thing to do is to forward them:
  → name: content_* & type:Forward

References

For more information on the typical macros supported by SpringServe:

• SpringServe Macros in the Magnite Help Center

For more information on the broadpeak.io concepts involved:

• Ad server & macros