Open Measurement SDK (OM SDK): Unified Viewability

Before the Open Measurement SDK, viewability measurement in mobile apps was a fragmented mess. Each verification vendor—Moat, DoubleVerify, IAS, and others—required its own proprietary SDK to be integrated into the publisher's app. This meant app developers had to embed multiple vendor SDKs, each with different APIs, performance characteristics, and integration requirements. The IAB Tech Lab's Open Measurement SDK (OM SDK) was created to solve this problem by providing a single, standardized integration that works with all verification vendors.

What Is OM SDK?

The Open Measurement SDK is a lightweight, open-source library developed under the IAB Tech Lab's Open Measurement initiative. It provides a standardized interface between the app publisher (who integrates the SDK) and verification providers (who receive measurement data through it). Instead of integrating five different vendor SDKs, a publisher integrates the OM SDK once, and all participating verification providers can measure viewability and other metrics through it.

The Core Problem It Solves

In the pre-OM SDK era, a publisher working with three verification vendors needed to:

• Integrate three separate SDKs, each adding to app binary size
• Maintain three separate update cycles and compatibility matrices
• Accept three different performance profiles, each potentially impacting app rendering
• Manage three sets of credentials and configuration
• Resolve conflicts between SDKs that competed for the same system resources

With OM SDK, the publisher integrates a single SDK, and all verification vendors communicate through its standardized event system.

IAB Open Measurement Initiative

The Open Measurement initiative was launched by the IAB Tech Lab in 2017 with support from major players across the advertising ecosystem, including Google, Meta, Twitter, Snap, and major verification vendors. The initiative encompasses two main deliverables:

1. Open Measurement Interface Definition (OMID): The specification that defines the measurement interface and data model.
2. Open Measurement SDK (OM SDK): The reference implementation of OMID for native mobile apps.

For web environments, the equivalent functionality is provided through OMID's JavaScript service, which is integrated into VAST 4.x tags rather than requiring a separate SDK integration.

SDK Architecture

Three-Layer Model

The OM SDK architecture follows a clean three-layer model:

Ad Sessions

The fundamental unit of measurement in OM SDK is the ad session. Each ad impression corresponds to one ad session, which tracks the lifecycle of the ad from creation through completion. The publisher creates an ad session before the ad renders and destroys it after the ad is removed from the screen.

// Android (Kotlin) - Creating an OM SDK ad session
import com.iab.omid.library.*;

// Initialize the OM SDK (once at app startup)
Omid.init(context, "com.example.app", omidScriptUrl, partnerName)

// Create an ad session for each ad impression
val adSessionContext = AdSessionContext(
    partner = partner,
    customReferenceIdentifier = "campaign-123",
    contentUrl = "https://publisher.com/article",
    omidJsScriptContent = null
)

val adSessionConfiguration = AdSessionConfiguration(
    impressionType = ImpressionType.ONE_PIXEL,
    creativeType = CreativeType.VIDEO,
    impressionOwner = ImpressionOwner.NATIVE,
    isolateVerificationScripts = true
)

val adSession = AdSession(adSessionConfiguration, adSessionContext)
adSession.registerAdView(adContainerView)
adSession.start()

Event Types

OM SDK defines a rich set of events that the publisher sends to the SDK throughout the ad lifecycle:

Display Ad Events

• loaded: The ad creative has been loaded and is ready to render
• impressionOccurred: The ad has met viewability criteria (typically 1 pixel for 1 second)
• adUserInteraction: The user has interacted with the ad (tap, click)

Video Ad Events

• loaded: The video creative has loaded
• start: Video playback has started
• firstQuartile, midpoint, thirdQuartile: Playback progress events
• complete: Video has played to completion
• pause, resume: Playback state changes
• volumeChange: Audio volume has changed
• skipped: User skipped the video ad
• bufferStart, bufferFinish: Buffering state changes

Viewability Standards

OM SDK supports the IAB's standard viewability definitions while allowing verification vendors to apply their own proprietary criteria:

Display Viewability (IAB Standard)

