Video

Overview

Marketplace video (via VAST specification) is a growing source of demand for publishers. This document outlines various enhancements to marketplace video that MoPub has employed.

What is VAST

VAST (Video Ad Serving Template), is a template for a standard XML-based ad response for in-stream video ad serving. It is a standard developed by the Internet Advertising Bureau (IAB). VAST 2.0 was published November 2009 and VAST 3.0 was published July 2012 (Note that VAST 1.0 was deprecated with the release of 2.0, and 3.0 is backward compatible).

How VAST Works

  • VAST is a XML template that contains all required assets and tracking pixels for video ad serving. This includes:
    • Video URL to an externally hosted video asset
    • Impression pixel to 3rd party ad server
    • Video tracking pixels for video start, 1st quartile, midpoint, 3rd quartile, and video complete
    • Click tracking pixel + destination URL
  • MoPub uses a custom Javascript-based video player that takes the VAST XML as an input and parses out these assets and is responsible for video playback and firing the relevant tracking pixels

CloudFront & China

If you are using CloudFront and targeting mainland China, it’s possible that your CDN hosted content may not display. This can be due to a variety of factors (such as latency or inability to download content). Amazon CloudFront’s content delivery article states the following:

“Amazon CloudFront uses a global network of edge locations, located near your end users in the United States, Europe, Asia, South America and Australia. Amazon CloudFront edge locations are currently not available inside of China.”

Support

  1. MoPub supports VAST 2.0 and 3.0 for Linear Videos per the IAB VAST 3.0 specification
  2. VAST InLine and Wrapper
  3. Interstitial placements only (320×480, 480×320, 1024×768, 768×1024)
  4. Supported media MIME types:
    • iOS:
      • video/mp4
      • video/3gpp
      • video/3gpp2
      • video/quicktime
      • video/x-m4v
    • Android:
      • video/mp4
      • video/3gpp
  5. Not supported media MIME types:
    • Flash (flv, swf) is not supported
  6. Video file size limits:
    • Max file size (iOS & Android): Recommended 2MB (recommended maximum file size is 10MB). Videos that are closer to 2MB can have a better performance.
    • If the request to retrieve the video file exceeds 30 seconds, it will be considered a timeout.

MoPub supports vertical video through VAST 3.0 + OpenRTB 2.3. The video is “true” portrait and takes up the entire screen space in portrait orientation. Please refer to the Vertical Video FAQ for more info.

Targeting Best Practices: (Bid Requests)

  1. It is your responsibility to
    • Serve video only to video-enabled bid requests
    • Serve video only to interstitial ad placements
    • Respect publishers’ min/max duration values as indicated the in bid request
    • Serve VAST tags to the correct “protocol” version when serving VAST 3.0 tags and utilizing VAST 3.0 features
  2. Video-enabled is noted in the bid_request.imp.battr[] field
    • A bid request is considered video-enabled only if the value ‘6’ is NOT present in “bid_request.imp.banner.battr[]” field
    • If the value of ‘6’ is present in the “bid_request.imp.banner.battr[]” field, the publisher has explicitly specified that auto-play video (VAST) is not to be served
  3. Allowed min/max video durations is noted in the bid_request.imp.video.minduration and bid_request.imp.video.maxduration fields.
    • Your bidder is required to ingest allowable video min/max duration and serve an appropriate video (or not serve at all) accordingly.
    • For example, a bid request that states minduration=16 and maxduration=30; the publisher is allowing only skippable-videos between 16-30sec in duration. If your bidder served a < 16sec video in this instance; our platform would immediately disqualify your bid response from the auction.
  4. VAST video is supported for interstitial ad placements only
    • ie: 320×480, 480×320, 1024×768, 768×1024
    • NOTE: Video may automatically render in landscape mode based on operating system and device size (regardless of ad unit size in bid request), so it is recommended to include video files properly encoded with a landscape aspect ratio. Our video player will always pick the best video option from the VAST tag.

RTB 2.3 – Bid Response Best Practices

  1. Ad Markup Notes
  2. Key Video Changes in RTB 2.3
  3. Requirements

