Creative specs

Ad Types

Linear Video Ad Slots

Ad Serving Capabilities

IAB Ad Standards

User Experience

• Full Screen
  • USER CHOICE: User may opt to view ad and/or content in full screen mode. Application code may not trigger this state without explicit user consent.
• Ad Skipping
  • VPAID APP: VPAID ad may opt to show skip ad option. Player will not present ad skipping to the user.

• Video Click Area: Area within player where click events are available to trigger a click-through or other interactive activity.
  • VPAID APP: Ad controls click area within the available display area.
• Player Controls: Controls presented to user during ad experience playback.
  • FULL: Full range of controls are presented as a lower 1/3 frame overlay that appears on mouse over or tap on the player area (controls include: play/pause, mute, volume control and possibly more)
  • REDUCED: Video player controls are reduced to only play/pause and mute controls presented in top & bottom frame slim, permanent overlays to avoid player UI overlap with “bug” or other interactive elements.
• Display Area: Area within player which is available to the VPAID ad.
  • FULL: Full frame of player is available (note: players controls presented as overlays are not deducted from the display area; ads should take this padding into consideration when certifying ad formats on MSN)
  • REDUCED: Video player will reduce the player display area to accommodate for persistent player controls. VPAID ads will be made aware of the available area through the initAd() and resizeAd() method calls.

This specification covers linear video ad formats that are third-party served (ad is delivered via IAB’s Video Ad Serving Template (VAST)).

All third-party ad servers must meet the below requirements:

• Vendor certification is required for each IAB standard and version. Work with your account team representative to verify certification or request certification for new vendors

• Third Party Served VAST tags are required to return an ad each time the tag is called. Ad tags provided by agencies/advertisers or their contracted vendors should not restrict ad responses based on upstream or buy side targeting or capping. Publisher targeting will be enforced at the time of booking per the IO contract. This includes, but is not limited to: GEO targeting, Audience or BT targeting, frequency capping, Dayparting, etc… Furthermore, ad tags provided on a specific advertiser/brand IO contract should not rotate in ads from advertisers or brands not covered on the IO contract.

  The following scenarios are deemed acceptable occasions when the ad may not return or may change its ad response: Ad tag is outside the agreed upon flight dates; ad is rotating between multiple ad creatives for the same brand. Note that while ad rotation is supported, all ads returned must comply with all Microsoft Advertising policies.

• Inline ad responses are expected to provide only one (1) ad per VAST ad call. Tags may rotate the response upon refresh but may not provide more than one ad element within the XML document.
• The duration node must be formatted as HH:MM:SS per the IAB specification. Furthermore, the duration node should represent the ad unit length (or expected ad unit length if unknown at time of VAST rendering) — it is not permitted to return a duration of 00:00:00 or 00:00:01.
• Media files present in the ad response should provide the full range of supported frame sizes and bit rates, sorted in order of preference HD, Mobile HD, SD, Mobile SD (specifications as indicated in the above table). Please do not attempt to perform device/bandwidth detection to scope the available media files list; players will make the appropriate bit rate selection client-side.
• Pop-up and pop-under windows are not supported on any product.

• Ad tag tokens will not be evaluated at runtime by the player. The VAST ad tag URL should be returned fully decorated by the ad server returning the wrapper ad response. This includes but is not limited to cache busting tokens.
• The maximum number of chained wrappers supported is currently 3 with the 4^th tag expected to provide an inline ad response. Chains longer than this number cannot be guaranteed for delivery or reporting accuracy.
• Per the IAB specification, the wrapper ad tags may provide tracking events only, no additional assets may be delivered through the wrapper payload. This includes but is not limited to: ad parameters, or media files.

• Ad selector
  • Ad selectors must time out and select a default ad if no user interaction is detected. Furthermore, ad selector timeouts will count toward the maximum duration specified above and the sum of the timeout and the ad video may not exceed the max duration.
• Countdown / Time Remaining
  • The MSN player will provide a countdown to the user to indicate the time until the ad completes. VPAID ads must implement the adRemainingTime property and adRemainingTimeChange event to indicate changes to the player to ensure that the countdown is accurate and to avoid unexpected timeouts within the player from prematurely unloading the ad experience.
  • Ads are discouraged from presenting their own countdown UI to avoid a poor user experience of displaying redundant information.
  • Ads should similarly not force their content to the top -most z-index to hide the countdown and mini- control bar; this action will be periodically detected, and MSFT may opt to pull ads exhibiting this behavior.
• Error Handling
  • Per the IAB specification, all errors within the ad must not be raised to the player unless communicated through the adError event.
  • Furthermore, ad errors encountered during specific IAB events (AdImpression, AdVideoStart, AdVideoFirstQuartile, AdVideoMidpoint, AdVideoThirdQuartile, AdVid eoComplete) should not prevent the player from receiving these events (for example, if the ad is detecting user behavior during these events and has an internal failure, the ad is still required to notify the player of the IAB events for proper tracking and metrics — ads failing to report properly may be pulled).
