Basic Video Ad Request and Double Auction in Video SSP

See also:

 

About video advertising

  • Video ads are not static but consist of a certain playtime (usually 5 to 30 seconds).
  • Video ads play at the same position on a web page like the video content just at a different time (prior, in between or after content).
  • Video ads (creatives) can consist of more than one asset (compared to wallpaper or companion ads in display advertising).
  • Video ads have special properties (play time, bit rate etc.) and can have different formats (Flash, MPEG etc.).
  • Instead of the browser now the video player controls the ad requests and the ad response from the ad server.

 

About video tags

  • The ad server uses dedicated tags for video requests.
  • To display ads for this placement in your videos, the ad tag URL must be trafficked in your ad serving platform.

    Note: The ad tag URL contains a cache-breaking field that must be replaced at runtime.

    Note: If you cannot, remove cb=[CACHE_BREAKER] from the ad tag. EMBEDDING_PAGE_URL may be left as is or omitted.

  • The initial ad server response is a VAST or VAST+VPAID compatible XML document document and not the ad itself. The information about the ad(s) to be played is inside the VAST response of the ad server that contains the URL of the video ad (creative), e.g. pre-roll ad.
  • The Video player then calls the URL of the video ad from the ad server.

    Note: If you ad serving platform is Video SSP, ensure you have place the JavaScript domain verification code in the header of each page, that is calling Video SSP tags. For detail, see How to Add the JavaScript Domain Verification Code to a Web Page.

 

About Trust but Verify

  • Trust but Verify (TbV) is a Video SSP feature that enables partners to provide their own parameters and information about a given ad opportunity in order to receive a faster response.
  • Player size and viewability are two values that every buyer wants to know and are required to make an accurate assessment of whether or not there is an ad that will deliver to a given opportunity.
  • To pass the information, the use of a macro is required. For details, see Common Ad Server macros.
  • To optimize ad delivery for auctions using Historical measurements (last 7 days) in TbV Viewability settings, overrides all other viewability configurations. For details, see Trust but Verify viewability settings.
  • From reporting, most of the “Double Auction Reason” points to “Viewability”. Viewability mismatch can occur due to reasons such as click to play videos, or user actions like moving to a different tab or scrolling etc.
  • You can take following actions:
    • Verify if the player is set up as click to play which may impact viewability measurement.
    • Create and access your own reports.
    • Track down, why your ad was double requested. See also, Reasons to Filter Ad Opportunity.

Note: There is a plan to release a code library to include the pi.viewable value automatically.

 

Video Ad Requests in Video SSP

Basic ad request

A video ad request takes place when a user opens a website with a video that starts automatically or when the user starts to play a video, and the video player requests a creative from the ad server.

Note: The Video SSP ad response complies with VAST 2.0, VAST 3.0 and VPAID 2.
For tag requirements, see Platform Integration Options for Publishers and Video Ad Tags Implementation.

 

Double auction ad request

  • To run an auction, the video player must support VAST+VPAID ad tags. In this case, the video player sends pre-bid parameters with the basic ad request (Pre-bid Auction) and Video SSP is assuming that the values sent reflect the truth.
  • However, to ensure the winning ad really matches the tag requirements, the Video SSP ad server attaches VPAID code (javascript) to the ad response. The VPAID checks, if the values (size and viewability) requested by the video player match with those detected by VPAID or not.
  • In case of a mismatch, the VPAID sends a new ad request (Second Auction) to the Video SSP ad server with detected values and the video player requests a second time a creative from the ad server.

 

Trust but Verify Double Auction Ad Request process

This table describes the basic sequences of a Double auction ad request in Video SSP:

Stage

Description

Data Flow

Starting point

Depending on the implementation the video starts automatically, or the user clicks the start button of the video player.

Video start auto or user initiated

Basic ad request

(Pre-bid Auction)
  • The video player requests the pre-roll ad from the Video SSP ad server.
  • This request includes pre-bid parameters required to run auction in Video SSP.
  • Basic parameters required in the ad request to run auction (VPAID inventory):

Tag Type

Trusted Player Parameters

Other Parameters

Desktop

pi.width, pi.height, pi.viewable

pageUrl, cb

Mobile Web

pi.width, pi.height, pi.viewable

a.ip, a.ua, pageURl, cb

 

VAST+VPAID ad tag with pre-bid parameters

Ad Server runs an auction
  • The Ad Server takes the parameters sent with the ad request for granted.

    Note: Same parameters are used to send RTB requests, as applicable.

  • The Ad Server runs the auction with runtime targeting and filters the ad lists based on inventory configuration, floor price etc.

Possible results:

  1. An ad matching the parameters is found. The Ad Server sends the winning ad back( see Ad Response).
  2. No matching ad is found. The Ad Server stops operations and would report the request as "No Ad found".

Ad found yes/no

Ad response
  • The ad server delivers a VAST compliant XML file that contains the URL of the pre-roll ad etc.
  • Additionally, the Video SSP ad server attaches VPAID functionality to the VAST XML response to discover the video player environment.
  • Detection parameters sent:
    • URL
    • Viewability (at that instant)
    • IP Address
    • Player size
    • User Agent (if applicable)

Note: While VAST XML alone supports only simple in-stream video ads, the use of VPAID in addition to the VAST XML ad response enables a method of communication between the ad and the video player.

VAST compliant XML file with VPAID

Video player loads One Video VPAID

Video player on the page loads the One Video VPAID shim that would allow it to run the ad.

VPAID Load

Ad load in the video player

