ORTB
OMID chapter navigation

Open Measurement: OMID & OM SDK

IAB Tech Lab · OMID 1.6
On this page

Why a common measurement interface

Third-party measurement only works if the measurer can obtain objective data contemporaneous with the ad being shown: the geometry of the ad view, obstructions, playback progress and the impression moment. That data can only be observed by the rendering party (the ad SDK, the player or the publisher app), so a measurer cannot collect it directly and has to rely on the renderer to supply it.

Before the Open Measurement Interface Definition (OMID), this capability for video advertising was provided by the Video Player-Ad Interface Definition (VPAID): both measurement code and interaction logic ran inside the ad executable, leaving the player and the ad mutually dependent. VPAID is officially marked deprecated and is being phased out, with OMID taking over verification and the Secure Interactive Media Interface Definition (SIMID) taking over interactivity; the VAST 4 model separates media from executable files accordingly.

OMID's approach is to define an interface: the renderer creates an ad session and dispatches events, the OM Service computes geometry and obstructions and forwards events to verification scripts, and the measurer judges and reports independently on that basis. The interface itself prescribes neither a measurement methodology nor a report format or destination — which is what makes discrepancies between measurers explicable rather than hidden.

For practitioners the interface matters in three ways:

  • Comparable criteriaA session explicitly declares its CreativeType and ImpressionType, giving different measurers a common reference for discrepancies on the same impression.
  • Independent measurementVerification scripts are supplied by measurement vendors and report on their own; the renderer only dispatches events and produces no measurement conclusion.
  • Consistent across platformsOne session and event model covers the JavaScript, iOS and Android implementation lines, with Connected TV (CTV) extended inside the JS implementation.

Three parties and the in-session data flow

  • Integration partner

    Ad SDK / publisher app

    The session client: omid-session-client-v1.js, OM SDK iOS, OM SDK Android

    • Creates the ad session and declares the CreativeType and ImpressionType
    • Registers the verification script resources (VerificationScriptResource) that should receive events for this session
    • Supplies the creative element or its bounds so the OM Service can compute geometry and obstructions
    • Dispatches impression, creative-loaded and media playback events
    • Finishes the session, reporting the error type and description first when something goes wrong
  • OM Service

    OMID JS Service / native SDK service layer

    Hosted in an iframe on the web; other iframes detect its availability through an iframe named omid_v1_present

    • Receives messages from the integration and maintains session state (running, ad/media events registered, creative loaded)
    • Injects verification script resources and carries their communication with the client (same document, cross-domain iframe, invisible WebView or DOM-less environment)
    • Computes ad view geometry, obstructions and the reasons a measurement is not possible
    • Dispatches session events (sessionStart / geometryChange / impression / sessionError / sessionFinish) and media events to verification scripts
  • Verification script

    Measurement vendor

    The verification client: omid-verification-client-v1.js, bundled into the vendor's own script at build time

    • Subscribes to session events via registerSessionObserver and to specific event types via addEventListener
    • In restricted environments uses sendUrl for network requests, injectJavaScriptResource for injection, and the controlled timers instead of native ones
    • Decides and reports its own measurements; OMID defines neither the report format nor its destination
    • Cleans up and performs end-of-session reporting on sessionFinish

Message order within one session