• Expansion/interactive ad experience
• Ads may enter into an interactive state (video is paused, and interactive content is shown in the player window) or an expanded state (ad content has exceeded the standard max duration at the user’s explicit request for more information).
• Entrance: Accessible only on click of an interactive element not larger than 10% of the video area or on hover of an interactive element not larger than 10% of the video area with a minimum 5 seconds of hover time and visible indicator of the impending action as the user is hovering (i.e. progress bar, decreasing clock wedge, numerical countdown, etc.…)
• Exit: Exit button must be clearly displayed and distinguished in the top-right hand corner of the video frame, with the smallest edge not smaller than 32px. Ads failing to comply with this requirement will be pulled or blocked from launch and vendors will be placed on certification review.
• Z-index
  • No z-index should be set by the ad. If one is required, the z-index value cannot exceed 100.
• Leave behind content.
  • Linear VPAID ads may not leave behind any content after the ad video completes. Once the ad completes, the VPAID ad will be unloaded, and all visual and non-visual objects must be removed and disposed.
• Max Duration
  • 30s – all other MSFT properties – unless user explicitly chooses to enter into an interactive ad experience (see below for restrictions)
• Resizing
  • Ads must respond when the resizeAd() method is invoked; while a 16x9 ratio is expected, it is not guaranteed, therefore ads should scale their content appropriately and not rigidly adhere to one display ratio. Ads should immediately resize, when instructed, to avoid a poor user experience and to reduce display flicker.
• Video Click Thru
  • Ads can opt to process video click events on interactive elements as they see fit; however, the following requirements must be followed for standard video click-thrus and for any navigation to pages outside of the player window:
    • If the video playback pauses on click, the ad must render a resume button over the video content so that the user can resume the ad and reach the content experience.
    • The VPAID AdClickThru event must be raised for video click-thrus. If the ad opts to handle the click thru directly, the destination page must open in a new (non-modal) tab/window and must not replace the current window/frame.

IAB VPAID 2.0 Support Limitations

• Only VAST 3.0 delivery is supported at this time (see related linear video spec for more details), it is important to note that skip functionality is not supported within the player. Therefore, if skip functionality is desired VPAID 2.0 should be used.

VPAID Vendor Certification

All VPAID vendors must submit test assets for certification prior for running VPAID ads on Microsoft Advertising properties. Please work with your account team representative to submit for VPAID vendor certification. VPAID vendors are expected to VAST deliver their VPAID ad content. If the VPAID vendor will also serve linear video through the same ad server to Microsoft Advertising, they should submit for both VAST and VPAID vendor certification. Otherwise, if the VAST payload is mostly static and does not vary by advertiser, only VPAID certification is required.

VPAID Interface Requirements:

• All functions and properties on the VPAID object interface MUST be present even if their return values are NULL or methods are not implemented.
• VPAID ad must respond to the initAd() method call within a reasonable time or risk being unloaded due to a timeout. Timeouts can vary by player, but common limits are between 5-10 seconds.
• VPAID ad must respond to the startAd() method call within a reasonable time or risk being unloaded due to a timeout. Timeouts can vary by player, but common limits are between 5-10 seconds.
• VPAID ad must update the adRemainingTime property with the actual duration of the ad or clearly indicating an unknown value within the first second after the video start event.
• AdStarted event and AdImpression event must fire as simultaneously as possible.

Cross-Domain Data Requests

Vendor ad servers, CDNs, and all server-side resources referenced in the VAST tag and VPAID ad must allow Microsoft & Microsoft partner domains (*msn.com; *.fwmrm.net; *.s-msn.com) to access cross-site data via the following method:

• CORS HTTP Headers: Server response headers must contain ‘allow origin’ CORS HTTP headers as documented at: http://www.w3.org/TR/access -control/#access-control-al low-origin-response-header. Allow origin headers can reply with a wild card or by echoing the source origin. Please refer to the w3 documentation for details on the benefits/risks for both options.

  • Example CORS response header:

    Access-Control-Allow-Origin:   *

Discrepancy rates between ad servers

Microsoft does not provide guarantees relating to 3rd party served discrepancies but will commit to investigate discrepancies that exceed accepted industry standard discrepancy rates.

Server-to-server ad calls

Microsoft does not currently employ server-to-server ad calls for vendor ad tags. Furthermore, it is strongly preferred that Microsoft provided ad tags for third-party sourced inventory are called directly from the client, however, server-to-server ad calls can be supported provided the following attributes are communicated to the MSFT ad server on the ad call (work with your account team to get specific query-string parameters for these attributes).

• Client IP Address
• User Agent

Max tracking pixels per event

While no hard limit is enforced on the MSFT properties, the maximum recommended number of tracking pixels per event is set at five (5). This limit is proposed to reduce risk of latent or dropped event tracking and ensure discrepancy rates within industry norms.

The following events are supported across the video product portfolio for first-party and third-party served ads.

Video Events

• Play (Impression)
• Video Click1
• First Quartile
• Midpoint
• Third Quartile
• Complete
• Pause1
• Mute1
• Unmute1
• Close1

MSN Video

Overview

This specification covers linear video ad formats for third-party served (ad is delivered via IAB’s Video Ad Serving Template (VAST)). Please refer to the section and columns headers when reading this document as some elements of the specification vary depending on which party is serving the ad.

Ad specifications

Third-party ad served video (VAST)

Outstream Video ad creative must be delivered by certified third-party ad servers. All third-party ad servers must be certified with Microsoft for each IAB standard and version. Work with your representative to verify certification or request certification for new vendors.

Examples

Outstream Video

Video in Display