• Pixel requirement: At least 50% of the ad's pixels are visible on screen
• Time requirement: The pixel requirement is continuously met for at least 1 second

Video Viewability (IAB Standard)

• Pixel requirement: At least 50% of the ad's pixels are visible on screen
• Time requirement: The pixel requirement is continuously met for at least 2 consecutive seconds
• Audio requirement: The ad must be audible (volume greater than zero)

Custom Viewability Definitions

Verification vendors can define custom viewability criteria through the OM SDK. For example, some advertisers require 100% pixel visibility for 5 seconds before counting a viewable impression. The verification script receives raw visibility data from the SDK and applies its own logic to determine viewability.

Integration Guide for Publishers

Step 1: Add the OM SDK Dependency

// Android (build.gradle)
dependencies {
    implementation 'com.iab.omid:omid-library:1.7.0'
}

// iOS (Podfile)
pod 'OMSDK', '~> 1.7.0'

Step 2: Initialize at App Startup

The OM SDK must be initialized once during the app's lifecycle, typically in the Application.onCreate() method (Android) or AppDelegate.didFinishLaunching (iOS). Initialization requires the publisher's partner name and the URL of the OMID JavaScript service provided by the verification vendor.

Step 3: Create Ad Sessions

For every ad impression, create a new ad session before the ad renders. Register the ad view (the container holding the ad creative) with the session, and start the session when the ad becomes eligible for viewability measurement.

Step 4: Send Ad Events

As the ad progresses through its lifecycle, send the appropriate events to the ad session. For video ads, this means firing start, quartile, and complete events at the correct moments. For display ads, the SDK primarily relies on the loaded event and automatic viewability detection.

Step 5: End and Destroy Sessions

When the ad is removed from the screen (either through user action, ad rotation, or screen transition), call finish() on the ad session and release resources.

Supported Platforms

OMID Event Data

Verification scripts receive structured event data from the OM SDK, including:

• Geometry data: The position, size, and viewport-relative coordinates of the ad container on each frame.
• Obstruction data: Information about any overlapping views that partially obscure the ad.
• Viewport data: The dimensions of the visible viewport area.
• Device orientation: Current screen orientation for mobile devices.
• Audio state: Volume level and mute status for video ads.
• App state: Whether the app is in the foreground, background, or inactive.

This rich data set enables verification vendors to compute viewability metrics with high precision, accounting for real-world scenarios like partially scrolled-off ads, ads behind system overlays, and ads in backgrounded apps.

Adoption and Industry Support

OM SDK has achieved broad industry adoption since its launch:

• Major mobile SDKs: Google AdMob, Meta Audience Network, Unity Ads, AppLovin, ironSource, and others have integrated OM SDK support natively.
• Verification vendors: Moat (Oracle), DoubleVerify, IAS, Comscore, and others provide OMID-compatible verification scripts.
• SSPs and exchanges: Many supply-side platforms pass OM SDK availability as a signal in OpenRTB bid requests, allowing buyers to filter for measured inventory.
• Advertisers: Major advertisers increasingly require OM SDK measurement as a condition of media buys, particularly for mobile video campaigns.

OpenRTB Integration

In OpenRTB bid requests, OM SDK support is signaled through the source.ext.om field (set to 1 when OM SDK is active) and the impservice object, which can specify the OMID partner and verification script details. This allows DSPs to know before bidding whether viewability measurement will be available for the impression.

Challenges and Limitations

• Publisher integration burden: While OM SDK reduces the number of vendor SDKs, publishers still need to integrate and maintain the OM SDK itself, which requires engineering resources.
• Cross-platform consistency: Slight differences between the Android, iOS, and web implementations can lead to minor discrepancies in measurement across platforms.
• Vendor support variance: Not all verification vendors support all OM SDK features equally. Some advanced measurements (like brand safety) may require vendor-specific extensions.
• CTV fragmentation: Connected TV environments have diverse technical capabilities, and OM SDK support is not yet universal across all CTV platforms.

Despite these challenges, OM SDK represents a significant improvement over the pre-standardization era and continues to evolve with new features and platform support in each release.