An ad that sits inside an iframe is separated from the page around it. That separation protects the page, and according to IAB Tech Lab it also made measurement hard: before SafeFrame, measurement was a black box for ads contained within an iframe. SafeFrame is the secure container for rich ad interaction, and the Open Measurement SDK is the shared measurement layer. If you sell ad space or want to set up verification and measurement as an advertiser, knowing which of the two answers which question saves a lot of report arguments.
Example scenario: A local newspaper sells ad slots on its news site and inside its mobile app. A hardware store in the town buys a campaign on both. After a month the store owner sees a viewability number from the newspaper's report and a different one from the verification vendor, and asks the newspaper to explain. Part of the answer sits in where each ad ran and which measurement route each report used.
Three layers that blur together
Container, interaction and measurement are three separate layers. The IAB Tech Lab pages treat them separately, and the table keeps the vocabulary straight.
| Layer | Question it answers | Where the IAB Tech Lab pages put it |
|---|---|---|
| Container | Where does the ad run and what can its code reach | SafeFrame article, an ad container for web display, with MRAID for mobile |
| Interaction | How does the ad respond to the user | SafeFrame for rich ad interactions on the web, SIMID for video |
| Measurement | Was the ad seen and was the traffic valid | Open Measurement SDK and the OMID API |
Decision rule: choosing the layer
Decision rule: If your question is about whether ad code can reach the page, or about rich interaction inside a web container, look at SafeFrame. If your question is about viewability, invalid traffic or device authenticity, look at the Open Measurement SDK. If the ad runs inside a mobile app, look at the SDK's Android and iOS documentation. If the ad is video and the question is about interaction, look at SIMID, and for measurement, OMID. When two questions arrive together, separate interaction from measurement first and send each to the right party.
| Question | Look at | Source page |
|---|---|---|
| Does the ad run safely in the page | SafeFrame | IAB Tech Lab SafeFrame page |
| Was the ad viewable and for how long | Open Measurement SDK | IAB Tech Lab OM SDK page |
| What signal does invalid traffic verification use | Open Measurement SDK and the provider | OM SDK page |
| Ad inside a mobile app | OM SDK for Android or iOS | OM SDK page |
| Interaction and measurement in a video ad | SIMID and OMID | IAB Tech Lab SIMID page |
The rule helps because it routes each question to the party that can answer it. Container and interaction questions go to the publisher's page or app team. Measurement questions go to the measurement provider. Teams that try to settle both in one meeting miss who owes the answer, so write the responsible party next to each question.
How an iframe boundary blocks measurement
The SafeFrame article states the problem plainly. Measurement was a black box for ads contained within an iframe, and SafeFrame at its initial release was vital to enabling measurement in iframes. In other words, the iframe is a boundary, and a boundary stops one side from freely seeing the other. A script that watches the page cannot assume it knows what happens inside the ad.
The article takes it as given that ads are contained in iframes and describes what that means for both security and measurement. Practical suggestion: when someone says the ad ran in an iframe, ask what that means for how it was measured, because the answer decides which report you should trust for which question.
SafeFrame as its working group describes it
The article on IAB Tech Lab's SafeFrame page (Opens in a new tab) was written by the co-chairs of the SafeFrame Working Group. It does not give a formal definition. It describes SafeFrame as a way to deliver rich ad interactions in web pages and apps, an ad container for web display, with MRAID covering mobile.
Security comes first
The authors say that, first of all, security was and still is the first priority for SafeFrame. They add that page security prevents access to user data and promotes user privacy. For an advertiser, that means the container is designed so ad code does not get free access to the page or its visitor data.
Aims of version 2.0
The article presents SafeFrame 2.0 as a major update to the first release, arriving more than six years later. The goals it lists are simpler implementation, alignment with MRAID, simpler creative expansion and event-based APIs. The authors say the original design had become outdated and that a more universal approach was needed for all HTML display ads, on web or mobile web.
Relying on browser features
According to the article, version 2.0 replaces the old register process with an event listener and drops the prescriptive host implementation, so publishers can innovate on hosting. It relies on browser features such as sandboxing, feature policy (permission policy) and intersection observer rather than duplicating them. Calling expand() expands the ad to the maximum size allowed.
Status as of writing
When the article was written, SafeFrame 2.0 was in public comment for 60 days, which the authors say is double the usual length because of the six-year gap. They also say wide adoption is needed for the benefits to be realized, and that host support guidance was in development. Standards change status over time. Check the current IAB Tech Lab page before relying on the status.
Measurement moves to Open Measurement
One sentence in the article explains the division of labor. As IAB Tech Lab develops Open Measurement for web, SafeFrame no longer needs to offer the measurement feature. That leaves SafeFrame free to concentrate on rich ad experiences. The container keeps the security and interaction job, and measurement moves to Open Measurement.
The same split shows up for video on the SIMID page of the IAB Tech Lab, which says OMID handles measurement and verification while SIMID handles interactivity. On the web display side it is SafeFrame and Open Measurement. On the video side it is SIMID and OMID. Different standards, one pattern: one handles safe interaction, the other makes the measurement signal shared.
The OM SDK in three questions
The page on the Open Measurement SDK (Opens in a new tab) describes the SDK as an industry-standard solution that brings transparency and trust to digital advertising measurement. It provides common code and libraries that give third-party measurement providers access to measurement data. The page was last updated on November 4, 2025.
Signals measured
The page names three areas. Impression and viewability: it confirms when ads appear on screen, what percentage is in view and for how long. Invalid traffic: it facilitates third-party verification of invalid traffic and brand requirements. Device authenticity: Device Attestation addresses what the page calls the prevalent device spoofing problem faced in digital ads.
Supported environments
According to the source, the SDK standardizes implementation and signals across mobile apps, web and connected TV. Developer documentation covers Android, iOS and JS. For connected TV there are native SDKs for AndroidTV and tvOS, and the HTML5 and Web Video SDK includes Samsung and LG TV support, added in OM SDK 1.5.
Mechanism
Sites and apps integrate the SDK to send signals to the Open Measurement Interface Definition (OMID) API. Measurement providers can place tags that collect these signals. The text lists OMID 1.6 as current and notes that API documentation for 1.3 through 1.5 is also available. Vendor names are left out; it speaks only of measurement providers and verification partners and links to a Transparency Center list of SDK-compliant companies.
Verification and invalid traffic: division of work
Per the OM SDK page, the SDK facilitates third-party verification of invalid traffic and brand requirements. It does not say the SDK filters or removes invalid traffic itself. The picture is two layers. The SDK provides the shared signal, and a measurement provider interprets it and reports on it.
For an advertiser, that distinction changes the question. Asking which vendor produced the invalid traffic report is only half of it. Ask also whether the signal behind the report is collected through Open Measurement. For the mechanics of invalid traffic and click verification, the invalid traffic and ad click verification guide goes further. Which vendor to choose is a business decision for the advertiser.
Benefits for advertiser, publisher and developer
The source sorts the benefits by audience. For advertisers, it says the SDK helps ensure you only pay for ads that had the opportunity to be seen, and that it works with multiple verification partners at once. For publishers and connected TV app developers, one implementation replaces custom integrations with multiple verification providers, and it lets developers sell with confidence in the authenticity of the devices on which customers' ads appear. Industry-wide, compliance certification verifies that your OM SDK implementation works with measurement providers.
| Role | Benefit stated on the page | Question to ask |
|---|---|---|
| Advertiser | Pay only for ads that had the opportunity to be seen, multiple verification partners at once | Which verification partner measures the campaign |
| Publisher | One implementation instead of custom integrations, confidence in device authenticity | Has the site or app integrated the OM SDK |
| App developer | Single SDK for each platform | Which platform SDK is in use |
| Industry | Compliance certification confirms the implementation works with providers | Is there a compliance certification |
A local newspaper on its site and in its app
Example scenario: The newspaper's website shows the hardware store's banner inside a container on the article page. The newspaper's mobile app shows the same campaign inside the app. The owner wants one answer to one question: was my ad seen?
The OM SDK text says the standard covers mobile apps, web and connected TV, so the same signal language can exist on both of the newspaper's surfaces. On the web side, the SafeFrame article says measurement duties were handed to Open Measurement. In the app, the SDK documentation for Android and iOS applies. Practical suggestion: the owner should ask the newspaper two things in writing. Which container does the web ad run in, and is measurement done with Open Measurement? Has the app integrated the OM SDK, and on which platform?
- Ask the newspaper which container the web ad runs in and get the answer in writing.
- Ask the verification vendor whether it collects viewability and invalid traffic signals through Open Measurement.
- Ask whether the app has integrated the OM SDK and which platform it supports.
- If the two reports differ, collect the method notes from both sides before drawing conclusions.
For help reading viewability thresholds and what counts as a viewable impression, the ad viewability and IAB standards article is a good companion. For the indicators that matter in a banner campaign report, see measuring banner ad performance.
Measurement tags and page weight
Measurement providers can place tags that collect the signals. Those tags are third-party code, and their effect on page performance falls outside the OM SDK page. Practical suggestion: put measurement tags on the same audit list as other third-party scripts and check what loads, when, and how it affects speed. The third-party scripts performance audit article lays out the steps.
The page does say that a single implementation replaces custom integrations with multiple verification providers. That points toward less duplicated code for the publisher, though the page does not quantify the reduction. A publisher weighing speed against verification coverage should measure its own pages.
One signal set and one method
According to the OM SDK page, basic signals such as on-screen placement, overlay transparency and quartile tracking are collected under one methodology, which makes results comparable and helps detect issues such as ad fraud. Comparable does not mean identical, so a report gap can still remain when two vendors both use the same signals.
What to ask the publisher and the provider
Compatibility can mean two things here. Per the OM SDK page, compliance certification verifies that an OM SDK implementation works with measurement providers. Whether a specific site or app holds that certification is not stated on the page, which only points to compliance resources. Practical suggestion: split your questions into two groups.
Questions for the publisher
- Does the ad slot use SafeFrame or an iframe, and can that be confirmed in writing?
- Has the site or app integrated the OM SDK, and for which platform?
- Is there a compliance certification for the implementation?
- Can several verification partners measure the same campaign?
Questions for the provider
- Are viewability and invalid traffic signals collected through Open Measurement?
- Which OMID version is supported? The text lists 1.6 as current.
- Is Device Attestation used?
- How is a method difference explained when two reports disagree?
When each question has a written answer, a report gap discussion starts from known methods. Questions without answers stay on the open list. Since the pages name no vendors, evidence about a particular vendor's quality has to come from elsewhere.
Version history
The Open Measurement SDK source lists the OMID versions with short notes, and the list helps place a publisher's answer. The page names OMID 1.6 as the current API.
| Version | What the page notes |
|---|---|
| OMID 1.0 | Initial full specification |
| OMID 1.2 | Web browser support |
| OMID 1.3 | Better session classification, audio support, friendly obstructions |
| OMID 1.4 | New CTV events |
| OMID 1.5 | Samsung and LG TV support, Picture-in-Picture |
| OMID 1.6 | Current API, with documentation for Android, JavaScript and iOS |
The same text also says the OM Web Video SDK, released in December 2020, is not backward compatible with the earlier OMID 1.2 web implementation. An answer such as "we use OMID" therefore leaves the version unknown, and the version decides which features a report can rely on.
Example scenario: the newspaper in two environments
Example scenario: the local newspaper sells the same display placement on its site and inside its app. The advertiser sees a viewability gap between the two. The first question is not which side is wrong but which measurement component each environment uses, since the page describes a web video SDK for browsers and separate iOS and Android SDKs for apps.
Booking questions
- Which OM SDK version does each environment run?
- Is the ad served inside a SafeFrame container on the web side?
- Who owns the integration on the app side, the publisher or an ad SDK provider?
The SafeFrame text says a lack of communication about SafeFrame use in header bidding systems made SafeFrame ads harder to support. Practical suggestion: ask the container question explicitly instead of assuming the publisher's setup is known to everyone in the chain.
For CTV app developers, the OM SDK page says a single OM SDK implementation can replace custom integrations with multiple verification providers. Whether a given publisher has done this is not stated on the page, so it stays a question for the publisher.
Working through a report gap
A gap between two reports invites blame. A better first step is elimination. The pages do not explain why any given gap appears, but they show which layers are separate, and that is enough to build an order of checks. Practical suggestion: work through these steps.
- Get both reports' measurement methods in writing. Do both rely on Open Measurement signals?
- Ask in which container the ad was shown. Was it an iframe or SafeFrame on the web?
- For app inventory, confirm the OM SDK integration and platform.
- Compare the OMID versions the providers support. The text lists 1.6 as current.
- If part of the gap remains, ask both providers for their measurement definitions.
Example scenario: The hardware store's two reports differ. The newspaper confirms that the web ad ran in a container and was measured through an OM SDK based provider, while the app used another provider. The question changes from who is wrong to which definitions differ. The store writes one measurement method into the brief for the next campaign. A shared signal structure does not guarantee identical numbers, and the pages make no such claim.
Measurement clauses for brief and booking
If measurement terms are not agreed before the campaign, the end-of-month discussion becomes a method dispute. Four lines in the brief cover the ground. Which provider measures. Whether Open Measurement signals are used. Which platforms are included in the report. How a report gap will be examined. These lines are a conversation draft, not a contract clause. Binding terms need a written agreement with the publisher.
| Line | What to write | Reason |
|---|---|---|
| Provider | Name the company that will measure | The pages name no vendor, so the choice is yours |
| Signal source | State whether Open Measurement signals are used | The standard defines a shared signal structure |
| Platforms | State web, app and connected TV scope | The SDK source names all three |
| Gap review | State that both sides will share method notes | Different methods can produce different results, which is a practical suggestion |
Wrong assumptions to drop
- SafeFrame is not a measurement standard. The article says the measurement feature moved to Open Measurement.
- Open Measurement does not stop invalid traffic by itself. According to the source, it facilitates third-party verification.
- The status of SafeFrame 2.0 in the article reflects the time of writing.
- Vendor choice is a business decision, because the OM SDK page lists no vendors.
- Having the OM SDK on a platform does not mean every provider will report the same result. The page makes no such claim.
All five items mark the edge of what a page says. The safest habit is to attach a question to a source page and a written answer, and to avoid filling the gap between them with assumptions.
Outside the scope
The IAB Tech Lab pages describe what SafeFrame and the OM SDK are, which platforms the SDK covers and which benefits it claims. A tool that checks whether an ad slot uses SafeFrame, the certification status of any named publisher, invalid traffic rates and a comparison of providers are all outside this topic.
How measurement results affect pricing, which body endorses viewability thresholds and how to word a measurement clause in a contract are also outside these pages. For those, use the standards material on viewability and a written agreement with the publisher.
Frequently Asked Questions
What made iframe measurement difficult?
The article says measurement was a black box for ads contained within an iframe before SafeFrame, and that SafeFrame was vital to enabling measurement in iframes at its initial release.
Is SafeFrame still used for measuring?
The article says that as IAB Tech Lab develops Open Measurement for web, SafeFrame no longer needs to offer the measurement feature, so it can concentrate on rich ad experiences.
How is SafeFrame described?
The IAB Tech Lab article describes SafeFrame as an ad container for web display, with MRAID covering mobile. The authors say security was and still is its first priority.
Which signals does the Open Measurement SDK cover?
According to the page, it confirms when ads appear on screen, what percentage is in view and for how long. It facilitates third-party verification of invalid traffic and brand requirements, and Device Attestation addresses device spoofing.
On which platforms does the OM SDK run?
Per the source, it standardizes implementation and signals across mobile apps, web and connected TV. Developer documentation covers Android, iOS and JS, with native SDKs for AndroidTV and tvOS.
Which verification vendor does the OM SDK page recommend?
None. The text names no specific vendors. It refers to measurement providers and verification partners and links to a Transparency Center list of SDK-compliant companies.
Conclusion
SafeFrame and Open Measurement look at two different parts of the same problem. SafeFrame aims at secure, rich ad interaction inside a container. Measurement moved to Open Measurement for web, and the OM SDK ties impressions, viewability, invalid traffic verification and device authenticity to a shared signal structure. As an advertiser, ask which container the ad ran in and whether measurement used Open Measurement, and ask in writing.
As a publisher, state your OM SDK integration, platform and certification status plainly in your booking form. A local newspaper with a website and an app can then answer the report-gap question quickly, because both sides are answering the same questions. Record the date you read each page.
Keep the evidence trail short and dated. A written answer about the container, a written answer about the OM SDK and its platform, the measurement provider's method notes and the date you read each IAB Tech Lab page are enough to open any later discussion with facts. The SafeFrame article describes a standard in public comment at the time of writing, and the OM SDK page lists OMID 1.6 as current as of its November 4, 2025 update. Date each note before it goes into a new contract or campaign.
Once your measurement questions are settled, compare placement options on Akua Adforce ad spaces.
Post a comment
Please log in to leave a comment. Login