Viewability and its companion exposure time are becoming more and more default metrics and measurements for online media campaigns. But ever since, I’ve heard quite some times that the measurement of viewability is a real pain in the ass, and a pain in the ass for multiple reasons.

Sometimes it was about the high CPM – 12c CPM is no exception. Sometimes it was about agreeing on a standard – according to MRC, an impression is viewable when it has been 50% in view for at leat 1s. But it also was about the huge amount of impressions that could not be measured because of technical difficulties. As a technical optimist, this surprised me. How hard could it be for those big vendors to just fix this?

So, I was really curious what the real challenge was with measuring viewability, so I decided to take a deep dive into viewability measuring and started writing my own viewability tracker. Along the way, I ran into quite some surprises, ‘WTF’-moments, challenges and different methods to measure viewability.

Because of all these different methods, there are quite some discrepancies when comparing data of various viewability measurement vendors. No wonder, viewability tracking is another mobile headache for publishers. But as you will know by the end of this post, the future looks very bright. For now, let’s start with the past.

Browser Optimisation method

When I first found out about this approach, I was flabbergasted. Was this really the method that the fancy, innovative online world was used to detect a viewable impression? Turns out it was. The Browser Optimisation method refers to a method where we ‘abuse’ browser optimisation features to detect if an HTML element (ad) is visible.

Without getting too technical, let me try to explain how this works. Every animation on a screen consists of a number consecutive images. Frame rate (expressed in frames per second or FPS) is the frequency (rate) at which those consecutive images called frames are displayed in an animated display. Ideally, the FPS in web animations is 60. Playing these animations use resources from a computer, and therefore most browser vendors have built in an optimization that stops the animation as soon as it leaves the screen (‘below the fold’), so they can use resources for things that are actually visible. So animations that run outside of the user’s viewport, will have a framerate of 0, meaning that it’s not animating at all.

This is exactly the method viewability vendors have used to measure viewability. When this was the way to go, Flash was still pretty much everywhere. So what they did, even when the served ad was in HTML, was adding a ton of little, invisible Flash elements of 1 by 1 pixels to the creative. One in every corner of the creative, and most of the times even one in the middle of all the y and x axises and in the center of the creative to be able to also measure the 50% in-view impressions. All these Flash elements did only one thing: measuring the framerate, and by doing so, measuring whether it’s in view or not.

With the growth of mobile inventory and as the Adobe Flash plugin was starting to disappear from computers, the ‘Browser Optimisation’ method using Flash also got more useless and vendors started moving away from this approach.

The JavaScript Throttle rendering pipeline approach

Certain browsers have released an optimization for HTML5 content that works very similar to the Flash optimization. It’s called Throttle rendering pipeline based on viewport visibility. It doesn’t work with a collection of Flash elements, obviously, but relies on JavaScript’s requestAnimationFrame. This is currently live for Safari version 9+, Firefox and Chrome version 52+. A huge advantage of this method is that it also works on mobile. On mobile, AppNexus moved from measuring 50% of mobile web traffic to 93% after switching to from Flash to JavaScript browser optimization method.

The Geometric Method

With this approach, one uses the geometric values of an ad to determine whether it’s in view or not. It measures the position of the ad relative to the browser viewport (the canvas of a browser).

This approach works great as long the creative, or the tag that tracks the viewability is served in a friendly IFrame of outside an IFrame at all. A Friendly IFrame is an IFrame that shares the same domain as the main page it is hosted on. When the creative is served in an unfriendly IFrame, it can not read the document of the publisher’s page and therefore it can’t read the geometric values of the element that contains the creative.

In the tests we’ve run, we see a fair amount of ad impressions served in unfriendly ("cross-domain") iframes. And this is not much of a surprise when you know that when serving a creative outside an unfriendly iframe, the creative can ‘break out’ of the IFrame and manipulate the content on the publisher’s page, or worse, read the credentials from visitors. When I first started out in the media world, I was surprised by the amount of trust that is involved in the relationship between publishers and advertisers. Luckily, nowadays most DSPs and ad servers have algorithms that can track down creatives that contain malicious code.

When the geometric method can be applied, it turns out to be very accurate. I also wrote a post on how to create a basic viewability tracker using the geometric method, so if you’re interested in the details of this approach, you might want to check that post out.

IAB SafeFrame

According to IAB, ‘SafeFrame technology is a managed API-enabled iframe that opens a line of communication between the publisher page content and the iframe-contained external content, such as ads’. This communication happens in a specific format, so the publisher only needs to give the creative the data and options it really needs, and thus this creates a controlled flow of data. SafeFrame is used for rich interaction, such as ad expansion, but it can also send viewability data from the publisher’s site to the ad. Under the hood, it’s using the JavaScript window.postMessage() API (docs) for communication. In our tests, we haven’t seen a lot of SafeFrame creatives in the wild.

The solid, new approach: IntersectionObserver API

Recently, a new API was released that’s going to change everything: the Intersection Observer API. According to the documentation,

the Intersection Observer API provides a way to asynchronously observe changes in the intersection of a target element with an ancestor element or with a top-level document’s viewport.

Bingo. That’s exactly what we need. To the Intersection ObServer API it doesn’t matter if your ad in nested 88 Iframes deep, it just checks if the ad intersects with the visitor’s viewport and to what extend. Easy as that. The code to measure viewability of an element looks like this:

// Function that is called every time the viewability of a tracked element changes
  var trackIntersectionObserver = function(entries, observer) {
      var inViewPercentage = entries[0].intersectionRatio;
      // Do whatever you want with the percentage
  }

  var options = {
      rootBounds: null,
      threshold: [1, 0, .50], // Only track changes between 0%, 50%, 100% in-view
      root: null
  }

  var observer = new IntersectionObserver(trackIntersectionObserver, options);
  // Start tracking your element
  observer.observe(document.querySelector('#your-element'));
  

I believe that this API is really going to make a change (it already has!) and I think for advertisers and publishers, this new API should reduce the discrepancies between various viewability measurement vendors.

In-app viewability

Most apps are created in programming languages other than the one used on the web (JavaScript), for example, Swift (iOS) or Java (Android). All methods discussed above rely on JavaScript, and therefore will not work with in-app ads. Luckily, there’s an API called MRAID that allows communication between the app and the ad.

MRAID 2.0 has support for reading the viewability of an ad, but it does not support measuring what percentage of the ad is exactly in view. Therefore, MRAID 2.0 does not give you the tools to meet the MRC guidelines.

The only way to get the in-view percentage of an ad when in-app, is using specific viewability trackers SDKs, like MOAT‘s, but not all publishers have installed these SDKs.

But there’s some good news here as well. As also discussed in our post on the new features in MRAID 3.0, with MRAID 3.0 it’s possible to track what percentage of the ad is viewable. By this new feature, the MRAID viewability measurement completely meets the criteria of the MRC guidelines for tracking in-app viewability. In another upcoming post, we’ll get into the technical specifics of tracking viewability with MRAID 3.0. With version 3.0, advertisers will no longer be dependent on publishers with specific viewability trackers SDK’s, like MOAT.

Final note

Measuring ad viewability has been a pain in the bum for both advertisers, publishers and viewability vendors for years now, but with the new Intersection Observer API and upcoming MRAID 3.0, the future looks very bright! I don’t think those specialized viewability vendors like MOAT will disappear because of these developments, as they still have a good position when it comes to tracking viewability with walled gardens like YouTube, and collecting the data is not the only thing they do (think of reporting, scalability etc).

I have no connection with people working at viewability vendors, so all findings are based on my own research. If you aware of other ways to measure viewability, please drop me a line in the comments below.