This article shows a complete list of parameters that can be used in a VAST ad tag. It may be useful to you if you want to know more about a specific parameter.
See a clickable alphabetical index of all parametersOn this page
- Parameters required for ad serving
- Parameters required for programmatic
- Parameters recommended for programmatic
- Other parameters
Parameter lists by implementation type
If you're using a specific implementation, you can use custom parameter lists that outline the usage and requirements for that implementation. Use the custom parameter list for:
Web Mobile app Connected TV Audio Digital out-of-home
All parameters
Parameters required for ad serving
In general, these parameters are required for ad serving for most implementations. However, there my be instances where they are not required. For the most accurate listing, use the parameter list for your specific implementation type.
correlator (Correlator)
Description
The correlator parameter (correlator) accepts a variable value that is shared by multiple requests coming from the same page view. It's used to implement competitive exclusions, including those in cookieless environments.
Usage examples
correlator=4345645667
Requirements and recommendations
This parameter is required to implement ad serving in web, mobile apps, connected TV, audio, and digital out-of-home.
SDK usage
- If the IMA SDK is used, the correlator value is set automatically. If your player attempts to set this value, the SDK overwrites it with its own value.
- If the IMA SDK is not used, ensure that you set this value to a truly random, positive, integer value that is not being reused by multiple page views.
description_url (Description URL)
Description
The description URL parameter (description_url) accepts a variable value that should describe the video playing on the page.
The description URL should be about the videos playing on a specific page of a web app, mobile app, or TV app. It should not be the top-level domain for all videos or all ad requests. For example, if you have a https://www.sample.com/golf.html page for showing videos about golf, set it as the value of description_url.
Usage examples
The description_url value must be URL-encoded for web pages with videos and CTV/OTT devices. However, the description_url value must not be encoded for mobile apps.
URL-encoded:
description_url=
https%3A%2F%2Fwww.sample.com%2Fgolf.html
Not encoded:
description_url=
https://www.sample.com/golf.html
Requirements and recommendations
This parameter is required to implement ad serving in web and mobile apps. It is also required if you use Ad Exchange or AdSense for dynamic allocation.
This parameter is recommended for programmatic monetization.
SDK usage
This parameter is not set automatically by the IMA SDK. It needs to be set manually.
Refer to the IMA SDK guides for your platform.
env (Environment)
Description
The environment parameter (env) accepts a constant value that indicates an in-stream request, or that the request is specifically from a video player.
Possible values are instream, which can be used for video and audio ads, or vp which can only be used for video ads.
Usage examples
Video and/or audio:
env=instream
Video only:
env=vp
Requirements and recommendations
This parameter is required to implement ad serving in web, mobile apps, connected TV, audio, and digital out-of-home.
This parameter is required to accurately report on request type broken down by "Video tag".
gdfp_req (Schema indicator)
Description
The Google Ad Manager schema indicator parameter (gdfp_req) accepts a constant value which indicates that the ad request is for Google Ad Manager inventory.
Usage examples
gdfp_req=1
Requirements and recommendations
This parameter is required to implement ad serving in web, mobile apps, connected TV, audio, and digital out-of-home.
iu (Ad unit)
Description
The ad unit parameter (iu) accepts a variable value which should be set to the current ad unit, in the format: /network_code/.../ad_unit.
Usage examples
iu=/6062/videodemo
Requirements and recommendations
This parameter is required to implement ad serving in web, mobile apps, connected TV, audio, and digital out-of-home.
output (Output)
Description
The output format parameter (output) accepts a constant value which should be set to the output format of the ad.
Usage examples
Use your network's default VAST version:
output=vast
Use VAST 4 (you can set specific versions for specific tags):
output=xml_vast4
Use your network's default VMAP setting:
output=vmap
Use VMAP 1:
output=xml_vmap1
Use VMAP 1, returning VAST 4 (if you return VAST inside of VMAP):
output=xml_vmap1_vast4
Requirements and recommendations
This parameter is required to implement ad serving in web, mobile apps, connected TV, audio, and digital out-of-home. It is required to output the correct ad serving response format.
SDK usage
For VAST, if your video player uses the IMA SDK, the output parameter for a video ad request will always be set to output=xml_vast4. This poses no reliability risk as the SDK is backwards compatible with all VAST versions that any third-party ad server may serve.
sz (Size)
Description
The size (sz) parameter accepts a variable value which should be set to the size of master video ad slot.
Multiple sizes should be separated by the pipe (|) character.
Do not include "v" after the size.
Usage examples
Single size:sz=400x300
Multiple sizes:sz=300x250|400x300
Requirements and recommendations
This parameter is required to implement ad serving in web, mobile apps, connected TV, and digital out-of-home.
This parameter is optional if only requesting ad_type=audio.
unviewed_position_start (Delayed impressions)
Description
The delayed impressions (unviewed_position_start) parameter accepts a constant value to indicate delayed impressions for video.
Usage examples
unviewed_position_start=1
Requirements and recommendations
This parameter is required to implement ad serving in web and mobile apps when there is a delayed impression opportunity.
url (URL)
Description
The URL parameter (url) accepts a variable value which should be set to the full URL from which the request is sent. This value is needed to help buyers identify and understand the context of where this request is coming from. To the extent possible, this value should be dynamically populated on the ad request.
- On web, this is the URL of the page that displays the video player.
- In non-web environments, this should be set to a URL that most accurately represents the video or audio inventory being monetized. For instance, if the user is watching a video within a mobile app that is also available on a desktop equivalent URL.*
Note: url differs from description_url in that url refers to the location that an ad request was made from whereas description_url is a web crawlable page that describes the video content.
The value of this parameter should be encoded.
Usage examples
url=https%3A%2F%2Fwww.example.com%2Fvideo.html
* For apps, if it's not possible to set this parameter to a variable URL value, the following pattern is recommended: url=https%3A%2F%2F<app/bundleid>.example.com
Requirements and recommendations
This parameter is required to implement ad serving in web, mobile apps, connected TV, audio, and digital out-of-home.
SDK usage
If you use the IMA SDK, the URL value is set automatically. If your player sets this value, the IMA SDK will respect the value being set.
vpmute (Video play mute)
Description
The video play mute parameter (vpmute) accepts a constant value which indicates whether the ad playback starts while the video player is muted. This parameter does not change the state of the video player, playback behavior must be handled directly by the video player.
Usage examples
Playback starts muted:
vpmute=1
Playback starts unmuted:
vpmute=0
Requirements and recommendations
This parameter is required for programmatic monetization in web, mobile apps, connected TV, audio, and digital out-of-home.
This parameter is also recommended per The Media Rating Council (MRC) Video Measurement Guidelines.
Parameters required for programmatic
ott_placement (Custom formats)
Description
The custom formats parameter (ott_placement) accepts a constant value which indicates a request for a non-in-stream OTT placement.
Placement definitions for the examples below:
- Pause: Out-stream format that appears via an overlay on top of video content when a user pauses content playback.
- Homescreen: Ad that appears on the homescreen of a CTV device or OTT app. This includes masthead, banner, and tile implementations on a homescreen.
- Picture-in-picture: In-stream video ad played in a separate ad video player beside video content. Typically requires squeezing back video content and loading a second video player.
- L-banner: In-stream display ad that involves squeezing back video content and creating an ad around the video. Typically, but not limited to, an L-shaped ad content box.
- Overlay: Any in-stream ad format that appears on top of video content but does not take up the full screen. Can be a display or video ad.
Usage examples
Supported formats and their corresponding avlues:
Pause:
cust_fmt=1
Homescreen:
cust_fmt=2
Picture-in-picture:
cust_fmt=3
L-banner:
cust_fmt=4
Overlay:
cust_fmt=5
Custom/other:
cust_fmt=99
Requirements and recommendations
This parameter is only required for programmatic monetization in web, mobile apps, and connected TV for publishers monetizing non-standard placements on OTT streaming environments.
plcmt (Placement)
Description
The placement parameter (plcmt) accepts a constant value which is used to indicate whether or not the in-stream inventory is declared as "Instream" or "Accompanying" per the guidance in the IAB specifications.
For non-in-stream requests, this is automatically populated for buyers based on the declared inventory format which overrides any in-stream or accompanying declaration.
Usage examples
In-stream request:
plcmt=1
Accompanying content request:
plcmt=2
Requirements and recommendations
This parameter is required for programmatic monetization in web, mobile apps, connected TV, audio, and digital out-of-home.
venuetype (Venue type)
Description
The venue type parameter (venuetype) is used to indicate the type of out-of-home venue. Values eligible are the integer enumeration IDs supported by the IAB OpenOOH venue type 1.1 taxonomy.
Usage examples
Hotel rooms:
venuetype=80703
Tablet in a taxi backseat:
venuetype=103
Requirements and recommendations
This parameter is required for programmatic monetization in digital out-of-home.
vpa (Video play automatic)
Description
The video play automatic (vpa) parameter accepts a constant value which indicates whether video content in an ad starts through autoplay or click.
Possible values are click if the page waits for a user action or auto if the video plays automatically. This parameter does not change the state of the video player, playback behavior must be handled directly by the video player.
Usage examples
Autoplay:
vpa=auto
Click to play:
vpa=click
This parameter should be left unset if it is unknown.
Requirements and recommendations
This parameter is required for programmatic monetization in web, mobile apps, connected TV, and audio.
This parameter is also recommended per The Media Rating Council (MRC) Video Measurement Guidelines.
Parameters recommended for programmatic
aconp (Audio continuous play)
Description
The audio continuous play parameter (aconp) accepts a constant value that indicates whether the player intends to continuously play audio content. This helps Google Ad Manager select the most suitable ads for the user experience.
Usage examples
Continuous play on:
aconp=2
Continuous play off:
aconp=1
If you don't know whether audio plays continuously, this parameter should be left unset or set to aconp=0.
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is recommended for programmatic monetization in web, mobile apps, connected TV, audio, and digital out-of-home.
This parameter is also recommended per The Media Rating Council (MRC) Audio Measurement Guidelines.
an (App name)
Description
The app ID parameter (msid) and app name parameter (an) accept variable values which should be applied to requests sent from mobile app and connected TV devices, as most programmatic video ads require them.
While the app name should be a human-readable name, on iOS and tvOS, it's not possible for the SDK to access the app ID. In these cases, the msid parameter is not sent, and the SDK sends the app bundle via the an parameter.
Usage examples
msid=com.package.publisher&an=sample%20app
App IDs are named and formatted differently across different app stores. See the IAB guidelines for app identification, or examples of common unique identifiers.
For platforms where an app store does not exist, the IAB recommends publishers use the following format for store IDs: com.publisher.deviceplatform
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is recommended for programmatic monetization in mobile apps, connected TV, audio, and digital out-of-home.
For brand safety and allowing more transparency to buyers, including the app information is highly recommended.
SDK usage
The IMA SDK will automatically populate both parameters, but they must be manually specified in non-SDK environments, including direct VAST calls, or when using Programmatic Access Library (PAL) or Publisher Authenticated Inventory (PAI).
Note: If the HTML5 IMA SDK is used, then app info is not used.
dth (Device type hint)
Description
The device type hint parameter (dth) accepts a constant value that helps reduce device misclassification, specifically on connected TV and set top box environments.
Device misclassification may result from unintended errors from the publisher or connected TV OEM. This parameter would be used in conjunction with other signals for Google to automatically flag instances where connected TV inventory may be reclassified.
Usage examples
Requests from:
- Feature phone:
dth=1 - Smart phone:
dth=2 - Desktop:
dth=3 - Tablet:
dth=4 - Connected TV:
dth=5 - Game console:
dth=6 - Set top box:
dth=7
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is recommended for programmatic monetization in web, mobile apps, connected TV, audio, and digital out-of-home.
SDK usage
This parameter is recommended for PAL and PAI (non-SDK) implementations. It is not needed for IMA SDK or DAI SDK.
givn (Video nonce)
Description
For integrations that use the Programmatic Access Library (PAL), the video nonce parameter accepts a variable string value.
The nonce is URL safe—you don't need to URL-encode it.
Note: If you previously provided a nonce using the legacy paln parameter, it is strongly recommended to migrate to the givn parameter and stop sending paln. Do not include both parameters.
Usage examples
Read more about the value passed to this parameter in the getting started guides for PAL.
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is recommended for programmatic monetization in web, mobile apps, connected TV, audio, and digital out-of-home.
hl (Language)
Description
The language parameter (hl) accepts a constant value which is used to request ads in that language, and for language of ad selection and video ad rendering in dynamic allocation to Ad Exchange or AdSense Video.
Usage examples
Request ads in Italian:
hl=it
The parameter value can be any ISO 639-1 (two-letter) or ISO 639-2 (three-letter) code. See a list of valid codes.
If omitted, the value defaults to any language with ad targeting by language in Ad Exchange.
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is recommended for programmatic monetization in web, mobile apps, connected TV, audio, and digital out-of-home.
msid (App ID)
Description
The app ID parameter (msid) and app name parameter (an) accept variable values which should be applied to requests sent from mobile app and connected TV devices, as most programmatic video ads require them.
While the app name should be a human-readable name, on iOS and tvOS, it's not possible for the SDK to access the app ID. In these cases, the msid parameter is not sent, and the SDK sends the app bundle via the an parameter.
Usage examples
msid=com.package.publisher&an=sample%20app
App IDs are named and formatted differently across different app stores. See the IAB guidelines for app identification, or examples of common unique identifiers.
For platforms where an app store does not exist, the IAB recommends publishers use the following format for store IDs: com.publisher.deviceplatform
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is recommended for programmatic monetization in mobile apps, connected TV, audio, and digital out-of-home.
For brand safety and allowing more transparency to buyers, including the app information is highly recommended.
SDK usage
The IMA SDK will automatically populate both parameters, but they must be manually specified in non-SDK environments, including direct VAST calls, or when using Programmatic Access Library (PAL) or Publisher Authenticated Inventory (PAI).
Note: If the HTML5 IMA SDK is used, then app info is not used.
omid_p (OMID partner name)
Description
The OMID partner name parameter (omid_p) accepts a variable value which indicates the name of the partner integrating OMID measurement, and the partner version.
The supported SDK APIs parameter (sdk_apis) accepts variable values which can either be a single or comma-separated list of supported APIs.
These parameters are parts of a set of parameters used for viewability and ad verification.
Usage examples
When not using PAL:
omid_p=examplepartnername/1.0.0.0&sdk_apis=7
See a list of possible API Framework values.
When using PAL:
request.omidPartnerName = 'examplepartnername'
request.omidPartnerVersion = '1.0.0.0'
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is recommended for programmatic monetization in web, mobile apps, connected TV, audio, and digital out-of-home.
SDK usage
- This parameter is only applicable to publishers wanting Active View measurement when using the Open Measurement SDK (OM SDK).
- To indicate OMID support when using Programmatic Access Library (PAL), you need to use
omidPartnerNameandomidPartnerVersionto set the partner name and version. When not using the PAL or IMA SDK, you must set theomid_pandsdk_apisparameters. - This should not be used when using the IMA SDK as it is set automatically.
rdid (Resettable device identifier)
Description
The resettable device identifier parameters (rdid, idtype, is_lat) accept variable values. This value is also known as the identifier for advertising (IFA).
With mobile applications using the IMA SDK for Android or iOS, the IMA SDK passes resettable device identifiers for user targeting into your stream requests with the parameters for rdid, idtype, and is_lat.
When IMA SDK is not used or when server-side beaconing (SSB) is used, you must pass these as explicit parameters. Learn more about device identifiers.
Nearly all programmatic video ads require the presence of these values.
LAT signal. Google instead relies on the presence of a non-zero IDFA to indicate that the user has consented to tracking on versions of iOS that support App Tracking Transparency. As such, a valid UserAgent indicating the correct OS version is required.Usage examples
See detailed examples of resettable device identifiers.
Requirements and recommendations
While these parameters are not required to serve ads to any specific implementation, they are required for programmatic monetization in mobile apps, connected TV, audio, and digital out-of-home.
For web implementations, resettable device identifiers are not used.
SDK usage
While the IMA SDK automatically passes this field, publishers pass these parameters manually when using the PAL SDK.
sid (Session ID)
Description
The session ID (sid) parameter accepts a variable value which is a privacy-preserving advertising identifier that is used for frequency capping purposes only.
Session ID is supported for in-stream video requests from connected TVs and on in-stream video inventory from mobile app devices. It is not currently supported for web.
You can opt out of passing the session ID by setting sid=0.
Usage examples
sid=123e4567-e89b-12d3-a456-426614174000
Per the IAB's IFA guidelines, this parameter must be populated in UUID format. Learn more about resettable device identifiers for user targeting.
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is required for programmatic monetization in digital out-of-home.
This parameter is recommended for programmatic monetization in mobile apps, connected TV, and audio.
SDK usage
This parameter is sent automatically by the IMA SDK.
vconp (Video continuous play)
Description
The video continuous play (vconp) parameter accepts a constant value which indicates whether the player intends to continuously play video content, similar to a TV broadcast.
Usage examples
Continuous play ON:
vconp=2
Continuous play OFF:
vconp=1
This parameter should be left unset if it is unknown.
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is recommended for programmatic monetization in web, mobile apps, connected TV, and audio.
This parameter is also recommended per The Media Rating Council (MRC) Video Measurement Guidelines.
vid_d (Video duration)
Description
The video duration (vid_d) parameter accepts a variable value which specifies the duration of the content, in seconds.
- The
vid_dandallcuesparameters are used to serve mid-roll ads without content ingestion. - The use of ad rules is required to return mid-rolls. If time-based cues are used in your ad rules (for example, "Every N seconds" or "At fixed times"), then those set in the ad rule are used, and the cues passed into
allcuesare ignored. Mid-rolls still require duration, sovid_dmust still be passed.
Usage examples
Video content duration of 90000 seconds (25 hours):
vid_d=90000
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is recommended for programmatic monetization in web, mobile apps, and connected TV.
vpos (Video position)
Description
The video position (vpos) parameter accepts a constant value which indicates whether the ad request is being sent from pre-roll, mid-roll or post-roll.
Usage examples
Pre-roll:
vpos=preroll
Mid-roll:
vpos=midroll
Post-roll:
vpos=postroll
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is recommended for programmatic monetization in web, mobile apps, connected TV, and audio.
If ad rules are used, this parameter is not needed as it's automatically added by the ad server.
wta (Why this ad)
Description
The "Why this ad?" parameter (wta) accepts a constant value which indicates the video player's support for rendering ad badging.
Usage examples
If the player should render the AdChoices icon provided in the VAST response, use:
wta=1(or omit thewtaparameter, or passwtawith no value set)Audio requests should use
wta=1if the AdChoices icon provided in the VAST response will be rendered on companions or otherwise provided to the user.
If the player should not render the AdChoices icon provided in the VAST response, use:
wta=0
Requirements and recommendations
While this parameter is not required to serve ads for any specific implementation type, it is recommended for programmatic monetization for web, mobile apps, connected TV, and audio.
When the parameter is used:
&wta=0traffic isn't eligible for certain types of personalization from Google Demand.&wta=0traffic from EEA is not eligible for creatives with ad badging enabled on reservation and publisher-managed Programmatic Guaranteed line items.
Ads must comply with applicable regulatory requirements for ads served in the European Economic Area (EEA). This includes a mechanism for users to report illegal content. Publishers must notify Google of any illegal content reports using the Report Content on Google form.
SDK usage
The ad badging functionality is supported automatically when using the IMA SDK. When the IMA SDK is not used, video players must implement VASTIcon and IconClickFallbackImage support, as documented in the IAB VAST standard.Other parameters
In general, these parameters are not explicitly required to serve ads, but may be required to use certain features, or may be required for certain implementation types.
ad_rule (Ad rule)
Description
The ad rule parameter (ad_rule) accepts a constant value that indicates whether to return a VAST creative or an ad rules response.
The default setting for ad rules depends a Google Ad Manager network setting which enables all requests to be ad rule requests. If the network setting is used, then ad_rule does not need to be set in the ad tag. If you want to disable on an ad request basis, then you can pass ad_rule=0 to override the network setting. Also, if you do not have ad rules on by default, you can enable/disable by passing ad_rule=1 and ad_rule=0, respectively.
Usage examples
If the ad rules setting is disabled:
- Request for VAST creative:
ad_rule=0or do not set
If the ad rules setting is enabled:
- Request for VAST creative:
ad_rule=0 - Request for ad rules (VMAP):
ad_rule=1or do not set
If you choose not to utilize ad rules, you can use ad tag parameters to indicate ad break and pod duration for your VAST tags using pmnd, pmxd, and pmad.
Requirements and recommendations
While this this parameter is not required to serve ads for any specific implementation type, it is required to correctly use video ad rules.
addtl_consent (Additional consent)
Description
The Additional Consent parameter (addtl_consent) accepts variable values and is used by publishers who wish to integrate with the IAB TCF v2.0 and use a vendor that is not yet registered with the IAB Europe Global Vendor List but are on Google's Ad Tech Providers (ATP) list.
You can read more about the values passed to this parameter in the Additional Consent Mode technical specification.
Usage example
addtl_consent=1~1.35.41.101
adtest (Ad test)
Description
The ad test parameter (adtest) should be used to ensure that queries used to test backfill (non-guaranteed) inventory aren't be identified as invalid traffic, and do not have a revenue impact.
When testing backfill, set this parameter to on to ensure that no ads log impressions or clicks for use during testing. Set to off in non-testing environments to bill normally. If left unset, this parameter defaults to off.
Note: When testing direct-sold line items, you should instead use test line items without a revenue impact.
Usage examples
On:
adtest=on
Off:
adtest=off
ad_type (Ad type)
Description
The ad type parameter (ad_type) accepts a constant value that indicates the ad types that should be returned for the request.
When ad_type is set to audio or audio_video, the vpmute parameter must be set to 0.
Usage examples
Allows only audio ads:
ad_type=audio
Allows both skippable and non-skippable video ads:
ad_type=video
Allows both audio and video ads:
ad_type=audio_video
This
audio_videovalue allows both formats to compete, but only one serves. It's intended to be used only for serving video creatives into audio content that supports video ad playback or audio creatives into in-stream video players for content that can be "listenable" in nature, like sports streams, videocasts, news, etc. Read about audio in video content.
Allows only skippable video ads:
ad_type=skippablevideo
Allows only non-skippable video ads:
ad_type=standardvideo
Requirements and recommendations
- If your app has video content, set this parameter to
video,audio_video, or leave it unset. - If you app has audio content only (for example, a radio or speech app), you must set this parameter to
audio. Leaving it unset will cause no audio ads to be returned.
afvsz (Non-linear ad sizes)
Description
The non-linear ad sizes parameter (afvsz) accepts constant values which should be a comma-separated list of non-linear ad sizes that can be displayed in the video ad slot.
These sizes must be any of the those supported:
200x200250x250300x250336x280450x50468x60480x90729x90
When using the IMA SDK, this field is overwritten and populated with all supported sizes that fall within the nonLinearAdSlotWidth and nonLinearAdSlotHeight.
This parameter can be left out or empty when no non-linear sizes are supported.
Usage examples
All sizes are supported:
afvsz=200x200,250x250,300x250,336x280,
450x50,468x60,480x90,728x90
Max width is 250:
afvsz=200x200,250x250
Max height is 60:
afvsz=450x50,468x60
Max width is 100:
//empty; no values supported
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation or transaction type, it is required to serve non-linear video ads when not using the IMA SDK.
allcues (All cues)
Description
The all cues parameter (allcues) accepts variable values which are a comma-separated list of cue points, in milliseconds. For each value, Google Ad Manager returns an ad break.
- The
vid_dandallcuesparameters are used to serve mid-roll ads without content ingestion. - Ad rules are also required to return mid-rolls. If time-based cues are used in your ad rules (for example, "Every N seconds" or "At fixed times"), then those set in the ad rule are used, and the cues passed into
allcuesare ignored. Mid-rolls still require duration, sovid_dmust still be passed.
Usage examples
Cue points at 10 and 20 seconds:
allcues=10000,20000
ciu_szs (Companion sizes)
Description
The companion sizes parameter (ciu_szs) accepts variable values which are a comma-separated list of companion sizes.
Pipe-separated (|) values indicate a multi-size ad slot.
Usage examples
ciu_szs=728x90,300x250
Sizes with a multi-size slot:
ciu_szs=728x90,300x200|300x250
cmsid (Content source ID)
Description
The content source ID parameter (cmsid) and video ID parameter (vid) accept variable values.
In order to target ads to video content, your master video tag needs to include both of these parameters.
- The
cmsidis a unique number for each content source. To locate this in Google Ad Manager, click Video, then Content sources, and then the name of the source. - The
vidis a string or number identifying a particular video. This ID is assigned by the CMS that hosts your content. To locate this in Google Ad Manager, click Video, then Content, and then the specific video content.
Usage examples
cmsid=[value]&vid=[value]
If you are building a tag for video on demand with Dynamic Ad Insertion, you should use the macros that will dynamically insert the correct content source and video ID.
For example: cmsid=%%CMS_ID%%&vid=%%VIDEO_ID%%
Requirements and recommendations
While these parameters not required to serve ads to any specific implementation or transaction type, they are required to use video content targeting.
cust_params (Custom parameters)
Description
The custom parameters parameter (cust_params) accepts variable values which are key-value pairs that allow you to set specific targeting, such as demographics, certain positions on a page, or a particular page or pages.
Usage examples
See examples of how to add key‑value pairs.
excl_cat (Exclusion category)
Description
The exclusion category parameter (excl_cat) accepts variable values and is used to block any line items containing the exclusion label in the ad request. Use the cust_params parameter to set exclusion category and the exclusion labels.
Usage examples
To set exclusion category for two exclusion labels (airline_excl_label and train_excl_label), use a pipe character (|) to separate the labels:
excl_cat=airline_excl_label%7Ctrain_excl_label
Then, apply URL-encoding and use the encoded string in the cust_params:
&cust_params=excl_cat%3Dairline_excl_label%7Ctrain_excl_label
gdpr (GDPR)
Description
The GDPR parameter (gdpr) accepts constant values and is used by publishers who wish to integrate with the IAB TCF v2.0. Direct VAST requests don't automatically read the values, but they're accepted when added to ad tags.
Only 0 and 1 are valid values for this parameter, where 0 means GDPR does not apply and 1 means GDPR applies. If GDPR applies, you must also provide a valid TC string using the gdpr_consent parameter.
You can read more about the values passed to this parameter in the general guidance for implementing the framework, or in the TC string section of the IAB TCF v2.0 specification.
Usage examples
GDPR applies:
gdpr=1
GDPR does not apply:
gdpr=0
gdpr_consent (GDPR Consent)
Description
The GDPR Consent parameter (gdpr_consent) accepts variable values and is used by publishers who wish to integrate with the IAB TCF v2.0. Direct VAST requests don't automatically read the values, but they're accepted when added to ad tags.
You can read more about the values passed to this parameter in the general guidance for implementing the framework, or in the TC string section of the IAB TCF v2.0 specification.
Usage examples
gdpr_consent=GDPR_CONSENT_123
iabexcl (IAB exclusion URL)
Description
The IAB exclusion URL parameter (iabexcl) accepts variable values, which are a comma separated list of categories.
Usage examples
iabexcl=3,14,527 excludes "Commercial Trucks," "Off-Road Vehicles," and "Rugby."
You can download a list of IAB Content Taxonomy categories and their IDs.
idtype (Device type)
Description
The resettable device identifier parameters (rdid, idtype, is_lat) accept variable values. This value is also known as the identifier for advertising (IFA).
With mobile applications using the IMA SDK for Android or iOS, the IMA SDK passes resettable device identifiers for user targeting into your stream requests with the parameters for rdid, idtype, and is_lat.
When IMA SDK is not used or when server-side beaconing (SSB) is used, you must pass these as explicit parameters. Learn more about device identifiers.
Nearly all programmatic video ads require the presence of these values.
LAT signal. Google instead relies on the presence of a non-zero IDFA to indicate that the user has consented to tracking on versions of iOS that support App Tracking Transparency. As such, a valid UserAgent indicating the correct OS version is required.Usage examples
See detailed examples of resettable device identifiers.
Requirements and recommendations
While these parameters are not required to serve ads to any specific implementation, they are required for programmatic monetization in mobile apps, connected TV, audio, and digital out-of-home.
For web implementations, resettable device identifiers are not used.
SDK usage
While the IMA SDK automatically passes this field, publishers pass these parameters manually when using the PAL SDK.
ipd (Inventory partner domain)
Description
The inventory partner domain parameter (ipd) accepts variable values which should be set to the inventorypartnerdomain declarations in the publisher's app-ads.txt (or ads.txt) file.
The inventorypartnerdomain parameter is an IAB specification that helps publishers designate a domain of an inventory sharing partner for purposes of ads.txt/app-ads.txt validation.
IPD declaration is especially important in inventory sharing use cases where the ad inventory in which a request originates from may be owned by another partner (the inventory sharing partner).
Learn more about ads.txt/app-ads.txt and inventory sharing partners.
Usage examples
Theinventorypartnerdomain is in the app-ads.txt file that points to the partner's .txt file that can monetize the inventory. The value in the ipd parameter should match a value in the app-ads.txt file under one of the inventorypartnerdomain items.Requirements and recommendations
This parameter is required for publishers monetizing on inventory that they do not own.
ipe (Impression pinging entity)
Description
The impression pinging entity parameter (ipe) accepts a constant value which is used to indicate impression pings and conversions that originate from the server, not the client.
The impression ping entity is used when a server sends impression pings/beacons from the server.
Usage examples
Server-side beaconing (SSB):
ipe=ssb
is_lat (Limit ad tracking)
Description
The resettable device identifier parameters (rdid, idtype, is_lat) accept variable values. This value is also known as the identifier for advertising (IFA).
With mobile applications using the IMA SDK for Android or iOS, the IMA SDK passes resettable device identifiers for user targeting into your stream requests with the parameters for rdid, idtype, and is_lat.
When IMA SDK is not used or when server-side beaconing (SSB) is used, you must pass these as explicit parameters. Learn more about device identifiers.
Nearly all programmatic video ads require the presence of these values.
LAT signal. Google instead relies on the presence of a non-zero IDFA to indicate that the user has consented to tracking on versions of iOS that support App Tracking Transparency. As such, a valid UserAgent indicating the correct OS version is required.Usage examples
See detailed examples of resettable device identifiers.
Requirements and recommendations
While these parameters are not required to serve ads to any specific implementation, they are required for programmatic monetization in mobile apps, connected TV, audio, and digital out-of-home.
For web implementations, resettable device identifiers are not used.
SDK usage
While the IMA SDK automatically passes this field, publishers pass these parameters manually when using the PAL SDK.
lip (Last position in pod)
Description
The last position in pod parameter (lip) accepts a constant value to indicate a request from the last position in a pod for targeting or reporting.
Note: This parameter does not apply to optimized pods and is ignored if used.
Usage examples
lip=1
ltd (Limited ads)
Description
The limited ads parameter (ltd) accepts a constant value which indicates whether to serve ads in a limited way in the absence of consent for the use of cookies or other local identifiers.
This parameter is used to indicate a limited ads request, and is different from the is_lat parameter. It disables personalization and the use of identifiers for such purposes.
ltd=1 changes the behavior of the IMA SDK to treat the request as ID-less and to disallow storage.Usage examples
ltd=1
max_ad_duration (Maximum ad duration)
Description
The minimum ad duration parameter (min_ad_duration) and maximum ad duration parameter (max_ad_duration) accept variable values that, taken together, specify the duration range an ad must match in milliseconds.
This parameter may be used to restrict creatives to a duration required in ad tag for single ads or in optimized pod requests.
Usage examples
min_ad_duration=15000&max_ad_duration=30000
min_ad_duration (Minimum ad duration)
Description
The minimum ad duration parameter (min_ad_duration) and maximum ad duration parameter (max_ad_duration) accept variable values that, taken together, specify the duration range an ad must match in milliseconds.
This parameter may be used to restrict creatives to a duration required in ad tag for single ads or in optimized pod requests.
Usage examples
min_ad_duration=15000&max_ad_duration=30000
mridx (Mid-roll number)
Description
The mid-roll number parameter (mridx) accepts a variable value which indicates the ordinal number of the mid-roll (for example, mid-roll 1, mid-roll 2, etc.).
Usage examples
mridx=2
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation or transaction type, it is required to target a specific mid-roll, report on the mid-roll, and forecast on the mid-roll.
nofb (No fallback)
Description
The no fallback parameter (nofb) accepts a constant value to indicate that the ad request should not return a playlist of video fallback ads.
Usage examples
Fallback disabled:
nofb=1
Single ad fallback and optimized pod ad buffet may be disabled on a per ad request basis by passing nofb=1.
npa (Non-personalized ad)
Description
The non-personalized ads parameter (npa) accepts a constant value to indicate that the ad request should be treated as non-personalized.
You must either specifically set npa=1 or include simply npa (without a set value) to tag the request as non-personalized. Ad requests either missing this parameter, or set to npa=0, default to personalized ads.
Usage examples
Non-personalized ads:
npa=1
Requirements and recommendations
This parameter is only required if the user disables personalization. Publishers should ensure that they represent the accurate state of the user when they control the state.
ott_placement (Custom formats)
Description
The custom formats parameter (ott_placement) accepts a constant value which indicates a request for a non-in-stream OTT placement.
Placement definitions for the examples below:
- Pause: Out-stream format that appears via an overlay on top of video content when a user pauses content playback.
- Homescreen: Ad that appears on the homescreen of a CTV device or OTT app. This includes masthead, banner, and tile implementations on a homescreen.
- Picture-in-picture: In-stream video ad played in a separate ad video player beside video content. Typically requires squeezing back video content and loading a second video player.
- L-banner: In-stream display ad that involves squeezing back video content and creating an ad around the video. Typically, but not limited to, an L-shaped ad content box.
- Overlay: Any in-stream ad format that appears on top of video content but does not take up the full screen. Can be a display or video ad.
Usage examples
Supported formats and their corresponding avlues:
Pause:
cust_fmt=1
Homescreen:
cust_fmt=2
Picture-in-picture:
cust_fmt=3
L-banner:
cust_fmt=4
Overlay:
cust_fmt=5
Custom/other:
cust_fmt=99
Requirements and recommendations
This parameter is only required for programmatic monetization in web, mobile apps, and connected TV for publishers monetizing non-standard placements on OTT streaming environments.
paln (Programmatic Access Library nonce – legacy)
Description
For integrations that use the Programmatic Access Library (PAL), the video nonce parameter accepts a variable string value.
The nonce is URL safe—you don't need to URL-encode it.
Note: If you previously provided a nonce using the legacy paln parameter, it is strongly recommended to migrate to the givn parameter and stop sending paln. Do not include both parameters.
Usage examples
Read more about the value passed to this parameter in the getting started guides for PAL.
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is recommended for programmatic monetization in web, mobile apps, connected TV, audio, and digital out-of-home.
pmad (Pod maximum ad)
Description
The pod maximum ad parameter (pmad) accepts a variable value which indicates the maximum number of ads in a pod.
This parameter limits the total number of ads in an optimized pod, which is a feature available to publishers with an advanced video package.
This parameter should not be used for VMAP (when ad_rule=1).
Usage examples
pmad=4
pmnd (Pod minimum duration)
Description
The pod minimum duration parameter (pmnd) and pod maximum duration parameter (pmxd) accept variable values which, taken together, specify the duration range that a pod must match, in milliseconds.
These parameters are used to request multiple ads in an optimized pod, which is a feature available to publishers with an advanced video package. When ad rules are used, Google Ad Manager automatically adds this information.
This parameter should not be used for VMAP (when ad_rule=1).
Usage examples
pmnd=0&pmxd=60000
pmxd (Pod maximum duration)
Description
The pod minimum duration parameter (pmnd) and pod maximum duration parameter (pmxd) accept variable values which, taken together, specify the duration range that a pod must match, in milliseconds.
These parameters are used to request multiple ads in an optimized pod, which is a feature available to publishers with an advanced video package. When ad rules are used, Google Ad Manager automatically adds this information.
This parameter should not be used for VMAP (when ad_rule=1).
Usage examples
pmnd=0&pmxd=60000
pmxfwt (Pod max forced watch time)
Description
The pod max forced watch time parameter (pmxfwt) accepts a variable value which specifies the maximum non-skippable duration of a pod in milliseconds.
If you support pods with a mix of non-skippable and skippable video ads, and want to limit the amount of ad time for users, use this parameter to define the maximum non-skippable ad time that a user needs to view.
Note: The max pod duration parameter (pmxd) supersedes this parameter in defining the maximum total duration of the pod (including full duration for skippable ads).
Usage example
pmxfwt=30000
pod (Pod number)
Description
The pod number parameter (pod) accepts a variable value to numerically identify each pod within a video. For example, a value of 1 indicates pod 1, a value of 2 indicates pod 2, and so on.
Usage examples
pod=3
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation or transaction type, it is required to allow the same ad to serve across different pods, and to correctly use competitive exclusions, frequency capping, and related features.
pp (Creative profile)
Description
The creative profile parameter (pp) accepts a variable value which controls the creatives eligible to serve based on the configuration set up in a video and audio creative profile.
Usage examples
pp=creative_profile
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is required to restrict media files for Google Ad Manager hosted creatives with video and audio creative profiles. For redirects or programmatic ads, this is used to ensure that the requirement is available, but does not restrict the media files to those selected in the creative profile.
ppt (Publisher Privacy Treatment)
Description
The Publisher Privacy Treatment parameter (ppt) accepts a constant value which is used to indicate whether to turn off ads personalization for the ad request.
This parameter provides a way to enforce non-personalized ads that may differ from npa=1 and rdp=1. It affects both reservations and programmatic demand.
Learn more about Publisher Privacy Treatment.
Usage examples
Turn off ads personalization:
ppt=1
ppid (Publisher provided identifier)
Description
The publisher provided identifier (ppid) parameter accepts a variable value of the identifier and is used in frequency capping, audience segmentation, targeting, sequential ad rotation, and other audience-based ad delivery controls across devices.
Learn more about publisher provided identifiers.
Usage examples
ppid=12JD92JD8078S8J29SDOAKC0EF230337
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation or transaction type, it is required to use a consistent platform agnostic identifier. It may be used when other identifiers are not present and can be provided to buyers.
ppos (Position in pod)
Description
The position in pod (ppos) parameter accepts a variable value which represents the position within a pod (for example, position 1, position 2, etc.).
This parameter is for standard pods only and is necessary for companion autofill. When ad rules are used, Google Ad Manager automatically adds this information.
Usage examples
ppos=2
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation or transaction type, it is required for standard pods when position targeting is needed, and for forecasting and reporting on standard pods. It's also required to correctly use competitive exclusions, frequency capping, and related features.
ppsj (Publisher provided signals JSON)
Description
The publisher provided signals JSON parameter (ppsj) accepts a variable value which is a base64-encoded JSON object containing audience and contextual data provided by the publisher to improve programmatic monetization.
This parameter can be used to send certain signals to buyers/bidders.
Learn more about publisher provided signals and supported taxonomies.
Usage examples
JSON object:
{
"PublisherProvidedTaxonomySignals": [{
"taxonomy": "IAB_AUDIENCE_1_1",
"values": ["6", "284"]
}]
}
Apply Base64 encoded value:
eyJQdWJsaXNoZXJQcm92aWRlZFRheG9ub215U2l
nbmFscyI6W3sidGF4b25vbXkiOiJJQUJfQVVESUVOQ0V
fMV8xIiwidmFsdWVzIjpbIjEiLCIyODQiXX1dfQ
See details of valid JSON key-value pairs in the
HTML5 IMA SDK sample.
ptpl (Ad break template ID)
Description
The ad break template ID parameter (ptpl) and name parameter (ptpln) accept variable values which are used to indicate which ad break template should apply to the optimized pod request.
Ad break templates allow you to configure which ad spots or custom ad spots, should be included in an ad break, and in which order they should serve.
Only one of these parameters are required to request an ad break template.
Usage examples
Learn more about how to set up and request ad break templates.
Requirements and recommendations
These parameters are only required if you are directly requesting an ad break template.
ptpln (Ad break template name)
Description
The ad break template ID parameter (ptpl) and name parameter (ptpln) accept variable values which are used to indicate which ad break template should apply to the optimized pod request.
Ad break templates allow you to configure which ad spots or custom ad spots, should be included in an ad break, and in which order they should serve.
Only one of these parameters are required to request an ad break template.
Usage examples
Learn more about how to set up and request ad break templates.
Requirements and recommendations
These parameters are only required if you are directly requesting an ad break template.
pubf (Public price floors in Ad Exchange tags)
Description
The public floor for Ad Exchange parameter (pubf) and the private floor for Ad Exchange parameter (pvtf) accept variable values which are used to add price floors to Ad Exchange tags.
These parameters are the equivalent of google_ad_public_floor and google_ad_private_floor.
Usage examples
Public floor:
pubf=123
Private floor:
pvtf=123
Requirements and recommendations
These parameters are only available for publishers in the European Economic Area ("EEA") or Switzerland who have been approved to use the "Price floor" feature.
Learn how to submit a request.
pvid (App set ID)
Description
The app set ID parameter (pvid) accepts a variable value which is set to the Android app set ID, and the app set scope parameter (pvid_s) accepts a constant value that represents the scope of the app set ID (either scope_app or scope_developer).
See the Android documentation on how to retrieve the app set ID.
Usage examples
pvid=[AppSetID_value]
pvid_s=scope_app
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is recommended for programmatic monetization in mobile app in Android devices.
SDK usage
While the IMA/PAL SDK automatically passes this field, publishers with non-SDK implementations must call the app set SDK and pass these parameters manually on ad request.
pvid_s (App set scope)
Description
The app set ID parameter (pvid) accepts a variable value which is set to the Android app set ID, and the app set scope parameter (pvid_s) accepts a constant value that represents the scope of the app set ID (either scope_app or scope_developer).
See the Android documentation on how to retrieve the app set ID.
Usage examples
pvid=[AppSetID_value]
pvid_s=scope_app
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation, it is recommended for programmatic monetization in mobile app in Android devices.
SDK usage
While the IMA/PAL SDK automatically passes this field, publishers with non-SDK implementations must call the app set SDK and pass these parameters manually on ad request.
pvtf (Private price floors in Ad Exchange tags)
Description
The public floor for Ad Exchange parameter (pubf) and the private floor for Ad Exchange parameter (pvtf) accept variable values which are used to add price floors to Ad Exchange tags.
These parameters are the equivalent of google_ad_public_floor and google_ad_private_floor.
Usage examples
Public floor:
pubf=123
Private floor:
pvtf=123
Requirements and recommendations
These parameters are only available for publishers in the European Economic Area ("EEA") or Switzerland who have been approved to use the "Price floor" feature.
Learn how to submit a request.
rdp (Restrict data processing)
Description
The restrict data processing parameter (rdp) accepts a constant value to indicate that the ad request should restrict data processing.
You can restrict data processing at the network level by enabling the Restrict Data Processing network setting.
Usage examples
Restrict data processing:
rdp=1 or rdp (with no set value)
Do not restrict data processing:
rdp=0
schain (Supply chain)
Description
The supply chain (schain) parameter accepts a variable value which should be serialized SupplyChain object. When this parameter is included, Google appends a node to any received schain objects prior to sending to buyers.
See the full IAB documentation for communicating SupplyChain information via a tag (rather than OpenRTB).
See requirements forschain to be parsed correctly
Based on the IAB documentation, the following defines the serialization for the SupplyChain object:
{SupplyChainObject}!{SupplyChainNode array}. SupplyChainObjectandSupplyChainNodeproperties are comma delimited such that optional fields can be omitted and comma separators for which can be optionally excluded.- Each
SupplyChainNodeelement is separated by a "!". - If the value of any property contains characters that require URL encoding (for example "
," or "!"), the value should be URL encoded before serialization.
Serialization order
SupplyChainObject properties are serialized in this order:
ver,complete
SupplyChainNode properties are serialized in this order:
asi,sid,hp,rid,name,domain,ext
ext are exchange specific. Google Ad Manager does not parse this property.Examples of how to serialize the SupplyChain object
Below are two examples of ways to serialize the above SupplyChain object:
1.0,1!exchange1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1,,,,
1.0,1!exchange1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1
Usage examples
schain=1.0,1!exchange1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1,,,,
If the value for asi were exchange,1, then the serialization with escaped characters would look like:
1.0,1!exchange%2C1,12345,1,bid-request-1,publisher1,publisher1.com!google.com,pub-12345678910,1
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation or transaction type, it is required for publishers leveraging payment intermediaries upstream of the request to Google Ad Manager. This includes publishers who use third-party ad server technology.
scor (Stream correlator)
Description
The stream correlator (scor) parameter accepts a variable value which should be an integer generated for each video stream.
The score and correlator parameters do not need to have the same integer value. However, they should retain their respective values throughout each video stream playback to identify a unique viewing session.
Usage examples
scor=17
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation or transaction type, it is recommended for ad serving in web, mobile apps, connected TV, audio, and digital out-of-home.
This parameter is used for competitive exclusions, frequency capping, and related features when a user is watching multiple videos on the same page.
sdk_apis (SDK API framework)
Description
The SDK API framework (sdk_apis) parameter accepts a comma-separated list of constant integer values which indicate all of the API frameworks that the player supports.
Requirements and recommendations
SDK usage
This parameter is used by publishers that use the Programmatic Access Library (PAL). If you attempt to set values to this parameter while using the IMA SDK, the values will be overridden with the values supported by the IMA SDK.
sdmax (Skippable max ad duration)
Description
The skippable max ad duration (sdmax) parameter accepts a variable value that allows publishers to specify their desired max ad duration for the skippable ads.
It takes a duration in milliseconds that represents the upper bound that should be allowed for the duration of skippable video/audio creatives for that particular ad request.
Use sdmax independently for skippable ads, or in combination with the existing max_ad_duration parameter to provide different max durations for skippable and non-skippable ads.
Usage examples
Using the following settings:
max_ad_duration= 15000 (15 seconds)sdmax= 45000 (45 seconds)
For the following creatives:
- Creative A: non-skippable; 30s
- Creative B: skippable; 30s
Results in:
- Creative A will be filtered because it's non-skippable and its duration exceeds the (non-skippable) max.
- Creative B will not be filtered because, while its duration exceeds
max_ad_duration, it's skippable, and its duration does not exceed the skippable max.
ssss (Server-side stitching source)
Description
The server-side stitching source (ssss) parameter accepts a constant value which should be set to a recognized, Google-supplied value for your video stitching technology vendor.
Video stitching technology vendors using server-to-server integrations with Google are given this value from Google and are able to provide it to you. You can reach out to your Google account manager with any questions about the value to set to this parameter.
Usage examples
ssss=mystitcher
Requirements and recommendations
While this this parameter is not required to serve ads to any specific implementation or transaction type, it is required to use server-side implementations.
tfcd (Tag for child-directed)
Description
The treat for child-directed (tfcd) parameter accepts a constant value which indicates that the request should be treated as child directed.
Usage examples
tfcd=1
trt (Traffic type)
Description
The traffic type (trt) parameter accepts a constant value that functions to request either purchased or organic traffic.
Usage examples
Request for purchased traffic:
trt=1
Request for organic traffic:
trt=2
Requirements and recommendations
SDK usage
The IMA SDK does not populate a default value if the traffic type parameter is missing from a request. In these instances, the server supplies a default value of 0 (undefined traffic).
us_privacy (IAB US privacy)
Description
Theus_national string has been deprecated by the IAB in favor of GPP. However, Ad Manager continues to read and respect the string if passed for backwards compatibility. It is recommended that publishers review GPP or other privacy controls and migrate off us_national.
vad_type (Video ad type)
Description
The video ad type (vad_type) parameter accept a constant value which indicates whether a linear or non-linear ad should be returned.
Usage examples
Return a linear ad:
vad_type=linear
Return a non-linear ad:
vad_type=nonlinear
vid (Video ID)
Description
The content source ID parameter (cmsid) and video ID parameter (vid) accept variable values.
In order to target ads to video content, your master video tag needs to include both of these parameters.
- The
cmsidis a unique number for each content source. To locate this in Google Ad Manager, click Video, then Content sources, and then the name of the source. - The
vidis a string or number identifying a particular video. This ID is assigned by the CMS that hosts your content. To locate this in Google Ad Manager, click Video, then Content, and then the specific video content.
Usage examples
cmsid=[value]&vid=[value]
If you are building a tag for video on demand with Dynamic Ad Insertion, you should use the macros that will dynamically insert the correct content source and video ID.
For example: cmsid=%%CMS_ID%%&vid=%%VIDEO_ID%%
Requirements and recommendations
While these parameters not required to serve ads to any specific implementation or transaction type, they are required to use video content targeting.
vpi (Video playlist inline)
Description
The video playlist inline (vpi) parameter accepts a constant value which indicates whether to serve inline VMAP (return VAST inside of VMAP).
This parameter can be used to reduce latency, and guarantee frequency caps and competitive exclusions across a video stream.
Usage examples
Return VAST:
vpi=1
Return redirects:
vpi=0