The table below is the message order of one ad session from creation to finish. The steps express order only and do not imply identical calling constraints on every platform; see the session lifecycle & ownership chapter for the full timing constraints.

  1. 1Integration partnerOM ServiceCreate the session context: partner identity, verification script resources, creative element, content URLRepresentative callnew AdSession(context) · AdSession.createAdSession(configuration, context)
  2. 2OM ServiceVerification scriptInject the verification script resources and establish communicationRepresentative callVerificationClient.registerSessionObserver(callback, vendorKey)
  3. 3Integration partnerOM ServiceDeclare the creative type and impression criteriaRepresentative callsetCreativeType(creativeType) · setImpressionType(impressionType)
  4. 4Integration partnerOM ServiceRegister event ownership: who dispatches ad events and media events for this sessionRepresentative callregisterAdEvents() · registerMediaEvents()
  5. 5Integration partnerOM ServiceStart the session (owned by the native SDK in a mobile app environment, where the JS call has no effect)Representative callstart()
  6. 6OM ServiceVerification scriptDispatch sessionStart: carries context and verificationParameters, and is always the first event of a sessionRepresentative callSessionEvent(type: 'sessionStart', data)
  7. 7OM ServiceVerification scriptContinuously dispatch geometryChange: ad view geometry, obstructions and reason codesRepresentative callAdEvent(type: 'geometryChange', data)
  8. 8Integration partnerOM ServiceDeclare creative load completion and that the impression occurredRepresentative callAdEvents.loaded(vastProperties) · AdEvents.impressionOccurred()
  9. 9Integration partnerOM ServiceDispatch media playback events: start and the three quartiles, complete, pause/resume, buffering, skip, volume, player state, user interactionRepresentative callMediaEvents.start(duration, mediaPlayerVolume) … complete()
  10. 10OM ServiceVerification scriptForward the impression and media events to verification scripts subscribed to that event typeRepresentative callVerificationClient.addEventListener(eventType, callback)
  11. 11Integration partnerOM ServiceFinish the session; report unrecoverable errors first — sessionError does not replace sessionFinishRepresentative callerror(errorType, message) → finish()
  12. 12OM ServiceVerification scriptDispatch sessionFinish: the last event of a session, on which verification scripts clean up and perform end-of-session reportingRepresentative callSessionEvent(type: 'sessionFinish')

Carriage points in ad formats

  • Request sideOpenRTB / AdCOM

    The request side declares capability and partner identity: whether the placement supports OMID, whether the creative requires OMID, and which integration drives the session.

    • imp.{banner,video,audio,native}.api with value 7 (OMID-1 in the AdCOM APIFrameworks list): the placement supports OMID
    • bid.apis (bid.api in OpenRTB 2.x) with value 7: the creative requires OMID
    • source.ext.omidpn / source.ext.omidpv: the name and versionString of the OMID Partner object
    • For Native ads, a custom event tracker with event value 555 carries the verification script, together with ext.vendorKey and ext.verification_parameters
    Open chapter
  • Response sideVAST 4.x

    The response side delivers the verification script resources themselves: resource URL, vendor identity and vendor parameters. After VPAID's deprecation, OMID takes over its verification role.

    • The AdVerifications / Verification elements (declared on both InLine and Wrapper in the official 4.0 XSD), with Verification@vendor giving the vendor identity (e.g. company.com-omid)
    • JavaScriptResource@apiFramework="omid" marks an OMID resource; @browserOptional is integrated from 4.1 (not declared in the official 4.0 XSD)
    • VerificationParameters is integrated from 4.1 and carries vendor-specific parameters
    • The macros [VERIFICATIONVENDORS] fill the verification vendor list and [OMIDPARTNER] fills the Partner identity (formatted name/versionString)
    Open chapter

Version history

OM SDK library versions are released per platform. The table below records the OM SDK JS release points, taken from the official repository's CHANGELOG.md.