The VPAID detection mechanism does verify, if the requested values in the Pre-Bid Auction match the detected values in the <AdParameters> of the video tag.

Possible results:

  1. Both, pre-bid and detected parameters match. The video player loads the ad. For details, see Detection parameters and mismatch tolerances.
  2. One or more parameters mismatch and/or are not within the allowed tolerance. The video player sends a second ad request (see Double Auction ad request).

Ad match/mismatch

Double Auction ad request

(Second Auction)
  • The video player requests the pre-roll ad from the Video SSP ad server a second time.
  • This request includes doubleauction parameter which sends values as comma separated for each of the “mismatched” parameters:
  • url (Page URL)
  • vw (viewability)
  • ip (IP Address)
  • psw (player size width)
  • psh (player size height)
  • ua (User agent)

Example: &doubleauction=vw,ip (encoded as applicable)

VAST+VPAID ad tag with doubleauction parameter

Ad Server runs a second auction

The Ad Server runs a second auction based on the detected values with runtime targeting and filters the ad lists based on inventory configuration, floor price etc.

Possible results:

  1. An ad matching the parameters is found. The Ad Server sends the winning ad back( see Ad Response).
  2. No matching ad is found. The Ad Server stops operations and would report the request as "No Ad found".

Ad load yes/no

Final ad response

The ad server delivers a VAST + VPAID compliant XML file that contains the URL of the pre-roll ad etc.

Result: The delivery is tracked for reporting based on the inventory type.

Ad match

 

Common Ad Server macros

A Macro is a special parameter that tells your primary ad server or player to replace this value with another based on the most current data. Please reach out to your account executive in case you have issues to pass the macro correctly.

 

Server or Player

Macro for Width

Macro for Height

Viewability

O2

[CONTAINER_WIDTH]

[CONTAINER_HEIGHT]

[P_VW_VIEWABLE]

JW Player

__player-width__

__player-height__

 

Spring Serve

{ {WIDTH} }

{ {HEIGHT} }

 

SpotxChange

$PLAYER_WIDTH

$PLAYER_HEIGHT

 

DFP

%%WIDTH%%

%%HEIGHT%%

 

 

Trust but Verify viewability settings

Sellers can optimize ad delivery for auctions by using Historical measurements (last 7 days) in TbV Viewability settings. For details, see  How to Define Format for Your Inventory Source or How to Create a New Connection.

  • If enabled for Inventory Sources or within a Marketplace Connection, the setting overrides all other viewability configurations and uses historical viewability for ad selection and auction. The tag is sent in TbV format from a specific entity.
  • If enabled for an Organization, the setting overrides all other viewability configurations and uses historical viewability for ad selection and auction. The tag is sent in TbV format from the organization.

    Note: Using this feature across an organization requires the appropriate user permission and configuration which is activated by your Account Manager.

  • Changes in the Report: Adserver will replace the pi.viewable to '-1' and reporting will reflect that.

 When will override be applied

  • The ad server recognizes when the historical viewability flag is checked in an incoming tag.
  • In such cases, ad server sends historical viewability only to bidders.
  • For direct campaigns, historical viewability will be used.
  • Last 7d rolling viewability % is used.
  • As a result, there are no second auctions.

 

Case

IS Config

MPC Config

Viewability applied

IS tag

Historic

N/A

Historic

MPC tag

N/A

Historic

Historic

IS tag with backfill

Historic

N/A

Historic (across all backfill MPCs)

IS tag with Direct

Historic

N/A

Historic

IS or MPC tag with valid pi.height & pi.width, but invalid or blank pi.viewable

Historic

Historic

Historic

Anything else

 

 

Pre-bid value

 

Schema

Trust but Verify Double Auction in reporting

Every ad request made to the Video SSP ad server is counted and shows data in reporting under Metrics based on the inventory type e.g. Ad Opportunities or Market Opportunities.

In a case of Double Auction, all these data will be double counted.

  • Use key Auction Type to to differentiate data for First and Second auction.
  • Use key Double Auction Reason to track down, why your ad was double requested.  See also, Reasons to Filter Ad Opportunity.
  • Use key VPAID Loads to find out how many times the player loaded Video SSP VPAID for filling the opportunity.

Example:

 

Detection parameters and mismatch tolerances

Continue with First Auction Expected and detected values as as given below

  1. Declared = 0, Detected=1
  2. Declared = -1, Detected= 0,1

 

Anything other than mentioned in the "Continue with First Auction" 

Parameter Name

Expected Values

Continue with First Auction

Trigger Second Auction

pi.width

value in px

Expected and detected values are as given in range below:

  1. Range : 300-349; Detected : >= 300
  2. Range: 350-399; Detected: >= 350
  3. Range : 400-449; Detected: >= 400
  4. Range : 450-499; Detected: >= 450
  5. Range : 500-599; Detected: >= 500
  6. Range : >=600; Detected: >= 600

 

Anything other than mentioned in the "Continue with First Auction"

 

pi.height

value in px

pi.viewable

0 – not viewable

1 – viewable

-1 – unknown

Expected and detected values as as given below

  1. Declared = 0, Detected=1
  2. Declared = -1, Detected= 0,1

 

pageUrl

Domain URL

no tolerance except if Page URL Override is enabled.

Note: Page URL Override is a restricted feature and not available to all clients. Please reach out to your Account Manager for further information.

Note: Displays Yes or No if the marketplace connection is enabled for Page URL Override.

Top Level Domain is different

a.ip

IP address

no tolerance

Any mismatch

a.ua

User Agent

no tolerance

Detected user agent is different

 

 

Have more questions? Submit a request