Forget Viewability: Your Ads Aren’t Serving

"Brand Aware” explores the data-driven digital ad ecosystem from the marketer's point of view.

Today's column is written by Bennett Rosenblatt, rider display marketing lead at Uber.

At Uber, our programmatic strategy prioritizes transparency and trust above all. We run campaigns in an enterprise self-service demand-side platform (DSP) and leverage a transparent ad server to build engaging creative and provide unique measurement capabilities. We’ve built deep relationships with the largest exchanges, data providers and mobile technology companies.

Programmatic display is among the most strategic channels for Uber moving forward, which was definitely not true a few years ago. As our internal sophistication grows, so too do our tools. One such evolution is our creative. Flat image files have given way to rich, dynamic, interactive experiences.

But as we traveled deeper into the world of rich creative, we discovered a massive problem in the ecosystem. When it comes to creative compatibility, the programmatic exchanges are not taking their responsibility to advertisers seriously. Ultimately, we found that some exchanges don’t run simple compatibility checks on their publishers and trust them to self-report accurately in the face of an obvious counterincentive: higher CPMs.

An Ad Tech ‘Whodunit’

In late Q4, we launched a series of small rich-media-based mobile brand campaigns to dip our toes in the water and establish performance benchmarks. We ran the tests for a few days then reviewed the data. This health check uncovered some odd trends.

First, our click-through rates were almost zero. For in-app static 300x250s with impression and click trackers, we could sometimes see as high as 2% click-through rates (CTRs). But exciting, motion-enabled, dynamic ads were generating sub-0.10% CTRs. It just didn’t make sense. On top of that, incrementality was completely flat across various short-term metrics.

Something was wrong. We were buying significant inventory across well-known, major exchanges, but it was as if our ads weren’t being served at all.

It’s important at this point to emphasize the distinction between a few key terms. First is the load rate, which is the ratio of rendered impressions – the number of ads that are served – over requested impressions, or the number of impressions won in auctions.

Most of us will agree that there are unavoidable cases, through no fault of the exchange, DSP or ad server, where an ad fails to load. The user, for example, closed a web page too quickly. Or the user went to the next level in a favorite app before the interstitial loaded. There are so many moving parts when it comes to programmatic advertising that this is just something you have to accept.

But for these small branding campaigns we tested, we were shocked to learn the load rate was 50%. A load rate of 50% means that of 1 million impressions we won and paid for, only 500,000 were served.

Thus began our “whodunit.” Where was the breakage? Which party was responsible?

When we looked at the logs in our ad server, which is the technology that handles our creative and tracks our load rate, we saw several errors. This was the most common error: “MRAID Object Doesn’t Exist.”

This error happens when the DSP tries to stuff an MRAID (mobile rich-media ad interface definitions) creative into a non-MRAID-compatible impression. In this case, either the DSP is at fault for buying “MRAID=0” placements, or the supply-side platform (SSP) is at fault for allowing non-MRAID inventory to declare as “MRAID=1.”

Our investigation ruled out the DSPs, and we determined that the issue existed on the SSP side. But to this point, the SSPs had completely resisted the idea that they were responsible.

Our hypothesis was that some exchanges were not performing basic validation of their inventory for things like MRAID compliance. We confirmed this hypothesis when multiple exchanges told us that they rely on publishers to self-declare MRAID compliance. There’s a clear and obvious reason that publishers might be incentivized to declare as MRAID-compliant: higher CPMs. In at least one case, an exchange asked us to provide our ad server logs so it could identify bad actors.

There appeared to be no prior awareness by SSPs of the issue.

Sounding The Alarm

I’m writing about this issue for four major reasons.

First, programmatic advertisers must educate themselves about load rates. The most basic assumption you can make – “my ads are being served” – is surprisingly flimsy. You might be shocked at how much of your budget is being wasted in an almost untraceable way and how hard certain parties will fight to hide that information.

Second, viewability has created a false sense of security among advertisers and has, in some ways, hidden this problem. The viewability pixel only fires when an impression is rendered, and viewability measurement doesn’t work in the majority of mobile environments. Ninety-percent viewability doesn’t sound as good when 50% of impressions weren’t served in the first place.

Third, transparency is key. Our team would have never realized the scale of this problem if we didn’t work with an ad server that transparently reported load rates and a DSP that acts as a genuine trusted adviser on our behalf. I was surprised to learn while writing this column that many of the top ad servers don’t report the percentage of ads they successfully served. That’s absurd to me.

