Video SSP Ad Request Eligibility

Both Marketplace Connections and Inventory Source tags require you to define a specific set of criteria that will be used to verify the ad requests coming from any 3rd party player. 

If an ad request does not match the specific criteria set in the assigned tag (either a Marketplace Connection or Inventory Source) then the request will be deemed not eligible and filtered out resulting in a lower ad response fill rate.

 

Equal or Less Matching

The basic concept of all ad related validations in the Video SSP platform is that the request specification cannot exceed the criteria set in either a Marketplace Connection or an Inventory Source. This means that the ad requests can be either equal or less than the setting defined in each of them.

Additionally, because Inventory Source tags check for matching Marketplace Connections, the Inventory Source criteria cannot exceed the Marketplace Connection criteria. Everything must be equal or less than the set specification.

The following diagram shows our complex validation that links Ad Requests, Inventory Sources, and Marketplace Connection.

Note: The same concept is also incorporated when an Ad Request is linked directly with a Marketplace Connection (thus eliminating the Inventory Source from the middle).

 

ONE_Video_Flow_007.jpeg

 

Marketplace Connection Ad Request Matching Example

In the following example, we have a Marketplace Connection setup with the following criteria:

  • Media: The only allowed domain listed is: `one.com.
  • Allowed Response Types: VPAID JS with VAST 2.0 support
  • Ad Duration: Any ad with a duration up to 30 seconds - not more.

On the left-hand side of the diagram below, you can see three numbered ad requests that are being made to the same Marketplace Connection. Each request has a different set of criteria (noted on each arrow), specifying the request information such as: requesting device type, requesting domain, supported ad type, ad duration etc. 

ONE_Video_Flow_005.jpeg

 

Looking at the example above, you can see that Request 1 is calling for a VAST 3.0 and VPAID Flash ad. As the Marketplace Connection is setup to only accept VAST 2.0 and VPAID JS this request is not eligible and therefore filtered out.

Looking at Request 3, Although it complies to the VAST and VPAID versions defined in the Marketplace Connection, it is actually coming from a domain that is not listed in the Marketplace Connection. Requests coming from any domain other than `one.com`are therefore also filtered out.

Only Request 2 only that matches all the Marketplace Connection criteria (either equal or less) is eligible for passing on for sale to Marketplaces.

 

 

 

 

Inventory Source Ad Request Matching Example

In the following example, we have an Inventory Source setup with the following criteria:

  • Media: The only allowed domain listed is: `one.com`
  • Allowed Response Types: VPAID JS and Flash with VAST 2.0 support
  • Ad Duration: Any ad with a duration up to 15 seconds - not more.

Additionally, we also have a Marketplace Connection setup with the following criteria:

  • Media: The only allowed domain listed is: `one.com`
  • Allowed Response Types: VPAID JS only with VAST 2.0 support
  • Ad Duration: Any ad with a duration up to 30 seconds - not more.

On the left-hand side of the diagram below, you can see three numbered ad requests that are being made to the same Inventory Source. Each request has a different set of criteria (noted on each arrow), specifying the request information such as: requesting device type, requesting domain, supported ad type, ad duration etc. 

Ad requests to Inventory Sources have a different flow than described above regarding Marketplace Connections as each request must pass validation criteria of both the Inventory Source and the Marketplace Connection.

ONE_Video_Flow_006.jpeg

 

Looking at the example above, you can see that Request 3 is calling for a VPAID Flash ad. Although the Inventory Source is setup to accept ad requests with both Flash and durations of up to 60 seconds, this one request will be filtered out as it is VAST 3.0.

Note: Although the Marketplace Connection accepts ad request for VAST 3.0, the Inventory Source is more strict only allowing VAST 2.0 ads. Therefore this request will be filtered out by the Inventory Source before it reaches the Marketplace Connection criteria validation. This is a setting we need to avoid.

Looking at Request 2 we can that it complies with all the criteria of the Inventory Source but the Marketplace Connection only accepts VPAID JS requests. Therefore Request 2 which is for VPAID Flash is not eligible and filtered out by the Marketplace Connection level.

Last is Request 1, that complies with all the Inventory Source and Marketplace Connection criteria. This is the only request that will be passed on for sale in the relevant Marketplaces.

Note: Using this logic, you can create more complex tiering with Marketplace Connections for separating Desktop, Mobile App and Mobile Web requests. You can then use the Inventory Source just to filter between your In-Stream video and Outstream inventory.

 

Have more questions? Submit a request