VPAID support

VPAID (Video Player Ad-Serving Interface Definition) is an interface allowing the integration of video players and ad units. Support of this technology increases the chances of getting impressions if the supply source supports VPAID. Because in this case the player runs a waterfall inside the pub’s player and aligns the technology stack when serving VAST tags. What's important to know is that it's about rendering demand VAST tags properly.

This feature does not affect vast to RTB connection, because in this case DSP/adverts often send the responses with the player inside just orienting on OpenRTB ‘API’ field and JS support.

Smarthub side

 

  1. A request for a video ad (OpenRTB or VAST) is received from an SSP.

  2. Checking if VPAID technology is supported

    1. For OpenRTB endpoints, a request must contain the values ​​1 or 2 in the 'api' field of video request

    2. For VAST endpoints, there must be [API] macro:

      The VAST request must contain that macro replaced with VPAID value as following:
      &api=VPAID
      This macro allows Smarthub to send a VPAID player that runs waterfall and ensures correct video serving.
      In case the macro is not sent, we will bid without the player, which lowers the chance to get video served correctly.

3. Repacking the request and send requests to filtered DPSs

4. Receiving all responses and processing the auction.

5. If VPAID is not supported

1. Generating a hash with the winning price (including margin and auction fee depending on auction type)

2. Inserting URLs for impression.

3. Sending a response with one type of ad.

If VPAID is supported

1. Collecting all responses in a list for the player.

2. Sending response to SSP

3. The highest price wins

4. The assembled list of responses is sorted by price from higher to lower.

5. Sending a response with our player and hash for the first video from the list.

 

Publisher side

 

How does the player work:

1. The player requests the next video via a hash

2. The server marks that the ad with current hash is no longer relevant, removes the impressions (so that they would not be able to request the next ad and make the impression for the previous ad)

3. The server gets the data of the next advertisement (if any).

4. Generating a hash with the price of the DSP (including margin and auction type)

5. Inserting URLs for impressions

6. Sending a response with an ad and hash to the next result

If the player is playing a video:

1. The impression is called

2. The server deletes all subsequent ads (so that they could not request the next after an impression)

If for some reason the player cannot play an ad and there is a hash to the next video, it all begins from step 1

 

We do not bid with VPAID if:

1. There is a CTV player (Device type 3, 6, 7)

2. There is no API parameter confirming VPAID (there’s no ​​’1’ or ‘2’ values in the 'api' field of OpenRTB-specified requests, or no API macro in VAST request), and there is no 'application' or 'javascript' values in the ‘mime’ object of the OpenRTB request.