Ad Markup Notes

  • URL-encoded VAST tags are NOT supported. Do NOT URL-encode your VAST xml tag
  • MoPub supports the use of VAST ad tag wrappers for serving VAST tags from a secondary ad server.
  • VAST tag wrappers <VASTAdTagURI>

Key Video Changes in RTB 2.3

  • crtype and duration were moved
  • ext.video was removed

Requirements

IMPORTANT: There are four (4) required video-specific fields for RTB 2.3 VAST video bid responses (See fields below)

  1. bid_response.seatbid.bid.attr
    • Details: This integer array field indicates the type of creative being served. Per section 5.3 of the IAB Open RTB 2.3 specification, the value ‘6’ indicates the creative is of type “In-Banner Video (Auto-Play)”
    • Valid value(s): 6 (This field must contain the integer 6)
    • Example: "attr": [6]
  2. bid_response.seatbid.bid.ext.crtype
    • Details: This field indicates the type of video being served
    • Valid Value(s): “VAST 2.0” or “VAST 3.0”
    • Example: "crtype": "VAST 3.0"
  3. bid_response.seatbid.bid.ext.duration
    • Details: The value in the ‘duration’ field must match the actual length of the video being served
    • Valid Value(s): 5-120 (Must adhere to min/max duration range passed in the bid request)
    • Example: "duration": 30
  4. bid_response.seatbid.bid.adm
    • Details: The “adm” (or admarkup field) contains the entire XML markup for either VAST 2.0 InLine, VAST 2.0 Wrapper, VAST 3.0 InLine, or VAST 3.0 Wrapper
    • URL-encoded VAST tags are NOT supported. Per the VAST spec, all URLs must be wrapped in <[CDATA[ ]]> and must not be encoded

Server-to-Server – Bid Response Best Practices

  1. Ad Markup Notes
  2. Requirements

Ad Markup Notes

Requirements

