Serve video ad units (VAST)
Third-party in-stream video ads are accepted on Ad Exchange according to the technical specifications and policies outlined below. Support for in-stream video ads applies to mobile applications and on sites accessed through mobile browsers.
Third-party in-stream ads must be served via a linear VAST pre-fetch tag by a VAST vendor approved specifically for Ad Exchange. See the list of approved Ad Exchange vendors.
New Flash video ads can no longer be uploaded into DoubleClick Studio, DoubleClick Campaign Manager, DoubleClick Bid Manager, DoubleClick for Publishers or AdWords.
Flash video ads can no longer run through DoubleClick Campaign Manager, DoubleClick Bid Manager, DoubleClick Ad Exchange, DoubleClick for Publishers or AdWords. Additionally, our Active View and Verification tools for video no longer uses Flash. Learn more about how Google video ads have transitioned to HTML5.
In-stream video ad
|Unit sizes||File types||File size||Video length||Frame rate|
|Video ads can render in any sized player.*
H.264 (MP4) video file type must be included **
Other formats, such
as HLS can be included but may not be used.
MP3 or AAC preferred.
|Maximum and minimum ad durations are set by publishers.
Although most inventory allows up to 15 seconds maximum ad duration, some requests allow 60 or more seconds.***
Some connected TV devices require that you add an HLS-encoded media file to your VAST response.
It is strongly recommended that you include an MP4 with at least 1080p resolution for ads served against high-quality, TV-styled content.
** The user device, with help from the IMA SDK chooses the first media file it encounters where the file type listed is a video format that the device can understand. This is determined by client-side software that is run for video ad requests. The MP4 requirement ensures sufficient device coverage.
*** Publishers commonly allow longer durations for skippable ads (determined by the
skippable_max_ad_durationsignal). If you have longer format ads, such as 60 or more seconds, consider making them skippable to improve your reach.
Companion ad (optional, but recommended)
|Unit sizes||Resource types||File size||Animation length||Frame rate|
Static GIF, JPG, PNG
within an iframe on the publishers page.
See section 188.8.131.52 of the
VAST specification for more details.
(rollover or click)
- All VAST tags must comply with the Google XML summary for VAST ad server response.
- Audio is not allowed for companion ads.
- Creatives may not expand past ad unit boundaries.
- On all ads with partially black, white, or transparent backgrounds, you must add a visible border of a contrasting color to the majority background color of the creative.
- All creatives must be free of applications, such as ActiveX, viruses, exit pops, spyware, and malware.
- Creative coding may not use cross-domain scripting or set cookies in unapproved domains.
- All creatives must open in new windows. The target window for the clickthrough URL must be set to
"_blank"so the URL will open in a new window. Do not leave the target statement undeclared.
- For each video ad served in a VAST tag, a
<mediafile></mediafile>node is required for the MP4 video format. Other formats, such as HLS may be included but might not be used. If a tag does not include each of the formats, it will only serve on the players with the included formats.
Missing media files do not result in disapproved ads, but are filtered at runtime. Progressive is required. Streaming is optional.
<adsystem></adsystem>node value: Please be sure that your all of your VAST tags include a specific consistent value for your company in the
<adsystem></adsystem>node in the VAST XML. For example, Google always includes the following for VAST tags:
- Unique ad ID value: Each VAST tag generated should include a unique value for the
idattribute in the
<ad></ad>node. Two different VAST tags should not have the same Ad id value. For instance:
- VAST tag 1:
- VAST tag 2:
- VAST tag 1:
- Note that only the following resource types will be allowed for
<companion></companion>node in the VAST XML:
StaticResource: URI to a static file, such as an image or SWF file
IFrameResource: URI source for an iframe to display the companion element
HTMLResourcetype is not permitted.
Google HTML5 SDK
In order for Google’s HTML5 SDK to serve video ads from a third-party ad server, the third-party ad server must include a CORS header in all of its responses. The CORS header must be formatted as follows:
Access-Control-Allow-Origin: [allow domain access from the originating request]
Access-Control-Allow-Origin: * option cannot be used in combination with
- No more than two VAST wrappers that redirect to one VAST in-line is permitted.
TrackingEvents(wrapper may include more than one node per each event):
All publisher inventory accessible via Ad Exchange has a secure connection (SSL) and requires SSL-compliant creatives.
For more information, see the SSL implementation guide.
- Vendors must receive separate certification to serve VAST ads on SSL-compliant publisher inventory.
- All ad responses must be SSL-compliant (
HTTPS). All servers involved require full SSL certification.
- VAST tags should auto-detect requests from an
HTTPSprotocol and auto-adjust the URIs and companion banners to be SSL-compliant, if necessary. Google has a protocol macro that can be inserted in your VAST tag to auto-update the protocol, if necessary.
- Vendors and buyers must ensure that any URIs within the VAST XML (for instance, the
<mediafile></mediafile>, and other nodes) that are served by a party other than the primary VAST vendor are also from vendors approved by Google for SSL-compliant ad serving or tracking.
- Companion ad banners as well as any fourth-party calls to other technologies within the companion ad banner must also be made from SSL-compliant vendors that have been certified by Google.
- Buyers must declare through RTB or the Ad Exchange UI that the ad is SSL-compliant. If an ad is declared as SSL-compliant but makes any non-SSL-compliant responses, the ad will be disapproved.