--- title: "Video viewability and Open Measurement (OMID)" description: "How Epom measures video viewability on third-party players through IAB Open Measurement — what the player receives, what counts as viewable, where the numbers land, the versions and inventory it does not cover, and how to fire a third-party pixel when a banner becomes viewable." type: "concept" audience: [network-manager, admin] keywords: [viewability, Open Measurement, OMID, OM SDK, AdVerifications, VerificationParameters, verification script, MRC, viewable impression, repeated viewable, not viewable, view undetermined, VAST 4.1, VAST 4.2, IMA, measurable, viewable pixel, fire on viewability, third-party pixel on view, viewability piggyback, display viewability, fire code when viewable] ui_path: "Account → Publishers → site → zone → placement (Video) → VAST tracking → Viewability & other" --- Fetch the complete documentation index at: https://epom.com/ad-server/docs/llms.txt. Use this file to discover all available pages before exploring further. Append .md to any documentation page URL to get its markdown version. # Video viewability and Open Measurement (OMID) An impression that was served is not the same as an impression that was *seen*. **Viewability** is the measurement of the difference, and for video the industry settled on one mechanism: **IAB Open Measurement**, usually shortened to **OMID** (Open Measurement Interface Definition). Epom measures video viewability itself. It does not resell a third-party measurement vendor and it does not need one installed. From **VAST 4.1 upward**, the ad server attaches a small verification script to the VAST response; an Open Measurement–capable player (Google IMA and the other major SDKs) runs it in its verification frame, the script watches how much of the ad is actually on screen, and it fires the viewability trackers you already wired on the placement's or the banner's [VAST tracking card](https://epom.com/ad-server/docs/guides/inventory/placement-video.md#vast-tracking-card). **Which player family you are in decides everything else on this page.** A VAST tag pasted into *your own* player — Google IMA, an SDK, any third-party player — is the family Open Measurement is for. The **VPAID tag** is the other family: it loads Epom's own video ad manager, which measures viewability itself from VAST's `` element and never loads the verification script. Exactly one mechanism goes out per response, chosen by which player asked, so nothing is double-counted — but the two are not equivalent, and the differences are in [What this does not do](#what-this-does-not-do). The short answers, before the detail: | Question | Answer | |---|---| | Do you support OMID? | Yes, as the **measurement provider** — Epom serves its own verification script. | | Do I have to install anything? | No. It is on by default and needs no keys, no vendor account, no contract. | | What do I have to do? | Serve a **VAST 4.1 or higher** tag *into a player that implements Open Measurement*, and wire at least one viewability event. | | Where do I read the numbers? | In your normal reports, as conversion actions — there is no new report to learn. | | Can I attach *my* verification vendor (IAS, DoubleVerify, Moat)? | Not as a `` — but their pixel can ride along; see [What this does not do](#what-this-does-not-do). | ## What the player actually receives On a VAST 4.1+ response, Epom adds one `` block alongside the creative: ```xml /at?subId=…]]> /at?subId=…"], "notViewable":["https:///at?subId=…"], "thresholdPercent":50,"durationMillis":2000}]]> ``` Three things are worth pointing out to a partner who asks to see this: - **`vendor` is a label, not a credential.** It identifies Epom as the measurement vendor to the player and to anyone reading the tag. It is not a key, nothing has to be registered against it, and changing it does not change what is measured. - **`VerificationParameters` carries whatever is wired to each viewability event.** For a ticked event that is an ordinary Epom tracking URL (`/at?subId=…`) — the very same one the event would fire by any other route, which is what keeps one number per event no matter which player served the ad. A **third-party pixel** whose *Fires on* is a viewability event lands in the same lists, verbatim and unchanged, so a partner reading the tag may legitimately find a vendor's host in there next to ours. Both routes feed the same list; the script fires everything it is given. - **The script is served from your CDN domain** when the network has one configured, not necessarily from the ad-serving domain. A vendor auditing the tag will see the CDN host. ## What counts as "viewable" The script applies the **MRC video criterion**: at least **50% of the ad area on screen for 2 continuous seconds**. Continuous, not cumulative — the clock restarts if the ad scrolls out of view before the two seconds are up. Both numbers are the defaults; Epom support or your account manager can change them network-wide (see [Network-wide settings](#network-wide-settings)). Four events come out of this. In the **new interface** they are the four grouped under **Viewability & other** on the VAST tracking card; on the **classic** placement page the same four are plain checkboxes in the flat **Vast events** panel, which is ungrouped and lists every VAST event together. | Event | Fired when | Fired by | |---|---|---| | **Ad viewable impression** | The first stretch that meets 50% for 2 continuous seconds | The verification script | | **Ad repeated viewable impression** | Every *later* qualifying stretch in the same playback | The verification script — **only** on the Open Measurement path | | **Ad not viewable impression** | Playback ended and the criterion was never met | The verification script | | **Ad view undetermined impression** | The verification code never ran at all | **The player**, not the script | The last one is deliberately different. A script that never loaded cannot report that it never loaded, so that event rides in the response as a standard `verificationNotExecuted` tracker and the player fires it. It is your signal for "this player could not be measured", as distinct from "this ad was measured and was not seen". > **Note: repeated viewable exists only on the Open Measurement path.** VAST's own > `` element has containers for viewable, not-viewable and undetermined — > there has never been one for a *repeat*. Open Measurement is the first mechanism that can report > repeat viewability at all, and the flip side is that Epom's own video ad manager can never > report it: with no container to carry the tracker, it is resolved and then dropped. Tick the > event on a VPAID-served placement and the column stays at zero. ## Where the numbers land Each viewability event is wired to a **[conversion action](https://epom.com/ad-server/docs/guides/conversions/conversion-actions.md)**, so viewability lands in ordinary Epom reporting rather than in a separate viewability console. In the **new interface**'s report builder, **Split columns by → Viewability** picks and orders that family of actions for you. The column headings are shorter than the event names you ticked, so match them by position: *Ad viewable impression* → **Viewable**, *Ad repeated viewable impression* → **Repeated viewable**, *Ad not viewable impression* → **Not viewable**, *Ad view undetermined impression* → **Undetermined**. That shortening is applied to the seeded actions only, and only in the new interface — the classic reports and any action you renamed yourself show the action's own name (*AD VIEWABLE IMPRESSION-GLOBAL* and so on). Both mechanisms resolve the **same** tracker URLs, so the three events that exist in both — viewable, not viewable, view undetermined — are one number across both player families rather than two columns to add up. Repeated viewable is the exception: it has no `` container, so it can only ever be reported through Open Measurement. > **Note:** these are *system* actions, and they do not count in the **Conversions** column of the > General report (or of the Advanced report), so a video impression does not inflate it by the > number of events it fired. Read them > through **Split columns by → Viewability** or by grouping on **Action**; the money they carry is > unchanged and still lands in Gross and Net. ## Turning it on There is no OMID switch, and nothing in the interface says the word. Two things have to be true on your side, and one on the player's: 1. **The tag has to be VAST 4.1 or higher.** In the **new interface**, on the placement's **Ad Tags & API → VAST Tags** tab, the **VAST version** picker defaults to **4.2**, so a freshly copied tag already qualifies; pick a lower version and the response carries no measurement at all. The picker exists only there — the **classic** placement page offers fixed **VAST 3.0**, **VAST 4.0**, **VPAID** and **VMAP** rows and cannot reach 4.1 at all, so a measurable tag has to be copied from the new interface. 2. **At least one viewability event has to have something wired to it**, on the placement or on the banner. Either a ticked event — under **Viewability & other** on the new interface's **VAST tracking** card, or in the flat **Vast events** panel on the classic page — or a **third-party pixel** whose *Fires on* is one of the viewability events. With nothing wired at all, the block is not emitted: Epom will not load a measurement script that has nowhere to report to. See [Video placements](https://epom.com/ad-server/docs/guides/inventory/placement-video.md#vast-tracking-card). 3. **The player has to implement Open Measurement.** This one is not a setting in Epom — it is a property of the player you paste the tag into. The major SDKs (Google IMA and friends) do it; a plain HTML5 VAST player generally does not. Nothing breaks when it does not (see [When a player supports nothing](#when-a-player-supports-nothing)), but there is no viewability. All three are needed, and none substitutes for another. A 4.2 tag with nothing wired measures nothing; a fully configured tracking card on a 3.0 tag measures nothing; and either of those in a player without Open Measurement measures nothing whatever you do to the tag. > **Corner case:** where the same event is enabled on **both** the placement and the banner, the > **placement's** action wins — the values are not merged. A publisher's placement-level setting > therefore overrides an advertiser's banner-level one for that event. ## What this does not do This is the half that prevents support tickets, so it is deliberately blunt. - **Viewability needs VAST 4.1+ *and* an Open Measurement–capable player — both, never either.** 4.1 is the version floor: VAST 4.0 has an `` element, but its pre-OMID shape cannot carry the script's configuration, so there is nothing to hand it. Raising a 3.0 or 4.0 tag to 4.1+ is a copy-paste of a new tag URL, and it is the fix **only if the player implements Open Measurement**. In a player that does not, the tag version makes no difference at all. - **While Open Measurement is enabled, a third-party player receives no `` at any version.** That element goes only to Epom's own video ad manager. So a third-party player that reads `` and does not implement Open Measurement reports **no viewability**, and raising the tag version does not change that. The two routes to it are a player that implements Open Measurement, or asking Epom support or your account manager to switch Open Measurement off network-wide, which sends the element to every player again (see [Network-wide settings](#network-wide-settings)). The platform does not record which players read the element, so check your own players rather than assuming they are unaffected. - **On Epom's own video ad manager, *Ad repeated viewable impression* is not supported.** `` has no container for a repeat, so do not rely on that event on a VPAID-served placement — its report column stays at zero there. - **The classic placement page cannot reach it at all.** That page still shows fixed **VAST 3.0**, **VAST 4.0**, **VPAID** and **VMAP** rows, all of them below the 4.1 floor. To get a measurable tag you must copy it from the new interface's VAST Tags tab. - **VMAP is never measured.** The VAST breaks a VMAP playlist schedules are pinned to VAST 3.0, so a VMAP integration gets no viewability by either mechanism. - **VPAID tags are never measured by Open Measurement.** The VPAID tag does not follow the version picker — its version is fixed on the server, below the 4.1 floor. It is also the tag that loads Epom's own video ad manager, so it is measured by the other mechanism instead: the ad manager's follow-up request inherits the VPAID tag's version, and `` needs 4.0. Which version you get depends on how the tag was produced, not on which interface produced it: the VPAID row is generated at **4.0**, which clears that bar, but the refresh that runs when a serving **Domain** is selected returns the tag at **3.0**, which does not. Both interfaces behave the same way, so read the version off a copied VPAID tag's response (see [Checking that it works](#checking-that-it-works)) before assuming it is measured at all. - **Programmatic (OpenRTB) video is not measured by Epom.** For a bid won by a DSP, Epom passes the DSP's own VAST through and adds no verification of its own. Whatever verification that creative carries is the buyer's, not ours. - **Only one `` is ever emitted, and it is Epom's.** There is no pass-through that puts a buyer's or publisher's own vendor (IAS, DoubleVerify, Moat) into the block as a second ``, even though VAST allows several. What a vendor *can* have is a pixel: attach their measurement URL to a viewability event as a **third-party pixel** on the VAST tracking card, and it travels inside `VerificationParameters` and is fired by Epom's script from inside the player's verification frame. That is the supported route, and it should be tried before the fallback of carrying the vendor's own tag inside the creative markup. What it does not give the vendor is their own script running in the frame — only their URL being called. - **Buyers cannot discover this in the bid request.** Epom does not advertise Open Measurement support to DSPs in OpenRTB. Support is a property of the tags you serve, not something a bidder can detect. - **A tag URL with no `vastv` parameter serves VAST 2.0**, and therefore no viewability — which bites hand-written and truncated URLs. Do not use a visible `vastv` as your test, though: on networks that serve **encrypted tag URLs**, the whole path and query are wrapped into ciphertext behind a decrypter endpoint, so no `vastv` is visible even though the tag carries one. Read the version off the response instead — see [Checking that it works](#checking-that-it-works). - **It measures the ad, not the audience.** Viewability says the pixels were on screen. It says nothing about attention, and it is not fraud detection — for that see [invalid traffic](https://epom.com/ad-server/docs/concepts/invalid-traffic-and-risk-scoring.md). ## When a player supports nothing Nothing breaks. The script polls briefly for the Open Measurement API and, if the player does not provide one, exits silently — no error to the publisher, no error in the player, and the response is otherwise unchanged. A non-OM player simply produces no viewability data, exactly as before. ## Network-wide settings Open Measurement is **on by default and needs no configuration**. A few server-side settings tune it **network-wide**; there is no interface for them, so ask Epom support or your account manager to change one: | Setting | Default | What it does | |---|---|---| | Open Measurement on/off | On | Master switch. Turning it **off** restores the previous behaviour — `` for every player on VAST 4.0+ — rather than removing viewability altogether. | | Verification script location | Your network's serving domain (or its CDN) | Where the verification script is served from. | | Vendor string | `epom.com-omid` | The `vendor` string advertised in the tag. Cosmetic — measurement does not depend on it. | | Viewable area | 50% | Percent of the ad area that must be on screen. | | Viewable duration | 2 seconds | How long, continuously, the threshold must hold. | The last two are the MRC video criterion. They are network-wide: one publisher cannot be measured against a different threshold from another. ## Checking that it works Viewability trackers fire from **inside the player's verification frame**, so they will not show up in your page's browser dev tools the way an ordinary pixel does. To confirm an integration: 1. Fetch the tag URL directly and confirm the response contains `` with a `` block. No block means either the version is below 4.1 or nothing is wired to any viewability event. 2. **Read the version off the response, not off the URL.** Every VAST response opens with it, as the root element's attribute — ``. It must be 4.1 or higher. The tag URL's `vastv` parameter says the same thing when it is visible, but on networks that serve encrypted tag URLs there is no query string in the tag to read, and an absent `vastv` there does *not* mean 2.0. 3. Play the ad in the real player and check the viewability actions in your reports rather than in the browser console. If the response looks right but the numbers stay at zero, the player is the next suspect: see [Diagnose video ad playback failures](https://epom.com/ad-server/docs/troubleshooting/vast-errors-and-playback.md). ## Fire a third-party pixel when a banner becomes viewable Measuring viewability and *acting on* it are different jobs. When a partner wants their own pixel or URL called the moment an ad is seen, you do not need a new feature: every viewability event — display and video alike — is recorded as a **system conversion action**, and a recorded conversion fires the [piggybacks](https://epom.com/ad-server/docs/guides/conversions/piggybacks.md) that match it. So the recipe is "track viewability, then hang a piggyback on the viewability action". 1. **Turn viewability tracking on.** - **Display banner:** on the banner, open **Advanced settings** and tick **Enable viewability tracking (beta)**. It is offered on Site and Non-standard placements only, and only to a role holding the *Banner View Tracking* permission (see [Image banners](https://epom.com/ad-server/docs/guides/advertising/banner-image.md)). The ad server then appends a small script to the banner's markup that reports **Ad viewable impression** the first time at least 50% of the banner stays on screen for one continuous second, and **Ad repeated viewable impression** each later time it does. - **Video:** wire the viewability events as described in [Turning it on](#turning-it-on). 2. **Add a piggyback** on the campaign, the site or the placement (**Piggybacks** card → **Add**): - **Type** — **URL (server-side)**. See the warning below for JS. - The partner's URL. Macros work; `$$ATTRIBUTION_TYPE$$` resolves to `system` here. - **Conversion action** — the viewability action. In the picker it is listed under its seeded name, after the account's own actions: **AD VIEWABLE IMPRESSION-GLOBAL (id: N)**. Pick **AD REPEATED VIEWABLE IMPRESSION-GLOBAL** as well only if the partner wants a call on every re-view rather than once per impression. - **Fire for** — **All conversions**. A viewability conversion is classified *System*, and *Post-click only* or *Post-view only* rows never receive it. 3. **Save**, and allow for the ad server's piggyback cache reload (every ten minutes by default) before testing. > **Warning:** only **URL (server-side)** piggybacks fire on a viewability event. A **JS code > (client-side)** row matches and is sampled, but its markup is only handed out to a caller that > asks for it, and the viewability trackers are plain image requests (display) or player-fired > tracking URLs (video) that never do — so the tag never runs. If the partner insists on a hit > from the visitor's browser, use a **third-party pixel** on the [VAST tracking > card](https://epom.com/ad-server/docs/guides/inventory/placement-video.md#vast-tracking-card) for video; for display there is > no client-side route. > **Corner case:** a piggyback whose **Conversion action** is **All** fires on system actions too — > on every viewability event and, for video, every quartile and player event the placement tracks. > A conversion partner on an *All* row will start receiving viewability hits the day viewability > tracking is switched on. Scope such rows to the real conversion action. **To check it works:** serve the banner on a test page and scroll it into view for over a second. For display the beacon is an ordinary request from the page, so the browser's network panel shows a call to `/at?subId=…`. The viewability action then appears in a report grouped by **Action**, and the partner should see the server-side call. A piggyback's sampling, fraud and duplicate rules apply exactly as for any conversion; see [Piggyback pixels](https://epom.com/ad-server/docs/guides/conversions/piggybacks.md). ## Related - [VAST vs VPAID: video ad tags explained](https://epom.com/ad-server/docs/concepts/video-vast-vpaid-explained.md) - [Video placements](https://epom.com/ad-server/docs/guides/inventory/placement-video.md) - [Video banners](https://epom.com/ad-server/docs/guides/advertising/banner-video.md) - [Ad tags, invocation codes and the API](https://epom.com/ad-server/docs/guides/inventory/ad-tags-and-api.md) - [Conversion actions](https://epom.com/ad-server/docs/guides/conversions/conversion-actions.md) - [Piggyback pixels](https://epom.com/ad-server/docs/guides/conversions/piggybacks.md) - [Run an awareness campaign with frequency control](https://epom.com/ad-server/docs/use-cases/branding-reach-frequency.md) - [Diagnose video ad playback failures (VAST errors)](https://epom.com/ad-server/docs/troubleshooting/vast-errors-and-playback.md)