Viewable Impressions And iFrames: Protecting Your Blind Side

"Data Driven Thinking" is written by members of the media community and contains fresh ideas on the digital revolution in media. Today's column is written by Mark Hughes, CEO of C3 Metrics.

It was a Michael Lewis book before it was a Sandra Bullock movie. Published in 2006, "The Blind Side" stated very elegantly what most football strategists had already begun to figure out. If your most important player in the game (quarterback) gets injured, you can kiss success goodbye.

Internet strategists have begun to see the same thing and taking steps to protect their most valuable asset. For DSPs and networks, it’s their intelligence, their targeting techniques, their day-parting, and their science. For advertisers, it’s their budgets. But the common denominator that hangs a huge question mark around both is their blind side, an issue the industry is attempting to solve with viewable impression standards. We estimate 68% or more of display ads are never seen by consumers, and initiatives like the cross-industry Making Measurement Make Sense coalition are hoping to eliminate the blind side and create a more efficient marketplace.

The proverbial Internet quarterback is the RTB platform. Despite all the infrastructure and real-time intelligence within RTB, if the blind side of viewable impressions isn’t covered, it knocks the wind out of increasing revenue for everyone using these display inventory platforms.

Despite the strides the IAB, ANA and 4A’s are making around viewable impressions, there is another hidden blind side. It’s this:  approximately 80% of display ads are delivered via iFrame (the remaining 20% are delivered with JavaScript).  Most leaders in viewable impressions have cracked the code on JavaScript.  The data coming from the JavaScript side of viewable impressions is exciting, but it’s less than a quarter of the problem at hand. Solving viewability with iFrames is a lot like breathing under water -- humans can’t do it without a special apparatus. In the case of iFrames that apparatus is very hard to build.

The challenge with iFrames, specifically iFrames that come from a different domain delivering ads, is that the viewable impression code within the iFrame is not able to access the publisher page due to the “Same Origin Policy."

As Mozilla defines it (dating back to the grandfathers of browsers Netscape Navigator 2.0):  "The same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from another origin."

Essentially the authors of the same origin policy wanted to prevent the loss of data confidentiality or integrity with strict separation between content provided by unrelated sites.  This permits scripts running on pages originating from the same site to access each other's methods and properties with no specific restrictions, but prevents access to most methods and properties across pages on different sites.

This is why the blind side of cross-domain iFrames is so difficult, and why it is one of the most common questions asked on Stack Overflow.

Several workarounds to access properties of the publisher page are possible, but all require the participation of the publisher, which presents additional compliance issues.  It’s a difficult problem.

So viewability must be solved both in the U.S. and E.U. for the full 100% of display ads served. As an industry, we won’t see a win until we seal the blind side, solving viewability in both JavaScript and iFrame.

Follow C3 Metrics (@c3metrics), Mark Hughes (@buzzmark) and AdExchanger.com (@adexchanger) on Twitter.

3 Comments

  1. I agree with your conclusion: "As an industry, we won’t see a win until we seal the blind side, solving viewability in both JavaScript and iFrame.".
    I allthemore agree because Alenty has solved this issue.
    Alenty's cross-domain iframes measurement does not require that publishers install any script or be involved anyhow.
    It can be directly configured in adservers and DSPs.
    On adexchanges, where most ads are in cross-domain iFrames, we usually successfully measure more than 98% of impressions.
    As Alenty ad-visibility is an Appnexus app now, you can easily verify this yourself.
    So, yes "viewability in both Javascript and iFrame is now solved".

    Reply
  2. As a Publisher our major concern is not how do we count if the ad is viewable, the issue, rather, is the impact on back-of-office process that rely upon accurate delivery data to report yield and performance analysis and to build inventory forecasting models that actually work. Unless this is achieved in a single process we are doomed to inject yet another 3rd party system to manage a process that should easily be achievable from the adserver itself.

    The issue here should not be about having to plug yet another 3rd party tag into every ad we deliver but instead for the adservers to have native support themselves. It's all well and good counting ad-delivery down the road after any daisy chaining that may occur on the RTB side. But as a publisher we need to get to see those numbers reflected in the adserver (not another unrelated site) as it is the adserver that is responsible for inventory forecasting. This needs to be achieved without relying on additional 3rd party calls which introduce lag, delay and, of course, their own counting issues.

    Adserving in the digital landscape is complex enough, we should be finding ways to simplify these processes not inject additional systems and potential failure points, we need to be more demanding of our technology providers and require that such features are built-in rather than relying upon additional 3rd parties. So, if you're going through an RFP for an adserver at the moment ensure that Viewable Impressions is supported as part of the base package or at the least due for release in the next 3-6 months.

    Reply
  3. Greg Hills

    Ad tech has a somewhat deserved reputation as a noisy marketplace with a lot of smoke and mirrors. Succinct, comprehensive articles that give just due to the technical complexities behind the actual products are a great step forward. Nice job, Mark.

    Reply

Add a comment

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>