OMID Explained: How IAB's Open Measurement SDK Works with VAST AdVerifications

You've probably seen apiFramework="omid" inside a VAST tag and wondered what it actually does. This is the practical explanation — what OMID is, how it fits into VAST 4.1+, what each field means, and what breaks when you get it wrong.

What is OMID?

OMID (Open Measurement Interface Definition) is the API layer inside the IAB Tech Lab Open Measurement SDK (OM SDK). It defines a standardised way for third-party measurement vendors — DoubleVerify, IAS, Moat, etc. — to collect viewability, audio, and fraud signals from any video or audio player, whether that's a web browser, a mobile app, or a CTV device.

The key distinction: OMID is the protocol. OM SDK is the implementation (native libraries for iOS, Android, and web). In practice, most people use the terms interchangeably.

Why it replaced VPAID for measurement

Before OMID, the common approach to third-party measurement was to piggyback a verification script inside a VPAID unit. VPAID gave that script full access to the player's JavaScript context and DOM — which meant it could read page data, fire arbitrary pixels, redirect users, and slow down load times. The IAB's own audit found VPAID ranked among the primary vectors for ad fraud.

OMID draws a hard boundary. Measurement scripts load into an isolated context and communicate through a standardised API. The player reports media events and geometry data to the OM SDK; the SDK forwards them to vendor scripts via the OMID API. No DOM access, no shared JS context, no ability to do anything outside the defined event model.

It also runs on CTV and SSAI environments where VPAID simply can't execute. That's the main reason the industry migrated.

How it fits into VAST

VAST describes the ad: media files, tracking URLs, companion ads. OMID describes who measures the ad and how.

Starting with VAST 4.1, the <AdVerifications> element carries one or more <Verification> entries, each pointing to a vendor's OMID-compatible script. Players that support OM SDK parse this automatically and begin reporting signals once the ad enters the viewport. Players that don't support it skip the element gracefully — OMID degrades without breaking playback.

The XML structure

Here's a complete example with two vendors:

<AdVerifications>
  <Verification vendor="doubleverify.com-omid">
    <JavaScriptResource apiFramework="omid" browserOptional="true">
      <![CDATA[https://cdn.doubleverify.com/dvtp_src.js]]>
    </JavaScriptResource>
    <VerificationParameters>
      <![CDATA[ctx=12345678&cmp=DV123456]]>
    </VerificationParameters>
    <TrackingEvents>
      <Tracking event="verificationNotExecuted">
        <![CDATA[https://cdn.doubleverify.com/not_executed.js?ctx=12345678&reason=[REASON]]]>
      </Tracking>
    </TrackingEvents>
  </Verification>

  <Verification vendor="ias.com-omid">
    <JavaScriptResource apiFramework="omid" browserOptional="false">
      <![CDATA[https://pixel.adsafeprotected.com/jload]]>
    </JavaScriptResource>
    <VerificationParameters>
      <![CDATA[anId=12345&advId=67890]]>
    </VerificationParameters>
    <TrackingEvents>
      <Tracking event="verificationNotExecuted">
        <![CDATA[https://pixel.adsafeprotected.com/jload?not_executed=1&reason=[REASON]]]>
      </Tracking>
    </TrackingEvents>
  </Verification>
</AdVerifications>

Breaking down each field

vendor (required)
Identifies the measurement vendor. Must follow the domain-omid format — e.g. doubleverify.com-omid, ias.com-omid. This is how players deduplicate vendors across wrapper chains and how the OM SDK routes signals to the right script.

<JavaScriptResource apiFramework="omid">
The URL to the vendor's OMID-compatible measurement script. apiFramework must be lowercase omid. Some players treat this attribute as case-sensitive, so OMID or Omid may be silently ignored.

browserOptional
When true, native iOS and Android players can skip loading the JS file and use the vendor's native SDK integration instead. When false (the default), the script is required even in app contexts — and if the player can't execute it, it should fire verificationNotExecuted.

<VerificationParameters>
A CDATA block with vendor-specific initialisation params — typically placement ID, publisher ID, campaign ID. The format is vendor-defined; VAST doesn't prescribe it. If this element is present but empty, it's usually a configuration mistake.

<TrackingEvents> / verificationNotExecuted
The [REASON] macro is replaced by a numeric code when measurement fails:

Code	Meaning
1	API not supported
2	JavaScript resource not executed
3	Verification not supported for this media type
4	Player/SDK does not support OM SDK

This event is how vendors know measurement failed rather than just inferring it from missing signals. Missing it means you have no visibility into non-executing scripts.

VAST version support

Version	Support	Notes
VAST 2.0, 3.0	None (native)	Some players accept AdVerifications inside an <Extensions> block — non-standard and not reliable
VAST 4.0	Partial	AdVerifications exists but placement differs from 4.1+
VAST 4.1	Full	Canonical placement; the version most OM SDK integrations target
VAST 4.2, 4.3	Full	Inherited from 4.1 without structural changes

If you're serving tags to CTV or app inventory, target VAST 4.1+. Anything below that and you're relying on non-standard extension handling.

OMID in wrapper chains

<AdVerifications> can appear in both <InLine> and <Wrapper> documents. When a wrapper chain is involved:

• The player accumulates <Verification> entries from every hop in the chain — outermost wrapper down to InLine.
• Duplicate vendor values (same vendor attribute at multiple hops) should be deduplicated by the player. Only one instance per vendor should run. "Should" — behaviour varies.
• If you're debugging a live chain, a hop-by-hop inspector will show you exactly which vendors are introduced at which level.

OMID vs VPAID for measurement — side by side

	VPAID	OMID
Security model	Script runs in shared player JS context	Script runs in isolated context via OM SDK API
DOM access	Full access to publisher DOM	None
CTV / native players	Not supported	Supported via native OM SDK libraries
SSAI environments	Not possible	Supported
Multiple vendors	Each vendor wraps the whole ad	Multiple <Verification> elements in one tag
Failed measurement signal	No standard mechanism	verificationNotExecuted tracking event
Fraud risk	High	Low — constrained to OMID event model
Status	Deprecated	Current standard (v1.5)

Common mistakes

These are the issues that actually show up in production tags:

apiFramework="OMID" (uppercase)
Case-sensitive players fail to recognise the vendor. Always lowercase: omid.

HTTP script URL
Mixed-content block in modern browsers. The script never loads. Use HTTPS.

Missing vendor attribute
Players can't deduplicate vendors or route scripts correctly. Always include it.

vendor not in domain-omid format
Values like "DoubleVerify" or "DV" are non-standard. Strict OM SDK implementations may silently ignore them.

Missing verificationNotExecuted tracking URL
The vendor has no signal when measurement fails. Discrepancies go undetected.

Duplicate vendor at multiple wrapper hops
Some players run both instances and double-count. Use your inspector to catch this before it hits production.

AdVerifications in VAST 2.0 / 3.0 without an Extensions wrapper
Structurally invalid — most players ignore the block entirely.

Validation

If you want to catch these issues before a tag goes live, paste it into VASTlint. It checks vendor format, apiFramework casing, HTTPS enforcement, empty VerificationParameters, and duplicate vendor detection. It won't execute the script or validate the runtime OM SDK session — that requires a live player — but it catches the structural mistakes that account for most OMID failures.

---

The IAB Tech Lab OM SDK docs are the authoritative reference if you need the full protocol details: iabtechlab.com/standards/open-measurement-sdk. The OMID API v1.5 spec is worth reading if you're integrating on the player or vendor side.