OMID chapter navigation
VAST carriage
carriageThe listings on this page are generated by scripts/gen-omid-spec.mjs from official IAB Tech Lab sources, with descriptions in the original English; see the page footer for the collection baseline.
On this page
Role & scope
Response side: verification scripts of the Open Measurement Interface Definition (OMID) are carried by VAST's AdVerifications / Verification elements (declared on both InLine and Wrapper in the official 4.0 XSD), JavaScriptResource marks an OMID resource with apiFramework="omid", and the browserOptional attribute plus the VerificationParameters element are integrated from 4.1; the macros [VERIFICATIONVENDORS] and [OMIDPARTNER] fill in the verification vendor list and the Partner identity (name/versionString) respectively. The Video Player-Ad Interface Definition (VPAID) is deprecated as of VAST 4.1 and its measurement role is taken over by OMID.
- Format
- VAST 4.x
- Element / attribute
- AdVerifications / Verification
- Since
- 4.0 (browserOptional and VerificationParameters from 4.1)
- Related macros
- 4
AdVerifications elements & attributes
| Element / attribute | Since | Meaning |
|---|---|---|
| VAST > Ad > {InLine | Wrapper} > AdVerifications | 4.0 | The official 4.0 XSD declares this element on both InLine and Wrapper; before 4.1 the practice was to carry it in an Extensions node of type AdVerifications. An extension-era AdVerifications shape also exists from 3.0, which this site treats as a tolerated form.ENAdded in VAST 4 so that executable code for measurement could be delivered separately from the MediaFile. |
| AdVerifications > Verification | 4.0 | Each Verification element represents one verification vendor's resource; the vendor attribute gives the vendor identity, and the element is repeatable.ENvendor attribute example in the official XSD documentation: "For example, 'company.com-omid'". |
| Verification > JavaScriptResource | 4.0 | apiFramework="omid" marks the resource as an OMID verification script; the element text is the script URI.ENapiFramework attribute; example value in official samples: apiFramework="omid". |
| JavaScriptResource@browserOptional | 4.1 | Declares that the script can run without a browser environment — native ads and DOM-less JavaScript execution environments rely on it. The official 4.0 XSD does not declare this attribute, so this site records it as integrated from 4.1.ENNot declared in the official 4.0 XSD; integrated from 4.1 (OMID integration). |
| Verification > VerificationParameters | 4.1 | Carries vendor-specific parameters, corresponding to the verificationParameters of an OMID VerificationScriptResource and playing the same role as ext.verification_parameters on the Native side.ENNot declared in the official 4.0 XSD; integrated from 4.1. |
| Verification > ExecutableResource | 4.1 | Carries VPAID-style executable resources; fades out with VPAID's deprecation, and OMID scenarios should use JavaScriptResource.ENIntegrated from 4.1 (Verification_type in the 4.1 XSD); fades out with VPAID deprecation. |
Related macros
| Name | Type | Since | Support | Meaning |
|---|---|---|---|---|
| [EXTENSIONS]#30 · VAST request URIs | Array<string> | 4.1 | Optional | Before 4.1 this is how a player declared support for the AdVerifications extension.Example: AdVerifications,extensionA,extensionBENList of VAST Extensions type attribute values that the player / client supports. Can be used to indicate support for the OMID AdVerifications extension, proprietary extensions, or future standardized extensions. |
| [VERIFICATIONVENDORS]#31 · VAST request URIs | Array<string> | 4.1 | Optional | The player declares which verification vendors it supports, using the same namespace as Verification@vendor (all three vendors in the official example end in -omid).Example: moat.com-omid,ias.com-omid,doubleverify.com-omidENList of VAST Verification vendor attribute values that the player / client supports. |
| [OMIDPARTNER]#32 · All tracking pixels, VAST request URIsFormat: {partner name}/{partner version} | string | 4.1 | Required (if OM is supported) | Required when OM is supported. It is the VAST-side combination of the OpenRTB omidpn / omidpv pair, separated by a slash; the official text explicitly requires the value unknown when the partner name is unavailable, rather than omitting it.Example: Unencoded: MyIntegrationPartner/7.1 · Encoded: MyIntegrationPartner%2F7.1ENAn identifier of the OM SDK integration. This is the same as the "name" and "versionString" parameters of the OMID Partner object. This will allow creative providers to determine if the OM partner integration is acceptable. Note - This value is essential for communicating the certification status of the OMID integration. If partner ID is not shared, verification vendors will not be able to properly measure and report on this inventory. If partner name is not available, use "unknown". |
| [REASON]#47 · verificationNotExecuted tracking pixels | integer | 4.1 | Required | The reason code for not executing verification, used on verificationNotExecuted tracking pixels; it is not the same value set as OMID's internal Reason enum for unmeasurability, and the two must not be conflated.ENReason code for not executing verification. |
Migration after VPAID deprecation
One of VAST 4's goals is to eliminate delivering executable code (usually VPAID) through the MediaFile node: AdVerifications and InteractiveCreativeFile were added so that measurement and interactivity executables can be delivered separately from the MediaFile. VPAID's verification/measurement role is replaced by OMID and its interactivity role by SIMID. From VAST 4.1 the apiFramework attribute on MediaFile, which enables VPAID delivery, is also deprecated.
For VAST tag creators (direct and wrapped tags)
- 1When OMID support is indicated in the request, include the AdVerifications node (or an Extensions node of type AdVerifications pre-4.1) to carry the verification scripts.
- 2When VPAID support is indicated and the tag creator requires VPAID (for interactivity or ad blocking), include both the AdVerifications node and a VPAID-type MediaFile node.
- 3When OMID/VPAID support status is unknown and the buyer has no hard VPAID requirement, the tag should contain all three: the AdVerifications node, a VPAID-type MediaFile node, and one or more non-VPAID video creative MediaFile nodes, so the publisher has every resource available.
- 4Capability information should be derived from the ad request (OpenRTB and VAST request macros), using the [APIFRAMEWORKS] macro as officially specified.
Execution order for publishers
- 1If OMID is supported, run the AdVerifications node (for Open Measurement) and the video creative MediaFile.
- 2If OMID is not supported but VPAID is, and a VPAID MediaFile node is available in the tag, run VPAID.
- 3If both OMID and VPAID are supported, run both the AdVerifications node and VPAID.
- 4If neither OMID nor VPAID is supported, run one of the non-VPAID MediaFile nodes.
The official text states the order above is only a recommendation and might not work in all cases; publishers may decide which MediaFile to run. It also makes publishers and technology vendors responsible for testing the combinations so that issues like double counting or namespace clashes are handled correctly.
VAST compliance explicitly excludes Open Measurement: the official compliance section states that the Open Measurement, VPAID and VMAP specs are excluded from VAST compliance because they are independent of each other and of VAST; compliance with one does not imply compliance with the others, and each must be declared separately.