Scope of this record

  1. Public release of the JS clients (2018)

    OM SDK JS shipped 1.1.0 as its first General Availability release, followed by the client code being published to a GitHub repository; from 1.2.0 browser integration became a supported scenario.

    • OM SDK JS 1.1.0 was released, recorded in the official CHANGELOG as the first General Availability release.
    • The OM SDK JS client code was made available in a public GitHub repository (1.1.3), together with build files, README and CHANGELOG.
    • OM SDK JS 1.2.0: verification scripts in a friendly iframe switched to direct communication instead of postMessage, and the restriction that the impression event must be sent before other events was removed.
  2. Session classification and event naming unified (1.3, 2019)

    1.3 was a significant update: media type became expressed as creative type, the video event type was renamed media, and the session type gained a javascript value. Scripts written for OMID 1.2 keep running, but integrations had to change code.

    • OM SDK 1.3.0 (significant update): the mediaType attribute was replaced by creativeType, the video event type by media, adSessionType gained a javascript value, the loaded event applies to display ad sessions, and error events can carry a media type; sessionStart gained supportsLoadedEvent and contentUrl, loaded gained creativeType / mediaType / impressionType, impression gained creativeType / impressionType, and geometryChange gained pixels / friendlyObstructions / declaredFriendlyObstructions. The official note states that 1.2 scripts keep running while integrations must change code, with the migration guide shipped in the Android and iOS releases.
  3. CTV support (1.4–1.5, 2022–2024)

    1.4 introduced the events and context fields CTV requires; 1.5 landed on specific TV platforms (Samsung Tizen, LG webOS) and shipped a CTV reference app.

    • OM SDK 1.4.0 (significant update): added Connected TV (CTV) support — the Context definitions gained DeviceCategory, a CTV last-activity signal was added (lastActivityTime entered the verification event schema and event-typedefs), noOutputDevice was added to the reason list and factored into viewability, and the unused adId field was removed.
    • OM SDK 1.5.0 (significant update): the OM Web SDK gained LG webOS and Samsung Tizen support, a web CTV reference app was added, appId and deviceInfo plus device volume detection were added for both platforms, and JS-managed sessions were no longer marked as under evaluation.
  4. Access mode consolidation and device attestation (2025 onward)

    The domain access mode was removed, leaving full and limited; from 1.6.0 device attestation was added to address misrepresentation of device information on CTV and mobile.

    • OM SDK JS 1.5.4: the domain access mode was removed. Selecting DOMAIN now falls back to LIMITED, and the constant is retained in constants.js with an @deprecated annotation.
    • OM SDK JS 1.5.5: added UniversalAdId support, added HUMAN to the verification vendors, and removed Moat's URL regex to prevent anyone who takes control of the domain from impersonating Moat.
    • OM SDK 1.6.0 (significant update): added device attestation support for Fire TV and Apple devices, including the Privacy Pass Attestation changes for Fire TV, and shipped modern versions of the session and verification clients. The attest method was added on the verification client side.
    • OM SDK JS 1.6.6: exported the VideoPlayerState, InteractionType, CreativeType, ErrorType and ImpressionType enums to OmidSessionClient, and improved precision handling in compliance and validation event data.
    • OM SDK JS 1.6.10 was released and is the collection baseline for this site's OMID module (commit b6f12bd).· last-verified 2026-09-22
  • Upstream discrepancyThe IAB Tech Lab standards page lists OMID spec versions 1.0 / 1.2 / 1.3 / 1.4 / 1.5 / 1.6 with no 1.1, while the OM SDK JS CHANGELOG.md contains five library releases from 1.1.0 (2018-03-29, the first General Availability release) to 1.1.4. These are two separate sequences — spec versions and library versions — and this site records each against its own source without merging or inferring a mapping.https://iabtechlab.com/standards/open-measurement-sdk/ · vendor/iab-omid-js/CHANGELOG.md
  • Upstream discrepancyThe upstream CHANGELOG.md entry for 1.3.0 contains two spelling defects in the original text: 'signficant update' and 'Atribute adSessionType'. This site reproduces the upstream text as-is rather than correcting it.vendor/iab-omid-js/CHANGELOG.md:342-363(commit b6f12bd)

Current platform status

The OMID specification itself is platform-neutral, with three implementation lines. Library versions and public class counts below come from each platform's official documentation and from the official source code collected by this site.

