Video Best Practices for Publishers

Document created by alynn.beyder on May 18, 2018Last modified by Marcos.Male on Oct 5, 2018
Version 7Show Document
  • View in full screen mode

Video Parameters Important for Monetization

Refer to Video-specific Parameters for specific parameter details.

  • Video player width and height
    • PubMatic found that buyers are typically interested in medium to large player sizes across desktop, mobile web, and mobile in-app inventory
  • Mime types
    • Required in RTB spec
    • Allows buyers to know which file type is supported
    • If all file types are supported, PubMatic suggests to pass all values rather than assuming there is a default
    • Pay special attention to this parameter for VPAID inventory (if VPAID is supported, mime type JavaScript and/or Shockwave Flash should be selected in addition to other mime types supported. For JavaScript, VPAID 2.0 should be passed)
    • Mobile does not support Flash or SWF (Shockwave Flash)
  • VPAID version
    • Only if supported by video player; if not supported, PubMatic encourages publishers to support the VPAID version as it allows both PubMatic and the buyer to measure fraud and viewability
    • PubMatic recommends VPAID 1.0 or 2.0 for desktop, but VPAID 2.0 for mobile web, since mobile web does not support flash 
    • Non-VPAID (commonly referred to as VAST) is most common on mobile in-app, but if the mobile app SDK or video player supports VPAID, then it should be sent to improve monetization
    • VPAID inventory is supported across tag, server-to-server (S2S/API), and oRTB (openbid) publishers
  • Minimum and maximum ad length
    • PubMatic recommends keeping duration within 30 seconds for best monetization results, with shorter durations for mobile than desktop
  • Playback method (auto sound off, auto sound on, etc.)
  • Maximum bitrate
    • Maximum bitrate helps control the file size and video ad quality (the lower the maximum bit rate, the lower the file size/resolution), which is especially helpful for mobile in-app
  • Skippability


Recommendations for API/Server-to-Server Based Publishers:

  • In the PubMatic UI, a VAST tag (not VPAID) should strictly be used, since VAST tags can still receive both VPAID and VAST only/non-VPAID ads
  • For VPAID inventory, include the vapi parameter along with its corresponding mime types in the ad request


Recommendations for Tag Based Publishers:

  • If only one type of VPAID file (JavaScript vs. Shockwave Flash) is strictly supported:
    • PubMatic recommends using the js parameter to indicate if it is JavaScript or Flash VPAID, along with the vapi parameter (VPAID version) and appropriate mime type(s)
    • VPAID tags in the UI should only be created if all of the inventory for the tag supports VPAID
    • If a mix of VPAID and inventory that doesn't support VPAID will be running on one tag, then a VAST tag should be used instead, and the vapi parameter should be dynamically set on each ad request to indicate the VPAID version support
  • Make sure vapi parameter and corresponding mime type is passed via PubMatic S2S API or is set on the tag 


Recommendations for Sending Out-Stream Inventory:

  • For ortb integrations, PubMatic currently supports the "placement" parameter for identifying in-stream vs. out-stream inventory. Refer to the ortb 2.5 spec for respective placement values. We will be expanding the support of this parameter for tag based integrations in the future.



  • Flash is not supported in mobile, so avoid sending this mime type for mobile ad requests
  • While Flash (flv) and Flash VPAID (swf) has been phasing out across all screens, not all DSPs have communicated their discontinued use of Flash VPAID yet, so while there will still be demand and PubMatic will continue to accept this type of inventory, JavaScript VPAID will have more demand and continued support from major DSPs (e.g. DBM does not support Flash anymore)


Challenges for Publishers:

  • Arbitragers re-sell inventory through VPAID
    • These arbitragers will deliver a VPAID Ad Manager (not an authentic ad) to the publisher, re-auctioning the inventory to other exchanges with a floor price that is high enough to cover the cost of the ad
    • If they are unable to fill it, they error out, which prevents the impression tracker from being fired, and therefore they do not get charged
  • Video errors
    • Sending incorrect video parameters can lead to DSPs returning a video ad that is not compatible with the player (i.e. file type not being supported by video player)
    • Too many VAST wrappers can lead to added latency
    • Some DSPs may return a VAST wrapper that leads to an empty VAST (instead of a final In-Line VAST response), which can be caused by a campaign that is past its end date or has had changes to the creative within the advertiser's ad server
    • For other potential causes of errors and troubleshooting tips: VAST Error Code Troubleshooting Matrix - IAB TechLab Wiki