Video & Mobile Ad Delivery Standards.
The execution layer for video, CTV, and mobile advertising: VAST, SSAI, SIMID, MRAID, OM SDK, device attestation — and the identifier and attribution frameworks that bound what any of it can prove.
This is a deep dive inside the six-layer standards system, not a seventh pillar. The transaction rails make impressions tradable and the trust layer keeps measurement honest — this page covers the gap between them: video and mobile standards are where workflow ambition meets execution reality. An agent may plan the buy in seconds; the ad still has to render in a player, run inside an app, pass measurement, respect platform rules, and survive verification.
The agent may plan the buy, but the ad still has to render, measure, verify, and comply.
Fast read
- What it is
- A deep-dive guide to the standards that actually deliver video, CTV, and mobile ads — and to the measurement and identifier frameworks that decide whether that delivery can be trusted.
- What it covers
- VAST 4.3 and the CTV Addendum 2024, SSAI, SIMID, VPAID’s deprecation, MRAID 3.0, OM SDK and OMID, device attestation, IDFA and ATT, SKAdNetwork, AdAttributionKit, and the Android identifier set.
- What it is not
- Not a seventh standards pillar — a deep dive inside the six-layer system. Not a claim that any SDK, identifier, or framework solves measurement, attribution, or fraud on its own.
- Why it matters
- Agentic buying can plan a video or mobile campaign in seconds. Whether the ad renders in a player, runs inside an app, and survives verification depends on this layer.
- Best for
- AdTech, MarTech, media, mobile, CTV, agency, publisher, and brand leaders building or evaluating video and mobile execution in agentic workflows.
- Best next read
- Core AdTech Standards, Measurement & Media Quality, and the Mobile App Growth playbook.
Where this layer fits.
The six-layer standards system already covers the transaction rails (Core AdTech), the permission rules (Privacy & Consent), and the trust layer (Measurement & Media Quality). Video and mobile delivery cuts across all three: it consumes VAST from the transaction layer, obeys identifier rules from the platform layer, and feeds the measurement rail that verification depends on. This page is the close-up of that intersection — the standards an execution path actually touches between a plan and a verified impression.
Why this layer exists.
Every standard on this page exists because a plan that is correct in the bidstream can still fail on the device. Six realities created this layer.
- 01
A plan is not a render
Workflow protocols can assemble a video buy in seconds. The ad still has to arrive as a VAST tag that a specific player, on a specific device, actually parses and plays.
- 02
Players are not browsers
Video players and CTV environments are constrained runtimes. Executable creative that assumed browser freedoms is why VPAID is deprecated — and why its successors split interactivity from measurement.
- 03
Apps are not the web
In-app rich media needs its own contract between the ad and the host app. That contract is MRAID — a delivery-layer API, not a measurement solution.
- 04
Server-side changes the picture
SSAI stitches ads into the content stream on the server. That can improve playback — and it moves the ad away from the client signals verification was built on.
- 05
Measurement needs a common rail
Before OM SDK, every verification vendor needed its own integration in every app and player. A standard data rail is the precondition for independent verification at scale.
- 06
Identifiers are not delivery
IDFA, AAID, and their attribution frameworks are platform-governed, permission-gated, and resettable. They constrain what delivery can prove — they are not delivery standards themselves.
Video delivery standards.
Three names carry most of the weight: VAST serves the ad, SIMID makes it interactive, and VPAID is the cautionary tale the other two were designed to retire.
- The serving template
VAST 4.3 + CTV Addendum 2024
VAST is the XML schema that carries video ad media, tracking events, and metadata from ad servers to players. The current version is 4.3 (released December 2022), with CTV-focused changes. The VAST CTV Addendum 2024 (final, July 2024) then retrofits CTV-critical features into all VAST versions via backward-compatible extensions rather than a new version: UniversalAdId recognition back into VAST 2.0–3.x, ACIF support, Open Measurement, DSA ad-transparency icons, interactive video, and high-resolution creative. The watch-outs: the addendum is not “VAST 4.4,” tag generators and players both need updates to use it, and parser support varies — validate what each supply path actually implements.
- The interactive layer
SIMID 1.2
The Secure Interactive Media Interface Definition is the official successor for video interactivity: IAB Tech Lab’s Digital Video working group describes “replacing VPAID with a set of more focused standards” — OMID for measurement and verification, SIMID for interactivity. SIMID separates the interactive layer from the media asset, both delivered via VAST 4.x, which is what lets interactivity coexist with SSAI and OTT delivery. The current version is 1.2 (spec marked December 2022; the official page notes a January 2024 update).
- Deprecated — historical only
VPAID
The Video Player-Ad Interface Definition is officially deprecated. IAB Tech Lab’s own page — which now lives under its archived standards path — states that VPAID “has been deprecated and is being replaced by” OMID and SIMID. The last published version is 2.0. VPAID bundled interactivity and measurement into one executable unit that players had to trust — a model at odds with SSAI and constrained CTV runtimes; its successors split those jobs apart. Treat any VPAID dependency as technical debt, not as a capability.
| Standard | Primary job | Current role | Agentic relevance |
|---|---|---|---|
| VAST 4.3 | Serve video ads: the XML schema carrying ad media, tracking, and metadata to players | Current version (released December 2022), with CTV-focused changes | The tag the agent’s plan must compile to — and the carrier of creative IDs and measurement hooks |
| VAST CTV Addendum 2024 | Retrofit CTV-critical features into VAST 2.0+ via backward-compatible extensions | Final, July 2024 — an addendum, not a new VAST version | Creative IDs, Open Measurement, DSA icons, and interactive video across legacy and SSAI paths — where implemented |
| SIMID 1.2 | Interactive video creative, separated from the media asset and isolated from the player | Current (spec marked December 2022; official page updated January 2024) | The sanctioned route to interactivity that still works with SSAI and OTT delivery |
| VPAID 2.0 | Legacy executable video creative combining interactivity and measurement in one unit | Officially deprecated — being replaced by OMID and SIMID per IAB Tech Lab | A dependency to remove, not a capability to plan around |
SSAI and CTV execution.
Server-Side Ad Insertion is how much of CTV actually delivers ads — and a precision point worth getting right: SSAI is a delivery technique with official IAB guidance and VAST-level support features, not a standalone IAB specification. The questions it raises — verification, transparency, creative identity — are answerable, but only if they are asked before the spend.
- 01
What SSAI is
Server-Side Ad Insertion stitches ads into the content stream before it reaches the device, so OTT and CTV playback can stay continuous. The trade: the ad call no longer happens where client-side measurement expects it.
- 02
What officially exists
There is no standalone IAB SSAI specification. The official artifact is the SSAI VAST Macros Guidance v1.0 (November 2020) — guidance, not a spec — a curated subset of VAST macros for sharing user-agent, environment, and content details with verification partners and buyers. VAST 4.x adds built-in SSAI-support features on top.
- 03
Creative identity survives the stitch
The UniversalAdId element of VAST 4.x carries a unique creative identifier, with Ad-ID as the registry for US markets. The CTV Addendum 2024 retrofits UniversalAdId recognition into VAST 2.0–3.x — and explicitly names SSAI vendors among the parties expected to implement its extensions.
- 04
The verification question
When the server requests and stitches the ad, the buyer must ask: which environment details reach verification partners, which macros are actually populated, and what independent measurement runs where supported on the device. Design those answers before the spend, not after.
The trade
SSAI can improve viewing experience, but it can also make verification and transparency harder if measurement is not designed upfront.
Mobile creative and rich media.
In-app advertising runs on a different contract than the web. The ad needs a standardized way to talk to the app that hosts it — and a clear-eyed view of what that contract does and does not cover.
- In-app rich media
MRAID 3.0
The common API between rich media ads and the in-app environments they run in: expand, resize, device-feature access, orientation, and full-screen interstitials. The current version is 3.0 (final, June 2018), which added viewability measurement support, audibility, a standardized close control, and error handling — and is backwards compatible with earlier MRAID versions. The watch-out: MRAID gives the ad a contract with the app; it does not solve measurement or verification on its own.
- Creative payloads
HTML5 ad guidance
IAB creative guidance covers how HTML5 ad payloads should be packaged and behave across environments — file structure, asset behavior, and host-environment expectations. Treat it as directional creative hygiene rather than a versioned delivery contract, and validate the current official guidance before locking specs into a workflow.
- Not a standard
The mobile SDK environment
The app’s SDK stack — rendering, mediation, and measurement SDKs — is implementation, not standard. MRAID and OM SDK are the standardized interfaces into that environment; everything else varies by app, mediation chain, and platform. An agentic workflow should treat each in-app environment as conditionally capable, never uniformly capable.
Measurement and verification.
Delivery without measurement is an invoice, not an impression. The measurement rail for this layer is Open Measurement — the SDK that carries the data, the OMID API that verification scripts speak, and, since late 2025, device attestation against spoofing. Each proves something specific; none proves everything.
- The data rail
OM SDK
One integration that enables third-party ad measurement instead of one custom integration per verification vendor. On CTV, public documentation lists native SDKs for tvOS and Android TV (announced June 2022) and Samsung and LG support via the HTML5/Web Video SDK in the OM SDK 1.5 release line (May 2024). Roku and Vizio are not listed as OM SDK platforms — treat CTV coverage as partial, where supported.
- The API
OMID
The Open Measurement Interface Definition — the API verification scripts use to receive measurement signals from OM SDK integrations. The current documented API version is OMID 1.6. OMID is also half of VPAID’s official replacement: OMID for measurement and verification, SIMID for interactivity.
- Shipped Oct 2025
Device attestation
IAB Tech Lab launched Device Attestation support in OM SDK on October 23, 2025 to combat device spoofing, adopting the IETF Privacy Pass protocol, with published implementation guidance and a public GitHub repository. The launch press release says the capability is “currently supported on Apple devices and FireTV”; a 2026 Tech Lab blog describes the latest release as bringing it to Samsung, LG, AndroidTV, and tvOS — two official statements, attributed here to their sources. DoubleVerify, HUMAN, and Integral Ad Science were quoted supporting it at launch. Watch-outs: no OM SDK version number is stated for it, platform coverage is not universal, and attestation proves the device is authentic — it is not a complete fraud solution.
| Measurement layer | What it proves | What it does not prove |
|---|---|---|
| VAST tracking events | That the player fired delivery and quartile events for the tag | That a human saw the ad, or that the events came from an authentic environment |
| MRAID 3.0 viewability support | That the in-app environment can expose exposure and audibility data to the ad | Independent verification — MRAID is the ad-to-app contract, not a measurement service |
| OM SDK | Standardized collection of geometry, viewability, and session data for third parties | A fraud or quality verdict — verification vendors judge with the data it carries |
| OMID verification scripts | That vendor code can observe the measurement session where the integration runs | Coverage on platforms without OM SDK support — absence of signal is not absence of ads |
| Device attestation | That the impression rendered on an authentic device, where supported | That the ad was viewable, the context suitable, or that spoofing elsewhere is impossible |
| SSAI VAST macros | That server-side delivery can share environment and content details with verifiers | Client-side confirmation — populated macros are declarations, not independent observations |
Mobile identifiers and attribution.
These are not delivery standards — they are the platform-governed identifiers and attribution frameworks that delivery and measurement workflows depend on. None of them is stable, universal, or privacy-safe by default: every one is permission-gated, resettable, scoped, or being phased out. Treat each as a conditional input and validate current status before building on it.
- Apple identifier
IDFA + ATT
The IDFA is gated by App Tracking Transparency: apps must declare a usage description and request authorization before accessing app-related data for tracking across apps and websites. The ATT framework is available from iOS and iPadOS 14.0. Never assume IDFA availability — it is a permission outcome, not a property of the device.
- Apple attribution
SKAdNetwork
Apple’s privacy-preserving install-validation framework — an attribution and measurement framework, not a delivery standard. The current documented version is version 4: up to three conversion windows starting iOS 16.1, up to three postbacks, and a winning postback plus runner-ups. Two older methods are deprecated; the framework itself remains documented, and Apple recommends AdAttributionKit for new ad campaigns.
- Apple attribution, newer
AdAttributionKit
Apple’s newer attribution framework, available from iOS 17.4, interoperable with SKAdNetwork. It supports install and re-engagement attribution in the App Store and alternative marketplaces, operates without ATT authorization, and sends cryptographically signed postbacks containing no user- or device-specific data. Neither framework makes all iOS measurement questions answerable — design within their constraints.
- Android identifier
AAID — Android Advertising ID
The identifier Google’s documentation assigns to advertising use cases. It is user-resettable, and — since the late-2021 Google Play services update — opting out zeroes it: attempts to access it return a string of zeros. Play policy forbids connecting it to personally identifiable information or persistent device identifiers (including SSAID) without consent, and forbids bridging user resets.
- Not SSAI
SSAID — ANDROID_ID
An Android device identifier concept — not an advertising delivery standard, and not to be confused with SSAI (Server-Side Ad Insertion). Per official documentation, on Android 8.0+ it is a 64-bit value scoped to the combination of app-signing key, user, and device, and can change on factory reset or signing-key change. The anti-ads guidance is indirect but firm: advertising use cases are assigned to the Advertising ID, and Play policy bans associating the Advertising ID with SSAID.
- Android, same-developer
App Set ID
A Google Play services identifier offered, per official documentation, “for use cases such as analytics or fraud prevention” across a set of apps owned by one organization. The best-practices guidance permits cross-app analysis of your own apps “as long as you don’t use user data for advertising purposes.” It resets if unused for over 13 months, when the last app in the set is uninstalled, or on factory reset.
- Retired — being phased out
Android Attribution Reporting
Google’s October 17, 2025 Privacy Sandbox announcement explicitly retires the “Attribution Reporting API (Chrome and Android)” — along with Protected Audience, Topics, Protected App Signals, and SDK Runtime — describing the technologies as being phased out, with no published end dates. Do not build new dependencies on it; validate current status, and watch the W3C attribution-standard work the announcement points to.
| Identifier / framework | Platform | Role | Key caveat |
|---|---|---|---|
| IDFA | iOS | Device advertising identifier | Gated by ATT authorization — never assume availability |
| ATT | iOS 14.0+ | Tracking-permission framework | Permission gate, not an identifier; no deprecation notes in public documentation |
| SKAdNetwork | iOS | Install attribution framework | Version 4 per Apple docs; two methods deprecated, framework remains — not a delivery standard |
| AdAttributionKit | iOS 17.4+ | Install + re-engagement attribution | Interoperable with SKAdNetwork; operates without ATT authorization — not a delivery standard |
| AAID | Android | Device advertising identifier | User-resettable; zeroed on opt-out since the late-2021 Play services update |
| SSAID (ANDROID_ID) | Android 8.0+ | Per-app-signing-key device identifier | Not an ads identifier — and not to be confused with SSAI (Server-Side Ad Insertion) |
| Attribution Reporting (Android) | Android | Privacy Sandbox attribution API | Retirement announced Oct 2025 — being phased out; validate current status |
What this means for agentic advertising.
Agentic systems negotiate and plan at a layer above all of this — and then every plan has to descend through it. The delivery layer is where an agent’s assumptions get audited by reality: by players that parse only some of VAST, identifiers that may not exist, and measurement that covers only some platforms. Six implications follow.
- 01
The plan-to-render gap
An agent’s media plan must compile down to VAST tags that the target players actually parse. CTV Addendum extension support varies by player and SSAI vendor — capability checks belong in the workflow, not in assumptions.
- 02
Creative identity is enforcement
Without registered creative IDs — UniversalAdId, and the ACIF framework the CTV Addendum points to — an agent cannot enforce frequency, competitive separation, or creative-level brand rules across SSAI and CTV paths.
- 03
Measure before you optimize
An agent should only optimize on signals that OM SDK and independent verification can actually carry on that platform, where supported. Optimizing on unverifiable signals automates wishful thinking.
- 04
Platform rules are runtime constraints
ATT status, identifier availability, and SKAdNetwork or AdAttributionKit postback design decide what attribution an agent may even request. Encode the constraints into the workflow before the campaign, not into the apology after it.
- 05
Spoofing scales with automation
Automated buying finds cheap CTV reach fast — and so does spoofed inventory. Use device attestation where supported, require app and bundle verification, and assume fraud adapts to every new buying pattern.
- 06
Deprecation debt is agent debt
VPAID-era assumptions and retiring APIs like Android Attribution Reporting must be removed from agent toolchains deliberately. An agent that plans around a deprecated capability fails silently at execution time.
Standards comparison.
The working matrix: what each standard or framework does, where it stands per the latest official documentation, and where it is covered in depth.
| Standard / framework | Primary job | Status per official documentation | Covered in |
|---|---|---|---|
| VAST 4.3 | Video ad serving template | Current (December 2022) | Core AdTech Standards |
| VAST CTV Addendum 2024 | CTV extensions across VAST 2.0+ | Final (July 2024); extension-based, not a new version | SSAI and CTV execution |
| SSAI VAST Macros Guidance | VAST macro subset for SSAI verification detail | v1.0 guidance (November 2020) — not a standalone spec | SSAI and CTV execution |
| SIMID 1.2 | Interactive video creative layer | Current (Dec 2022 spec; page updated Jan 2024) | Video delivery standards |
| VPAID 2.0 | Legacy executable video creative | Officially deprecated — replaced by OMID + SIMID | Video delivery standards |
| MRAID 3.0 | In-app rich media API | Current (final, June 2018) | Mobile creative and rich media |
| OM SDK | Measurement data collection rail | 1.5 release line per latest official documentation | Measurement & Media Quality |
| OMID | Open Measurement API | API version 1.6 per latest official documentation | Measurement & Media Quality |
| OM SDK Device Attestation | Authentic-device proof for impressions | Launched October 23, 2025; platform coverage partial — validate current status | Measurement and verification |
| SKAdNetwork / AdAttributionKit | iOS attribution frameworks — not delivery standards | SKAN version 4; AdAttributionKit from iOS 17.4, interoperable | Privacy & Consent Standards |
| Android identifiers (AAID, App Set ID, ARA) | Android identifier and attribution set | AAID zeroed on opt-out; Attribution Reporting being phased out per Oct 2025 announcement | Privacy & Consent Standards |
Implementation lens.
The same standards land differently depending on where you sit in the chain. Select your company type for the version of this page that applies to you.
Require registered creative IDs (UniversalAdId) on video buys, independent measurement via OM SDK where supported, and explicit answers on SSAI verification before treating CTV reach as premium. Keep attribution expectations inside what SKAdNetwork, AdAttributionKit, and the Android identifier rules actually permit.
Translate plans into delivery reality: which players parse which VAST features, which CTV platforms carry OM SDK, where device attestation applies, and which identifier constraints shape measurement design per platform. Maintain a capability matrix per supply path and validate it on a cycle.
Implement VAST 4.x and the CTV Addendum extensions, populate SSAI VAST macros for verification partners, integrate OM SDK on supported platforms, and carry creative IDs through the stitch. Transparency here is a sales asset — buyers increasingly gate spend on it.
Support MRAID 3.0 for rich media, integrate OM SDK for measurement, and follow the platform identifier rules: AAID for advertising on Android, App Set ID only for same-developer analytics and fraud use, ATT-gated IDFA on iOS. Never connect advertising IDs to persistent device identifiers.
Parse and emit VAST CTV Addendum extensions, support SIMID rather than VPAID-era creative, carry SSAI macros faithfully, and surface OM SDK and attestation signals to buyers. Remove retired dependencies — VPAID assumptions and Android Attribution Reporting — from roadmaps deliberately.
Build on OMID 1.6 sessions where OM SDK runs, consume SSAI macro details for server-side paths, and incorporate device-attestation signals where supported — while being explicit with clients about which platforms have no coverage. Absence of signal is not absence of ads.
Design measurement around SKAdNetwork version 4 and AdAttributionKit on iOS, AAID-with-consent on Android, and the retirement of Android Attribution Reporting. Treat every identifier as conditional — resettable, permission-gated, or being phased out — and validate current status on a cycle.
No Fluff POV.
Video and mobile standards are where workflow ambition meets execution reality. The agentic layer gets the headlines; this layer decides whether anything the agent planned actually happens, gets measured, and can be defended. Build for it deliberately.
- Treat the delivery layer as a constraint set the agent must satisfy, not a detail someone downstream will handle.
- Remove VPAID-era assumptions deliberately — the official direction is OMID for measurement and SIMID for interactivity.
- Design SSAI measurement upfront: which macros are populated, which verification runs where supported, and how creative IDs survive the stitch.
- Treat identifiers as conditional inputs — never stable, never universal, never privacy-safe by default.
- Keep attribution claims inside what SKAdNetwork, AdAttributionKit, and the Android identifier rules actually support.
- Validate current status before building: this layer keeps moving — VPAID deprecated, the CTV Addendum shipped in 2024, device attestation launched in 2025, and Privacy Sandbox ad APIs were retired the same year.
The point
The agent may plan the buy, but the ad still has to render in a player, run inside an app, pass measurement, respect platform rules, and survive verification.
Primary sources to validate.
Video, mobile, CTV, measurement, and platform references last validated: June 2026. Validate current official documentation before implementation.
Primary sources to validate 28 sources
- Update on Plans for Privacy Sandbox Technologies ↗ Official blog
Google's October 17, 2025 announcement retiring most Privacy Sandbox ad APIs — including Topics, Protected Audience, and Attribution Reporting (Chrome and Android) — citing ecosystem feedback and low adoption. CHIPS, FedCM, and Private State Tokens continue. No concrete removal dates published. Supports: Current Privacy Sandbox status, Which APIs are retired vs continuing, Why Google retired the ad APIs.
-
Google's April 22, 2025 announcement that Chrome will keep third-party cookies under the existing user-choice settings and will not roll out a standalone cookie prompt — reversing earlier deprecation plans. Supports: Third-party cookie status in Chrome, Cookie-deprecation reversal (April 2025).
- Privacy Sandbox feature status ↗ Official docs
Per-API status table (last updated October 17, 2025): Topics, Protected Audience, Attribution Reporting, Private Aggregation, Shared Storage/SelectURL, and Related Website Sets marked 'Deprecate and remove'; CHIPS, FedCM, and Private State Tokens continue. The live tracker for validating current status. Supports: Per-API deprecation status, Live phase-out tracker.
- Topics API — developer documentation ↗ Official docs
Canonical Topics API docs: interest-based advertising without sharing the specific sites a user visited. Carries a phase-out banner — historically important, being retired; validate current status before building on it. Supports: What the Topics API does, Phase-out caveat.
- Protected Audience API — developer documentation ↗ Official docs
Canonical Protected Audience (formerly FLEDGE) docs: on-device ad auctions run by the browser for remarketing / custom-audience ads without cross-site third-party tracking. Carries the same phase-out banner — validate current status. Supports: What Protected Audience does, Phase-out caveat.
- Attribution Reporting API — developer documentation ↗ Official docs
Canonical Attribution Reporting docs: browser-generated reports matching ad interactions to conversions without cross-site tracking. Carries the same phase-out banner — validate current status. Supports: What Attribution Reporting does, Phase-out caveat.
- SKAdNetwork — Apple Developer documentation ↗ Official docs
Apple's privacy-preserving install-validation API. Documents version 4: up to three conversion windows (starting iOS 16.1), up to three postbacks, and a winning postback plus up to five runner-up postbacks. Only two methods are deprecated — not the framework; Apple recommends AdAttributionKit for new ad campaigns. Supports: What SKAdNetwork does, SKAdNetwork version 4 specifics, Apple's AdAttributionKit recommendation.
- AdAttributionKit — Apple Developer documentation ↗ Official docs
Apple's newer attribution framework (iOS/iPadOS/Mac Catalyst 17.4+): install and re-engagement attribution for ads in the App Store and alternative marketplaces, no ATT authorization required, cryptographically signed postbacks containing no user- or device-specific data. Supports: What AdAttributionKit does, OS availability (17.4+), Re-engagement and alternative-marketplace support.
-
The authoritative reference for how AdAttributionKit and SKAdNetwork interact when delivering ad impressions — the two frameworks coexist and interoperate; neither has fully replaced the other. Supports: AdAttributionKit–SKAdNetwork relationship.
-
ATT requires apps to declare NSUserTrackingUsageDescription and request user authorization (ATTrackingManager.requestTrackingAuthorization) before accessing app-related data for cross-app/website tracking. Available iOS/iPadOS 14.0+; no deprecation notes — ATT remains in force. Supports: What ATT does and requires, OS availability.
- MRAID — Mobile Rich Media Ad Interface Definitions (IAB Tech Lab standards page) ↗ Official standards page
Official MRAID page listing 3.0 as the current version. MRAID is the common API between rich media ads and in-app environments — expand/resize, device-feature access, orientation handling, full-screen interstitials. 3.0 added viewability measurement support, audibility, a standardized close button, and error handling; backwards compatible with prior MRAID versions. Supports: MRAID current version (3.0), What MRAID defines, 3.0 feature additions, Backward compatibility.
-
The normative MRAID 3.0 specification PDF, FINAL June 2018 — still the current MRAID spec per the official standards page as of June 2026. MRAID defines the in-app rich media ad API; it is not a measurement or attribution solution. Supports: Canonical MRAID 3.0 spec citation, June 2018 final date.
- SIMID — Secure Interactive Media Interface Definition (IAB Tech Lab standards page) ↗ Official standards page
Official SIMID page: latest version 1.2 (page last updated January 3, 2024). States the Digital Video Technical Working Group is 'replacing VPAID with a set of more focused standards' — OMID for measurement/verification, SIMID for interactivity. SIMID separates the interactive layer from the media asset, both delivered via VAST 4.x, enabling SSAI and OTT use cases. Supports: SIMID current version (1.2), Official VPAID-replacement framing, SSAI/OTT positioning.
- SIMID 1.2 specification (PDF) ↗ Official docs
The SIMID 1.2 specification PDF ('Released December 2022'; the standards page notes a January 2024 update — cite both dates). v1.2 added responsive ad support, L-shaped ad-space guidance, cryptographic session-ID requirements, and deep-link handling. Supports: Canonical SIMID 1.2 spec citation, v1.2 changelog, Dual dating (Dec 2022 PDF / Jan 2024 page).
- VPAID — Video Player-Ad Interface Definition (official page, deprecated) ↗ Official standards page
The official VPAID page — now living under /standards-old/ — states verbatim that VPAID 'has been deprecated and is being replaced by Open Measurement Interface Definition (OMID) and Secure Interactive Media Interface Definition (SIMID).' Last published version is VPAID 2.0. Supports: VPAID deprecation (official wording), Last version (2.0), OMID + SIMID as the named replacements.
- SSAI VAST Macros Guidance — IAB Tech Lab page ↗ Official standards page
The official server-side ad insertion artifact: SSAI VAST Macros Guidance v1.0 (November 2020) — a curated subset of VAST macros for sharing user-agent, environment, and content details with verification partners and buyers; compatible with VAST 2.0+. It is guidance, not a standalone SSAI specification — IAB Tech Lab publishes no standalone 'SSAI spec'; VAST 4.x carries built-in SSAI-support features. Supports: What officially exists for SSAI (guidance, not a spec), SSAI macro purpose and scope, v1.0 / Nov 2020 dating.
-
The canonical SSAI VAST Macros Guidance document, v1.0, November 2020. Supports: Canonical SSAI guidance citation.
- A Deeper Look into VAST 4.0 and the Universal Ad ID ↗ Official blog
Official explainer: the UniversalAdId element of VAST 4.x carries a unique creative identifier maintained across platforms, with Ad-ID (ad-id.org) as the registry for US markets. Registry metadata supports creative-level competitive separation, brand safety, and advertiser/product categorization; consistent creative IDs also help in SSAI environments. Supports: Universal Ad-ID purpose in VAST 4.x, Ad-ID as the US registry, UniversalAdId element placement.
- VAST CTV Addendum 2024 (FINAL, July 2024 — PDF) ↗ Official docs
The final addendum (published July 18, 2024) retrofits CTV-critical features into VAST 2.0–3.x via backward-compatible extensions — explicitly not a new VAST version: UniversalAdId recognition (a designated field in VAST 4.x), ACIF registered ad IDs, Open Measurement, interactive video, high-resolution creative, and DSA-compliance icons. Names video players, SSAI vendors, and ad platforms that parse and execute VAST tags as implementers. Supports: CTV Addendum scope, UniversalAdId retrofit into VAST 2.0–3.x, SSAI vendors as named implementers, Extension-based approach (not a VAST version bump).
- IAB Tech Lab Expands Open Measurement SDK to Connected TV ↗ Official press release
June 8, 2022 announcement extending OM SDK to CTV (available Q3 2022) on tvOS and Android TV, adding CTV-specific viewability signals — TV-off signaling and last-user-activity-in-app — alongside screen/ad geometry, obstruction, viewable impressions, and quartile measurement. Supports: OM SDK CTV launch (June 2022), Initial CTV platforms (tvOS, Android TV), CTV-specific signal list.
- IAB Tech Lab Expands Open Measurement SDK to New CTV Platforms (Samsung, LG) ↗ Official press release
May 30, 2024 announcement adding Samsung and LG to OM SDK CTV coverage — delivered via the HTML5/Web Video SDK in the OM SDK 1.5 release line per the standards pages (the PR itself states no version number). Cited 40% CTV-market coverage as of that announcement (a stale figure — do not cite as current). Roku, Vizio, and Fire TV are not listed as OM SDK CTV measurement platforms on official pages. Supports: Samsung/LG addition (May 2024), HTML5/Web Video SDK delivery, Platform-coverage limits (no Roku/Vizio).
- IAB Tech Lab Launches Device Attestation Support in Open Measurement SDK to Combat Device Spoofing ↗ Official press release
October 23, 2025 launch (shipped, not proposed) of Device Attestation in OM SDK, adopting the IETF Privacy Pass protocol for the ads-verification use case. The PR states the capability 'is currently supported on Apple devices and FireTV'; a 2026 Tech Lab blog instead lists Samsung, LG, AndroidTV, and tvOS — attribute each list to its source rather than merging them. No OM SDK version number is stated. DoubleVerify, HUMAN, and Integral Ad Science quoted supporting at launch. Attests device authenticity only — not a complete fraud solution. Supports: Device Attestation launch (Oct 23, 2025), Privacy Pass basis, PR platform list (attributed), Launch supporters (DV, HUMAN, IAS).
- OM SDK Device Attestation Implementation Guidance ↗ Official docs
Landing page (last updated November 4, 2025) hosting the Open Measurement Device Attestation Implementation Guidance PDF (uploaded October 2025), which references the IETF Privacy Pass working group — evidence that the capability shipped with formal implementation guidance. Supports: Published implementation guidance (shipped status).
- OMSDK-Device-Attestation repository ↗ Official GitHub
Public repo containing the implementation guidance and attestation flow diagram; frames the capability as privacy-preserving attestations made by device manufacturers. The README describes the initiative as 'In Progress' — the capability launched October 2025 but expansion work continues. Supports: Official technical resource location, Post-launch expansion signal.
- Open Measurement Working Group — IAB Tech Lab directory page ↗ Official standards page
Official directory entry for the working group under which OM SDK/OMID standards work is developed: owner Jill Wittkopp, status Active, join via [email protected]. The page publishes no detailed charter text — do not quote a mission statement from it. Supports: Working group existence, owner, active status, Stewardship of OM SDK/OMID.
-
Google's canonical identifier-per-use-case guidance: use the most restrictive identifier that satisfies the use case — advertising → Advertising ID (AAID); same-developer analytics/crash reporting → App Set ID or Firebase Installation ID; fraud prevention → Play Integrity API. AAID is user-resettable and, since a late-2021 Google Play services update, returns a string of zeros after opt-out; Play policy forbids connecting it to PII or persistent device identifiers (SSAID, MAC, IMEI) and bans bridging user resets. No Android identifier is stable or universal. Supports: Identifier-per-use-case mapping, AAID reset and zero-on-opt-out behavior, Play policy constraints on AAID.
-
Official SSAID/ANDROID_ID definition: on Android 8.0 (API level 26) and higher, a 64-bit number unique to each combination of app-signing key, user, and device; the value may change on factory reset or APK signing-key change. SSAID is an Android device-identifier concept, not an ad-delivery standard — not to be confused with SSAI (server-side ad insertion). Official guidance assigns advertising use cases to the Advertising ID, not SSAID. Supports: SSAID definition and per-signing-key scoping, Reset behavior, SSAID-vs-SSAI disambiguation.
-
Official App Set ID page: a Google Play services identifier for analytics or fraud prevention across apps owned by one organization — per the best-practices doc, usable only 'as long as you don't use user data for advertising purposes.' Scoped to the Google Play developer account (app-scoped fallback); resets after 13 months without access, when the last app in the set is uninstalled, or on factory reset. Supports: App Set ID purpose and advertising restriction, Scope (Play developer account), Reset conditions.
Platform capabilities and naming change quickly. Last validated: June 12, 2026. Check current documentation before implementation.Video, mobile, CTV, measurement, and platform references last validated: June 2026. Validate current official documentation before implementation.
Building video, CTV, or mobile execution into an agentic workflow?
The operating work is to wire VAST capability checks, SSAI measurement design, identifier constraints, and independent verification into the execution path — before agents scale whatever the delivery layer actually permits.