IMPORTANT: There are three (3) required video-specific fields for RTB 2.3 VAST video bid responses (See fields below)

  1. `bid_response.seatbid.bid.crtype
    • Details: This field indicates the type of video being served
    • Valid value(s): “VAST 2.0” or “VAST 3.0”
    • Example: "crtype": "VAST 3.0"
  2. bid_response.seatbid.bid.attr
    • Details: This field indicates the _type _of creative being served. The value ‘6’ indicates the creative is of type “Auto Play In-Banner Video”
    • Valid value(s): 6 (This field must contain the integer value 6)
    • Example: "attr":[ 6 ]
  3. bid_response.seatbid.bid.ext.video{}
    • Details: This object provides more specifics on the video being served. There are three required fields:
      • duration
      • type
      • linearity
        1. bid_response.seatbid.bid.ext.video.duration
          • Details: The value in the ‘duration’ field must match the actual length of the video being served
          • Valid value(s): 5-30
            • Server-to-Server: Publishers cannot control the min/max values that are passed in the request. You must discuss video settings with your publisher prior to serving video.
          • Example: "duration":30
        2. bid_response.seatbid.bid.ext.video.type
          • Details: This field indicates the type of video being served
          • Valid value(s): “VAST 2.0” or “VAST 3.0”
            • This field must be set to either “VAST 2.0” or “VAST 3.0”
          • Example: "type":"VAST 2.0"
        3. bid_response.seatbid.bid.ext.video.linearity
          • Details: This field provides the linearity
          • Valid value(s): 1
            • The ‘linearity’ field must be set to ‘1’ since MoPub only supports linear video
          • Example: "linearity":1
        4. Example of bid_response.seatbid.bid.ext.video{}
           "ext": {
             "video": {
               "duration":30,
               "type":"VAST 2.0",
               "linearity":1
             }
           }
          

The above video-specific fields are required in addition to to the standard fields required for all bid responses in general.

Your VAST video bid responses will ALWAYS be rejected by MoPub if they do not include ALL three fields (3) with valid and appropriate values.

Video Creative and Companion Banner Best Practices

  • Media File Dimensions: Bid responses with VAST tags should include a variety of media file options for proper display regardless of device and orientation. Our video player will pick the best video option from the VAST tag. However, since video may automatically render in landscape mode regardless of the height/width dimensions as stated in the bid request. It is important to include a file encoded with a landscape aspect ratio for optimal viewing experience. See orientation best practices below.
  • Media File Encoding: iOS and Android devices have varying support for video and audio mime types. Below is our recommended media file encoding so your video has the greatest chances of success across all devices.
Media Encoding Description
H.264 Baseline Profile Level 3.0 Also known as MPEG-4 Part 10, Advanced Video Coding (MPEG-4 AVC) is the most popular format for the recording, compression, and distribution of video content.
AAC LC Advanced Audio Coding (AAC) Low-Complexity (LC) is an MPEG-2/MPEG-4 profile that is supported by all mobile devices
HE-AACv1 AAC High-Efficiency v1 is an MPEG-4 profile that is supported by all mobile devices
  • Industry Icon: Bid responses with VAST 3.0 tags may incorporate an industry icon, such as the AdChoices icon, for supported inventory. For support, see ‘Overview of SDK Version 3.9 Support for Video Features’ section.
    • We will only support the use of a single industry icon in a given response. We will choose the icon closest to the media file that’s being played. If an industry icon exists in wrapper tags, it will be preceded by the icon in the main VAST tag, if it exists.
    • We will ignore x/y coordinates for the icon and will always place it in the top left corner to ensure a consistent user experience.
    • DSPs should submit icons that are approximately 35×35 in size for the industry icon. Wider icons are OK, but taller icons will lead to a poor user experience.
  • Targeting:
    • iframe and HTML industry icon support exists for SDK v3.9+ only. In order to effectively target supported inventory, please do the following:
      • RTB 2.3: target companion type = 2 or 3
      • As an alternative, always serve a static icon
  • Orientation: (“device orientation” meaning the orientation of the app, not the physical device orientation):
  • Note: The following orientation behavior applies to all Server-to-Server partners. Bidders on RTB 2.3 should refer to the below section on ‘Orientation flexibility’
    • iPhone: Will always attempt to play video fullscreen in landscape unless device orientation is locked in portrait by the app at the xcode level. If so, the video will play in portrait.
    • iPad: Will always play video in the height/width dimensions as stated in the bid request. (NOTE: if the physical device orientation does not match the ad unit (e.g., device is oriented in portrait mode (768×1024) but ad unit is requesting landscape content (1024×768) ), the ad will play letter-boxed in portrait orientation).
    • Android Phone: Will always play video in landscape.
    • Android Tablet: Will always play video in landscape.
  • Orientation flexibility: With the introduction of VAST 3.0, DSPs can choose to submit landscape and portrait videos. In those cases, the MoPub player will choose the best video based on how the device is oriented by the user. Note this is only available for bidders on RTB 2.3 only. To target inventory with this capability, bidders integrated with RTB 2.3 can do the following:
    • Target inventory supporting VAST 3.0 – i.e., ‘protocols’ contains values 3 or 6 (VAST 3.0 or VAST 3.0 wrapper)
    • Note the ‘h’ and ‘w’ fields in the video object to target the proper ad unit orientation (best practice: include video assets coded to both portrait and landscape orientation and we’ll choose the best fit)
    • Include the XML elements in your VAST document.
    <VAST version="3.0">
        <Ad>
          <InLine>
            <-- Other VAST XML Elements-->
            <Extensions>
              <Extension type="MoPub">
                <MoPubForceOrientation>Device</MoPubForceOrientation>
             </Extension>
            </Extensions>
          </InLine>
        </Ad>
    </VAST>
  • Duration: Videos with a duration > 30 seconds are not allowed. Note: publishers can now request video up to 120 seconds, however, DSPs should continue to refrain from submitting videos with a duration > 30 seconds.
  • Quality: QA video to ensure it is high quality. ie, it is not blurry and adheres to MoPub’s creative content policies
  • iurl (image URL) field: iURL for VAST or MRAID bid responses is not required to match the user displayed image. Demand Partners may either submit the preview link or provide a representative example. You can read more on our Demand Policy section.
  • Companion banner: Companion banners appear after the video completes.
    • MoPub supports companion banners for iOS and Android implemented via <StaticResource>, <HTMLResource>, and <IFrameResource>. These will be supported for VAST 2.0 and VAST 3.0 tags.
      • Note: Companion type support is outlined below in ‘Companion Targeting’. Also see Overview of SDK Version 3.9 Support for Video Features Section below
    • .png, .bmp, .jpeg, and .gif files are supported in <StaticResource>
    • We will prioritize processing companion banners in the following order once we’ve picked the best size: Static, HTML, iframe.
    • MoPub does not support the <CompanionClickThrough> element for HTML and Iframe companion banners. Per IAB’s VAST spec this element is only applicable for Static companion banners. Click through tracking for or should happen from the HTML snippets within.
    • For iOS: We will not fire URLs in the events for HTML and iframe companions on iOS because of limitations in the video player. We will fire them on Android.
  • Companion banner targeting: <IFrameResource> and <HTMLResource> companion banner support exists for SDK v3.9+ only. In order to effectively target supported inventory, please do the following:
    • RTB 2.3: target companion type = 2 or 3
  • Companion banner size: Minimum size of 300×250. There is no maximum size; however, images larger than the device screen will be scaled down proportionately to fit the screen, and centered. Note that if your static companion banner image does not have the same general aspect ratio as the screen; the scaled-down image will be wrapped by a black border that extends to the screen’s edge. HTML and iframe companion banners should not exceed the screen size. If submitting multiple companion banners, our SDK will pick the one that fits the device and orientation best.

  • Custom call to action: DSPs and Server-to-Server Partners can replace the standard “Learn More” call to action with a custom one, up to 15 characters in length. To do so, DSPs should add the node to their VAST XML (2.2.4.2). This can be added to a Wrapper or standard tag. For support, see ‘Overview of SDK Version 3.9 Support for Video Features’ section
 <VAST version="3.0">
    <Ad>
      <InLine>
        <-- Other VAST XML Elements-->
        <Extensions>
          <Extension type="MoPub">
            <MoPubCtaText>Install Now</MoPubCtaText>
         </Extension>
        </Extensions>
      </InLine>
    </Ad>
  </VAST>
  • Video birate: There are no limitations on video bitrate, however, best practices do apply:
    • Video bitrate combined with video duration should net out to a recommended file size of 2MB (recommended maximum 10MB). Videos that are closer to 2MB can have a better performance.
    • Ideally below 512kbps or lower
  • Video: H.264 Baseline Profile Level 3.0, constant bitrate
  • Audio: AAC, Low-complexity profile, constant bitrate, 2 channels, 44.1K Hz sampling rate

Additional VAST 3.0 Behaviors

Below are additional behaviors of VAST 3.0 specifically related to MoPub’s implementation:

  • We do not support Ad Pods. Our player will only look for ads videos with sequence set to 1, 0, or empty.
  • Close Events (2.3.1.7) VAST 3.0 introduced a closeLinear event specifically for linears ads. VAST 3.0 also introduced a skip event, which is the same for us because skipping a video leads to closing it. We will fire all 3: close, closeLinear and skip when the user closes the video ad.
  • Progress event (2.3.2.3) VAST 3.0 allows the ad creator to supply a progress tracker parameter to track when a video reaches a specific percent or time, in addition to the standard quartile trackers.
  • Wrapper chain management. (2.4.1.2) We do not support any of the functionality in wrapper chain management.
  • Error Reporting (2.4.2) We support the following errors to be reported to a DSP. We will look into adding others, if there is demand for them.
    • 100 – XML parsing error
    • 301 – timeout of Wrappers
    • 303 – no ad error response
    • 400 – any error that occurs as a result of trying to play/display the video
    • 600 – any companion ad error
    • 900 – any other error
  • Macro support (2.4.4) VAST 3.0 supports placing a number of macros at the end of URLs for additional tracking. We support all of the macros outlined in the spec:
    • [ERRORCODE]
    • [CONTENTPLAYHEAD]
    • [CACHEBUSTING]
    • [ASSETURI]

Overview of SDK Version 3.9 Support for Video Features

Video Feature iOS Android
Support for static AdChoices icon All SDK versions SDK 3.9+ only
Support for HTML, iframe AdChoices icon SDK 3.9+ only SDK 3.9+ only
HTML and iframe companion banners SDK 3.9+ only SDK 3.9+ only
Custom Call to Action All SDK versions SDK 3.9+ only
Additional VAST 3.0 behaviors All SDK versions All SDK versions

Opt-in Rewarded Video Bid Requests

For opt-in rewarded video, there are two (2) video-specific extention fields for RTB 2.3 VAST video bid requests to distinguish these requests from standard interstitial video bid requests. Both extention attributes are optional to ingest. (See fields below)

  1. bid_request.imp.video.ext.skip
    • Details: This field indicates whether the video is skippable by the user
    • Valid value(s): 0 (Set to 0 to identify non-skip opt-in rewarded video)
    • Example: "bid_request.imp.video.ext.skip":0
  2. bid_request.imp.video.ext.videotype
    • Details: Always set to “rewarded” indicating the request is for an opt-in rewarded video.
    • Valid value(s): rewarded
    • Example: "bid_request.imp.video.ext.videotype":"rewarded"

Known Limitations

  • Error Codes
    • Errors are fired when Companion Banners are present in the XML
      • MoPub will fire a value of 900
      • This is an issue on iOS only
      • There is no impact to the Companion banner and it will render on the device if the Companion Resource is supported (see Video Creative and Companion Banner Best Practices above)

Best Practices for Optimal Performance

  • Video File Size: We recommend having a 2MB file size (recommended maximum file size is 10MB). Videos that are closer to 2MB can have a better performance compared to those that are of larger file size. Keep in mind that data connection speeds and latencies vary throughout the world.
  • Media File Delivery: MoPub supports progressive delivery and not streaming. We also do not support video files such as Flash (flv, swf) or any other streaming file types. For more info on supported media types, click here. If you plan on using a VAST Wrapper, we recommend the following tips for optimal performance.
  • VAST wrapper: Use no more than 5 wrappers max. The more wrappers you have, the longer it can take to download the appropriate assets and show the video. Verify that your wrapper links appropriately to your XML source. If it does not, then we may not be able to load the video.
  • Media File Encoding: Make sure your video is encoded for H.264 Baseline Profile Level 3.0 for the most compatibility.

Commons Causes for Low or 0% Clear Rate

DSPs may find that they win auctions, but do not end up successfully clearing (showing) an impression for certain creatives. Below is a list of reasons for why this may happen for VAST. Note: This is not an all-encompassing list. We recommend always Self-Testing your creative.

  • Blank XML- Be sure that you are not using a wrapper which points to blank XML.
  • XML errors(i.e. - not properly following the VAST spec).
  • Video file size exceedingly large- We recommend 2MB.
  • Geos with slower internet connection- You may want to consider targeting devices on Wifi only for some countries.
  • Publisher integration - If you notice a high volume of your auctions are being won but not cleared by a specific Publishing App, that could be the driving force behind a low clear rate.
  • Improper encoding - any field not properly encoded can result in the impression not clearing. For example, are you using a macro for the Publisher name? Be sure to encode the name to accomodate for any spaces.
  • Media File Encoding: Make sure your video is encoded for H.264 Baseline Profile Level 3.0 for the most compatibility.

Frequently Asked Questions

General and Inventory Avails

  1. How do I know if the inventory supports VAST video?
    • The inventory which supports VAST will not pass the Creative Attribute 6 “In-Banner Video Ad (Auto Play)” via the “battr” parameter. Additionally, if the impression supports in-banner video the video attributes will be passed in the video extension parameters.
    • Please see our Video Ads Bid Request Specification for details and examples of how video duration is indicated in the bid request and how to differentiate between VAST 2.0 and VAST 3.0 supported inventory.
  2. Which ad sizes support VAST?
    • Interstitial placements only (320×480, 480×320, 1024×768, 768×1024).
  3. Is VAST 3.0 backwards compatible to support VAST 2.0 tags?
    • Yes.
  4. If a partner submits a VAST 3.0 tag for inventory that only supports VAST 2.0, will it still work?
    • Yes, the video ad will still render and play properly – however, the features that are specific to VAST 3.0 will not take effect. All VAST 2.0 features would still be supported.
  5. How do I know if the inventory supports 15 sec or 30 sec video?
    • Marketplace Partners:
      • The bid request will pass the specific durations that are supported per app:
      • To view how VAST inventory duration is indicated in the bid requests, please review the MoPub OpenRTB Spec.
      • If the video is 17.6 seconds, round to the closest integer. For example if the video is 17.6 seconds, serve the duration as 18.
    • Server-to-Server Partners
    • Publishers cannot control the min/max duration that is sent. You must speak with your customer directly to understand their video preferences prior to serving video
  6. How can I find the inventory that supports VAST in my Metamarkets account? (Only applies to DSPs – N/A to server-to-server partners)
    • Login to your Metamarkets account and select the dimension “Video Enabled: Yes” to see what inventory which supports VAST.
  7. How many monthly VAST video avails are currently running in the Marketplace? (Only applies to DSPs – N/A to server-to-server partners)
    • (Updated 7/1/15)
    • iOS: 38% of interstitial auctions
    • Android: 41% of interstitial auctions
  8. Will we track VAST 3.0 spend in Metamarkets? (Only applies to DSPs – N/A to server-to-server partners)
    • We have made a request to add this to Metamarkets and will have a timeline for inclusion soon.
  9. How does VAST differ from HTML5?
    • VAST Video follows the IAB VAST Spec. As part of the RTB Response, the DSP provides a VAST document to us. MoPub then uses a custom Javascript-based video player that takes the VAST XML as an input and parses out these assets and is responsible for video playback tracking pixels
    • HTML5 Video on the other hand doesn’t have to follow any specific pre-defined spec. In this case the video URL, impression trackers, click trackers etc. are present in an HTML5 payload which the SDK Webview can then interpret – similar to any regular HTML5 ad i.e. display ads. Since VAST is a standard spec which has gone through rigorous testing on MoPub, we recommend to use VAST spec over HTML5.
  10. Do I have to serve VAST or can I still use HTML5?
    • We support both VAST and HTML5 video, however VAST is preferred.
  11. What are the advantages of VAST over HTML5 or MRAID video?
    • Minimized impression tracking discrepancies (all trackers are fired with same mechanism for VAST)
    • 100% of videos will be precached for optimized user playback.
  12. Do you support VAST with VPAID?
    • No, we recommend using MRAID for interactivity with mobile video ads.
    • Note that all VAST capable inventory is compliant with MRAID 1.0.
  13. When do you charge for a video view? On completion or on start of the video?
    • MoPub charges based on cleared impressions. The cleared impression tracker is fired when the video webview becomes viewable to the user. The VAST ‘start’ event tracker fires immediately as well for all SDK version on iOS and SDK 4.11+ on Android.
  14. What is the lower limit to the fps / quality of video you will serve?
    • Lowest recommended is 24fps
  15. Does MoPub support pre-caching?
    • Yes – for all Android SDKs and iOS 1.16+
    • It is important to note that “pre-caching” is different from “caching.” The video will stream and cache video beyond where playback is to ensure continuous playback once it starts.
  16. Will we provide quartile tracking for reporting?
    • Not through MoPub reporting, it is up to the DSP / advertiser to incorporate 3rd party quartile tracking into the VAST template and MoPub will be responsible for making sure these pixels are called at the right time during video playback.
    • We are looking into tracking quartiles internally as a future product enhancement.
  17. What type of engagement metrics can we expect to see with VAST video?
    • MoPub’s reporting will not change as part of Video. Thus we continue to provide metrics for impressions (when the player becomes viewable) and clicks. We do not provide metrics for quartile tracking and completion of video.
    • DSPs, Server-to-Server partners, and Advertisers will be able to see their own metrics from the Video-specific tracking pixels that are part of the VAST template.
  18. What are the eCPM for video ad units?
    • This will vary based on application type (game etc.), country (CPMs will higher for US vs. India for example) and size of the publisher. However, on average, you can expect video ad eCPMs to be at least around 1.5-2x of Interstitial Ad Units.
  19. What formats and types of video does MoPub support (inline/banner/click to expand etc)?
    • Linear Video only.
    • Auto-play video only.
    • Pre-roll video is NOT supported
    • We do not support inline video, non-linear ads, overlay ads, or simultaneous playback of video with companion banners.
    • Only interstitial ad units for phones (320×480, 480×320) and tablets (728×1024, 1024×728). No support for banner ad units (320×50) or mrects (300×250).
    • NOTE: Video may automatically render in landscape mode based on operating system and device size (regardless of ad unit size in bid request), so it is recommended to include video files properly encoded with a landscape aspect ratio. Our video player will always pick the best video option from the VAST tag.
  20. Do you support companion banners?
    • Yes! MoPub supports <StaticResource>, <IFrameResource> and <HTMLResource>. For <StaticResource>, the companion must be 300x250 or larger. For 16x9 videos, we recommend a 16x9 end card like 640x360 but will also accept and render 480x320 for phones. For iPad specifically, if the video is 4:3, we recommend 4:3 end card as well, for example 1024x768.
  21. Will there be any integration or collaboration with Vine?
    • Currently there are no plans for this. All changes to our product roadmap with Twitter will be discussed and communicated at a later date.
  22. Do we need to certify vendors, similar to MRAID, or do we allow any/all video creatives?
    • If using VAST 2.0 or VAST 3.0, MoPub does not need nor require certification.

Video & Companion Banner Behavior

  1. Are there any differences to mobile video as compared to desktop video?
    • The VAST 2.0 and VAST 3.0 template is the same for desktop & mobile.
    • Unlike desktop, VAST Video ads in mobile are typically standalone ads and are not played as a pre-roll or post-roll in an existing video.
    • Desktop video ads are played in the browser while you are viewing a video. On mobile, we only play video ads within an app – mobile web is not supported.
  2. What video durations are supported and how do they differ?
    • Videos between 16-30s are referred to as “skippable videos”. Our platform automatically inserts MRAID controls to allow the user to skip or engage (click) with the video after 5s of video play. A countdown timer is automatically inserted for the first 5s of the video prior to becoming “skippable”.
    • Videos between 1-15s are referred to as “non-skippable videos”. Users are NOT able to skip or engage (click) with the video until the video fully completes. Our platform automatically inserts a countdown timer for these types of videos.
    • Some inventory now allows videos with duration between 31-120sec. MoPub is internally testing the viability of longer videos from a performance standpoint and partners should not submit videos with duration greater than 30sec until further notice. (N/A to server-to-server partners)
  3. Why is MoPub doing internal testing for 120 second video? (N/A to server-to-server partners)
    • Background on the “internal testing” for 120 second video: the biggest work that needs to be done for testing is ensuring we can quickly render videos that will be of much larger file sizes. Since we are not yet confident in a strong user experience for videos greater than 30 seconds, that is why we are doing internal testing.
  4. How long do you estimate the internal testing will be for 120 second video before DSPs can start submitting videos longer than 30 seconds? (N/A to server-to-server partners)
    • The rough estimate is 3 months.
  5. Will the user be able to engage with the “Learn More” button before the video-ad has completed playback?
    • For skippable video ads (> 15s), the user will be able to engage with the video ad by clicking the “Learn More” button after 5s of video-play has elapsed.
    • For non-skippable video ads (<= 15s), the user will not be able to engage with the video ad until the video has completed playing.
  6. If I serve a 15s video (non-skippable) but declare it incorrectly as a 16s video (skippable) in our bid response, what is the expected behavior?
    • MoPub will use the ‘true’ length of the video (15s) to determine whether this particular video ad will treated as a skippable/non-skippable ad.
    • So, in this instance; MoPub will disregard the 16s (skippable) declaration and display this video as a 15s (non-skippable) video ad to the end-user.
    • IMPORTANT – declaring your video ad’s length improperly and/or incorrectly in the bid response is considered a policy violation for not respecting the publisher’s video-ad duration requirements.
      • This note does not apply to server-to-server partners. The publisher and network are expected to discuss video preferences prior to serving video.
  7. Where can the user click within the video ad to engage with it?
    • Assuming the video ad is clickable, the user can click anywhere on the video body to engage with the video ad. This includes the “Learn More” button and the companion banner that appears after the video ad completes (if provided by the video tag).
  8. If we improperly serve a video ad longer than the publisher’s max allowable duration (maxduration), what is the expected behavior?
    • Your video will not be cut off prematurely if it is longer than the publisher’s max video duration. It will play to completion.
    • IMPORTANT – Please note that it is considered a policy violation for not respecting the publisher’s video-ad min/max duration requirements.
  9. Do videos close automatically when finished?
    • No. If an appropriate companion banner is provided in the VAST tag, we will display this comp banner once the video is finished playing.
    • Even if a companion banner is not available, we will always provide the user with an opportunity to engage further once the video is finished playing with an on-screen “Learn More” button.
  10. Is it possible to auto-close/dismiss companion banners?
    • No, this is not possible.
  11. If the publisher has locked their app’s orientation to portrait, how will the video ad render?
    • All videos will appear in landscape orientation unless all the following conditions are met:
      • SDK 3.9.0 or above
      • MoPubForceOrientation Extension present in the VAST XML
      • “Portrait” or “Device” option chosen for MoPubForceOrientation
    • If those conditions are met, the video-ad will render in portrait orientation; letter-boxed with black/bars on the top/bottom.
    • The video ad will not rotate if the user rotates the device to landscape in this situation.
  12. Do videos autoplay with sound on?
    • All sound will adhere to the hardware settings (i.e., if volume is off on the phone there will be no sound).
  13. What does the video ad space look like when I don’t have a companion banner?
    • End Card

Other

  • Examples of VAST XML Responses can be found here.
    1. Is there a maximum allowed bitrate for video media files?
    • There are no limitations on video bitrate, however, best practices here are: 1) Video bitrate combined with video duration should net out to a recommended file size of 2MB (recommended max 10MB). Videos that are closer to 2MB can have a better performance. 2) Ideally below 512kbps or lower.
      1. Would there ever be a case where the width and height from the banner are different from the width and height of the video? If yes, could you give the cases where that happens?
    • Yes – Most interstitial requests come in as Portrait in the impression object. However, the video object may be Landscape based on operating system and device size (regardless of ad unit size in bid request).
      1. Would there ever be cases where imp.banner object is empty or not present? (i.e. Is there such a thing as video-only requests, where the imp.banner object is not present and imp.video object IS populated)?
    • Marketplace Partners:
      • Yes – We call these “Video Only Line items.” These are cases when the publisher only wants a video to fill the ad space and does not want a static interstitial banner. We recently offered this functionality to Publishers, so volume on video-only requests is lower but in theory should be higher value. In early days, we’ve seen that more “premium” publishers prefer video-only over the chance of getting video or static ads. 
      • We keep track of which impressions are “just banner” vs. “just video” vs. “both” in MMX under the “Video or Banner” dimension.
    • Server-to-Server Partners:
      • No

Best practice for DSPs to serve Vertical video

  • Use OpenRTB 2.3
  • Read width “w” and height “h” values. Choose w < h values
  • Serve to only 3.9.0 and above (Android, all iOS SDKs OK)
  • Use the “Portrait” (best option) or “Device” (works on rotate) MoPubForceOrientation Extension
  • Include a portrait 320×480 or 768×1024 companion banner (depending on the bid request size)

Changelog

  • May 3, 2017 – Added CloudFront & China information
  • Apr 21, 2017 – Clarified when VAST start tracker fires
  • Feb 25, 2016 – Added documentation for server-to-server partners
  • Sep 9, 2015 – Added best practices for RTB 2.3
  • July 1, 2015 – Support for VAST 3.0 released and documentation updated accordingly
  • Jan 29, 2015 – Third-party macros issue has been fixed
  • Jan 22, 2015 – Non StaticResource companion banner issue has been fixed.
  • Jan 22, 2015 – Serving VASTAdTagURI wrapper tags via SSL (https) has been fixed.
  • Oct 21, 2016 – Added documentation for opt-in rewarded video.

Last updated May 22, 2018

TWITTER, MOPUB, and the Bird logo are trademarks of Twitter, Inc. or its affiliates. All third party logos and trademarks included are the property of their respective owners.

© 2018 MoPub Inc.