PlatformImplementationLibrary versionSpec versionsPublic classesOfficial docs
JavaScriptOM SDK JSOmidSessionClient · OmidVerificationClient1.6.10OMID 1.68docs.iabtechlab.com/omsdk-1.6/js/index.html
iOSOM SDK iOSOMIDOMID 1.612docs.iabtechlab.com/omsdk-1.6/ios/index.html
AndroidOM SDK Androidcom.iab.omid.library · com.iab.omid.library.adsession · com.iab.omid.library.adsession.mediaOMID 1.610docs.iabtechlab.com/omsdk-1.6/android/index.html

Core terms

Frequent terms in this domain. Field-level entries (kind = field) are marked in monospace.

  • OMIDOpen Measurement Interface Definition

    The API made available to verification code by OM SDK or an equivalent service. In the VAST 4 model of separated media and executable files, OMID replaces VPAID for verification, while SIMID takes over interactivity.

  • OM SDKOpen Measurement SDK

    An IAB-led project developing a common library to collect and expose measurements of ad creatives, including video, at view time, for verification purposes. OMID is the interface definition it exposes; OM SDK is its implementation, across the JavaScript, iOS and Android lines.

  • OM Service

    The intermediary between the session client and verification scripts: it receives session and media events dispatched by the integration, forwards events to verification scripts and computes geometry data. On the web it is hosted in an iframe, and other iframes detect OMID availability through an iframe named omid_v1_present (omid_v1_present_app in-app, omid_v1_present_web on web). Since 1.5.6 the official guidance is not to use display:none on that iframe.

  • Ad Session

    The unit of measurement in OMID. An integration creates a session, declares the creative type and impression criteria, registers the verification scripts that should receive events, and runs it from start to finish; during the session the OM Service dispatches sessionStart / geometryChange / impression / media events to those scripts.

  • Integration Partner

    The integrating party — ad SDKs and publisher apps — responsible for creating and driving the ad session. The session client is what an integration partner bundles into the ad HTML or native app at build time.

  • Verification Script

    Executable code supplied by a measurement vendor, delivered through an ad format's verification resource element, which subscribes to session events and reports its own measurements. Scripts bundle the verification client source at build time; they may run in the same document as the creative, in a cross-domain iframe, in an invisible WebView, or in a DOM-less JavaScript execution environment for native ads.

  • Verification Vendor

    A measurement provider that supplies verification scripts. OM SDK JS ships a list of known vendor IDs (VerificationVendorId: OTHER 1, MOAT 2, DOUBLEVERIFY 3, INTEGRAL_AD_SCIENCE 4, PIXELATE 5, NIELSEN 6, COMSCORE 7, MEETRICS 8, GOOGLE 9, HUMAN 10, MOBIAN 11) matched by script URL regex; MOAT is intentionally excluded from the URL matching map, with the upstream comment stating that they no longer operate and the namespace should not become usable by another party who acquires Moat's old domains.

  • Session Client

    The OMID client used by the integration, shipped as omid-session-client-v1.js (UMD) and working both at the top level of a webview and in a cross-domain iframe. It exports AdSession, AdEvents, MediaEvents, Context, Partner, VerificationScriptResource, UniversalAdId, VastProperties and OmidVersion.

  • Verification Client

    The OMID client used by a measurement vendor's verification script, shipped as omid-verification-client-v1.js (UMD). It provides registerSessionObserver, addEventListener, sendUrl, injectJavaScriptResource, controlled timers and attest (since 1.6.0).

  • Access Mode

    Determines whether a verification script receives a reference to the creative element. full means verification code has access to the creative element and OM SDK supplies a video / slotElement reference in the context; limited supplies geometry data only. The domain mode was removed in 1.5.4 and falls back to limited when selected.

  • Impression Type

    Declares under which condition a session counts its OMID impression: definedByJavaScript / unspecified / loaded / beginToRender / onePixel / viewable / audible / other. Declaring the criteria makes impression discrepancies between measurers easier to understand; when unset the default is unspecified (the OMID 1.2 default).

  • Creative Type

    The type of creative measured in the session: definedByJavaScript / htmlDisplay / nativeDisplay / video / audio. It also constrains the form a verification script may take — under htmlDisplay scripts can wrap the creative or be delivered as resources, while the other values allow resources only; audio provides no visibility data at all. Replaced the former mediaType attribute in 1.3.

  • Geometry Change

    The geometryChange event fires whenever the ad container state changes such that any field of the viewport or ad view would differ from the previous report, and carries the full geometry of the registered ad view including obstructions and any detected reason codes. Sizes and positions in the event data are in independent pixels, with coordinates relative to screen coordinates.

  • Obstruction

    Another view or element covering the ad view and affecting the viewability calculation. The geometryChange event reports obstructionClass and obstructionPurpose per obstruction, and the Reason enum explains why measurement is not possible (notFound / hidden / backgrounded / pictureInPicture / deviceLocked / viewport / obstructed / clipped / unmeasurable / noWindowFocus / noOutputDevice).

  • Friendly Obstruction

    A view the integration declares to be part of the ad experience and therefore not to be counted as an obstruction (such as its own playback controls). Since 1.3 the geometryChange event carries friendlyObstructions and declaredFriendlyObstructions; the registration API exists only on the native side (on iOS, methods such as removeAllFriendlyObstructions on OMIDAdSession plus the OMIDFriendlyObstructionType enum).

  • Partner

    The session partner object: its name and versionString declare which integration (ad SDK) drives the session. The same pair travels as source.ext.omidpn and source.ext.omidpv on the OpenRTB side and is filled by the [OMIDPARTNER] macro (formatted as name/versionString) on the VAST side.

  • Device Attestation

    Privacy-preserving attestations issued by device manufacturers that let buyers independently verify they are buying genuine CTV and mobile inventory, addressing device spoofing. Supported from OM SDK 1.6.0 on Fire TV and Apple devices and reached from the verification client via the attest method. The official implementation guidance self-describes as In Progress.

  • CTVConnected TV

    Connected TV: a scenario OMID supports from 1.4, extended inside the JS implementation. 1.4 added DeviceCategory and a last-activity signal, 1.5 landed on Samsung Tizen and LG webOS with a CTV reference app, and 1.6 added device attestation for Fire TV and Apple devices.

  • VPAIDVideo Player-Ad Interface Definition

    The legacy standard specifying the protocol between the ad and the media player, used for ad interactivity and other advanced video functionality. Officially marked deprecated and being phased out, with OMID taking over verification and SIMID taking over interactivity.

  • libraryVersion

    The version number of a platform's OM SDK implementation (e.g. OM SDK JS 1.6.10). It is a separate sequence from the spec version (OMID 1.0 / 1.2 / 1.3 / 1.4 / 1.5 / 1.6): each of the three platforms ships its own library versions, the JS library carries more revisions than the spec, and equal numbers do not imply equal dates. IAB Tech Lab's compliance certification records libraryVersion and partnerVersion separately per platform.

Suggested reading path

Six steps through the backbone of this domain, in the order model, then API, then carriage.

  1. 1Session model: the three parties, session lifecycle and ownership
  2. 2AdSession and session construction: the integration side of the API
  3. 3AdEvents and MediaEvents: the event set and its mapping onto VAST tracking events
  4. 4VerificationClient: the measurement vendor side of the API
  5. 5OpenRTB / AdCOM carriage: how the request side declares OMID capability and partner identity
  6. 6VAST carriage: how the response side delivers verification script resources

Sources & baseline

OM SDK JS 1.6.10 (commit b6f12bd, fetched 2026-09-22) · public APIs of all three platforms from docs.iabtechlab.com/omsdk-1.6 · license Apache 2.0

IAB Tech Lab OM SDK standards page

25 chapters · scripts/gen-omid-spec.mjs

Spec data (interface methods, enumeration values, release history) is taken from official IAB Tech Lab sources and kept in the original English; site-written prose is bilingual. See data/omid-spec/PROVENANCE.json for provenance.