IAB

The Year in Ad Ops 2011 – MRAID Specs Released

Even though it’s been the ‘year of mobile’ for the last decade, mobile advertising really did seem to reach a critical mass this year, as many publishers sold some of their first campaigns, and marketers moved more share of budgets to the mobile medium.  From an Ops point of view, this was also the first year for a lot of organizations to come to terms with needing a real process around mobile campaign implementation on both the mobile web as well as in application environments. As it turns out, getting ads, particular rich media ads to work in an app is fairly complex, requiring a higher level of technical expertise than desktop advertising.

Thank goodness then for the IAB’s release of the first set of development specs for mobile rich media APIs, known as MRAID and written in partnership with ORMMA to unify the industry’s approach to in-application advertising and simplify the implementation of mobile rich media.

Why is MRAID Necessary?

Thanks to some of the security features built it to smartphones, a layer of software called a software development kit, or SDK is typically required in the app to allow ads to expand over content, play sound and video, and do other things that are fairly standard in a desktop environment.  An SDK is nothing more than a block of code that a vendor like a rich media company might write to get their products to work in other applications, so the application developers don’t have to write the code themselves.  The problem is that every ad server and network has their own proprietary SDK for publishers to implement in order to get their ads to work, which usually requires an update to get released through the app store, which typically takes a few weeks.

Publishers not only have to do some development work to make this happen, but they then have to ensure that it doesn’t break the app itself before releasing it and then have to support updates to the SDK, basically forever, since not all users will update their apps, so legacy SDKs will stay in place long after a publisher might remove a vendor’s code from the most current version of the app.

So, with all that headache, the IAB took up the challenge to set some standards for SDK development, creating an open standard for rich media APIs to communicate with a mobile device, which is what an SDK does. By standardizing the API code, publishers can hopefully move to an SDK agnostic place, where they can use one centralized SDK that works with all rich media, and not need to support multiple piece of vendor code to enable ads. This is a big deal for the Ad Ops community and the Ad Tech community, who have struggled under the weight of technical problems to get campaigns live and facilitate mobile ad budgets. Hopefully MRAID makes a huge dent in those operational problems, and makes it faster and easier to get campaigns up and running, which should encourage advertisers to put more money to work in mobile.

I would encourage all Ops professionals to demand MRAID compliant apps and ads in your mobile ad spec and with vendor negotiations. The good news is that MRAID has enjoyed wide adoption and compliance from the major players in the mobile marketplace from the beginning, so there is already considerable momentum here.

Read about the other most significant developments in Ad Ops in 2011:

MediaBank & Donovan Data Systems Merger
Adobe Emerged as a Major Force in Ad Tech

Tracking Billable Impressions and 3rd Party Discrepancies with Ad-Juster

The Problem with 3rd Party Discrepancies

It’s a sad fact that after more than a decade of innovation and growth in the digital display business, virtually nothing has been done to address the cost of 3rd party discrepancies on the industry.  As I detailed in my post on how 3rd party ad serving works, because Publisher ad servers and Marketer ad servers count an impression at a different point in the technical process, there is always a variance in the numbers, and reconciling those figures to cut an invoice is a manual, time-consuming process, and a huge administrative cost on the industry.  Discrepancies are typically around 10%, but can often exceed this, especially if there is a technical problem with the ad.  In virtually all cases however, publishers simply have to accept losses due to discrepancies as the cost of doing business.

Third party ad servers have never made it easy to address this issue.  Their publisher reporting tools are woefully inadequate and in some cases comically inefficient.  For example, the leading ad server, DoubleClick’s DART product, does not provide site level reports for publishers that allows them to see everything running on their site from that ad server, but only allows publishers to get reports advertiser-by-advertiser.  That means billing departments on every major online publisher spend days pulling hundreds of reports every month out of Dart alone. That means for most operations folks, a centralized reporting database that maps 3rd party delivery to local ad server delivery at the creative or flight level and updates automatically is practically a holy grail.

The Industry’s Response: An Impression Exchange

The IAB has recommended their own solution to address the matter via the Impression Exchange project, but I find the project fundamentally flawed.  For one, the technical process the IAB uses to centralize impression reporting between systems adds another call in the ad serving process and so creates a discrepancy on the discrepancy it reports.  Additionally, it has been very slow to win adoption by the ad servers – a year and a half in and DART is the only ad server currently on board.

Ad-Juster, The Superior Solution

A far better solution is for publishers to look at a company called Ad-Juster, which has created a way to centralize third party reports and map third party delivery against their internal flights down to the creative level.  Ad-Juster has essentially mapped the schema for every ad server reporting system, figured out how to pull large data dumps from every major third party ad server on a regular basis and map it with a unique identifier back to the third party tag running on a publisher’s local ad server.  In other words, it allows them to create a unified database across lots of systems. While the system is just a read-only version of the reporting you can get yourself, the speed and automation it brings to the table is very compelling for any large publisher.

Ad-Juster offers some canned reports that actually calculate the discrepancy between systems as well as some helpful filters that automatically email you a discrepancy report on flights that launched in the last three or five days for example, which allows operations staff to quickly catch implementation or technical issues.  Since you can monitor the entire network on a regular basis, it is easy to adjust the padding that most publishers add to client goals to makeup for an expected discrepancy.  You may very well find that some third parties track closer than others, so you can reduce the padding for those campaigns.  The reports are a boon to operations folks, but also extremely useful for billing departments.  Now the billing staff doesn’t have to spend all their time waiting in an ancient publisher-facing ad server UIs, they can push bills to clients faster.

The system isn’t perfect, especially if you run the same third party tags in multiple flights (the system can have a hard time attributing the right amount of third party impressions at the flight level in that case), but in most cases it offers tremendous benefits.  Recently Ad-Juster has partnered with Solbright and Fattail to push their data into those workflow systems, but they also offer an API for clients that want to push the data to proprietary systems.

Highly recommended for large publishers seeking reporting relief.