/

Browse the help center

Video viewability and Open Measurement (OMID)

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.

Concept network manager admin Account → Publishers → site → zone → placement (Video) → VAST tracking → Viewability & other

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.

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 <ViewableImpression> 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.

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 `<Verification>` — but their pixel can ride along; see What this does not do.

What the player actually receives

On a VAST 4.1+ response, Epom adds one <AdVerifications> block alongside the creative:

<AdVerifications>
  <Verification vendor="epom.com-omid">
    <JavaScriptResource apiFramework="omid" browserOptional="true">
      <![CDATA[https://cdn.example.com/js/omid.js]]>
    </JavaScriptResource>
    <TrackingEvents>
      <Tracking event="verificationNotExecuted">
        <![CDATA[https://<ad-serving-domain>/at?subId=…]]>
      </Tracking>
    </TrackingEvents>
    <VerificationParameters>
      <![CDATA[{"viewable":["https://<ad-serving-domain>/at?subId=…"],
                "notViewable":["https://<ad-serving-domain>/at?subId=…"],
                "thresholdPercent":50,"durationMillis":2000}]]>
    </VerificationParameters>
  </Verification>
</AdVerifications>

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).

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 <ViewableImpression> 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, 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 <ViewableImpression> 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:

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.
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.
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), 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 <AdVerifications> 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 <ViewableImpression> at any version. That element goes only to Epom’s own video ad manager. So a third-party player that reads <ViewableImpression> 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).

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. <ViewableImpression> 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 <ViewableImpression> 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) 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 <Verification> 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 <Verification>, 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.
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.

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 — `<ViewableImpression>` 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:

Fetch the tag URL directly and confirm the response contains <AdVerifications> with a <VerificationParameters> block. No block means either the version is below 4.1 or nothing is wired to any viewability event.
Read the version off the response, not off the URL. Every VAST response opens with it, as the root element’s attribute — <VAST version="4.2" …>. 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.
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.

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 that match it. So the recipe is “track viewability, then hang a piggyback on the viewability action”.

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). 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.
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.
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 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.