If I have learned one thing over the past quarter, it is that exchanges are not monitoring their own inventory for basic issues like MRAID compatibility. Load rates are a much bigger problem than people realize, and if we didn’t have partners that prioritize transparency, we would have never found this issue.

Finally, I want to sound the alarms that major exchanges are not taking their duty to advertisers seriously. We are completely pulling our spend from multiple exchanges until they address this problem, and we are doubling down on those exchanges that proactively take steps to validate their inventory. MRAID compatibility is just one symptom of a much larger issue and underscores the need for exchanges to take accountability so that advertisers can get what they pay for.

Follow Uber (@Uber) and AdExchanger (@adexchanger) on Twitter.

 

8 Comments

  1. Jonathan Bouman

    Wouldn't working with an IAS or DV to block any non-complaint ad impressions solve this issue?

    Reply
  2. At Uber, our programmatic strategy prioritizes transparency and trust above all. This is counter the programmatic where 50% of ads are not seen by human and the trouble only starts there. Would love to know what KPI those who provide the budget are looking at to justify programmatic campaign when other channels with huge scale and less issue exist.

    Reply
  3. Good info, thanks for sharing. We smaller players will have to rely on big brands with big $ to catch, report and pull spend from offending SSPS (I wish you'd name names!) to make an impact.
    The info on CTRs doesn't really make sense in the end still. I assume you're saying CTR data reporting from your DSP is based on a formula of =clicks/requested-impressions, and in reality it should be =clicks/rendered-impressions? Even then your correct CTR would still be less than 0.2% (not that that sounds unreasonable to me for banner ads, "exciting, motion-enabled, dynamic" or not). Thanks!

    Reply
  4. It's not like the IAB didn't try but MRAID just doesn't have a whole lot of support out there. Standard tags are the only way to go, especially in a programmatic setting. You might think that would limit anything "rich" but the in-banner format, if done properly, is actually quite nice and is IAB and mobile compatible.

    Reply
  5. Analizer

    Its pretty amazing.
    Sueing for rebates.

    Im affraid thats the only way,
    Agencies will be way more carefull and as a result, more money to real value players.

    Reply
  6. MRAID objects isn't only because of non MRAID compliant supply marked as compliant, as per my testing with atleat 1 major SDK provider, a N-1 version of the SDK would not initialize mraid, everything else being equal. I wonder how many developers out there keep their SDKs updated.

    Reply
  7. This must be excruciating for a publisher to read too, because they are paid on the exchange's reporting (which is then edited and audited based on the advertiser's creative reporting)...

    And if the ad isn't showing according to the advertiser reporting, the publisher will see a higher discrepancy with the exchange when they audit / edit out the impressions that aren't showing or loading.

    It's also possible that the campaign would have performed well on these incompatible sites, so everyone loses. The Marketer, Exchange and the Publisher.

    I'm sure that if a publisher is made aware of an incompatibility and they are able to act on it, they would. They want to ensure their site isn't wasting impressions, but driving performance for their advertisers and being compatible with as many buyers as possible to maximize their yield.

    Great article Bennett, +1 for compatibility checks across the exchanges.

    Reply
  8. Hi Bennett,

    Thanks for sharing your experience & expertise. If the programmatic web market went through a big clean-up and significant rationalization in 2017, it was not yet the case for the mobile app market.

    You probably sourced a lot from your inventory from indirect supply sources, i.e. from platforms who do not have direct relationship with the app publisher and thus do not have their SDK implemented. They source through an API. It is a major blocker to deliver MRAID ads at scale as these platforms do not actually control the ad integration and delivery.

    Beside the MRAID standard is not very well implemented and is subject to interpretation.

    We have been maintaining an MRAID sdk since 2010 and went through the different implementations of the standard. We are pretty much MRAID orthodoxe actually. And with close to 10 billion fully MRAID compliant RTB ad opportunities every month we would love more buyers to operate campaign like yours through the RTB pipes.

    Then your comment about the delivery rate raises a red flag: for in app RTB ad transactions it is well accepted that the win notice should be sent client side with the delivery of the ad. So delivery rate MUST BE at least 90% for an inapp transaction. It is the only way to account for mediation and client side yield dynamic implemented in many apps. The case you described would mean that the win url was fired server side (similar to a web transaction). This a rogue behavior, almost surely a fraudulent implementation and at your place I would stop working with any platforms offering this type of set-up. MRAID or not.

    The good news it that the big in app cleaning is coming in 2018 and that the market will experience a major desintermediation and run for quality. I am quite convinced you won’t be experiencing similar issues in one year from now!

    Looking forward to discussing this in person!

    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>