HTML and CSS Reference
I like to break my ad testing down into the following four tiers. I always try to shoot for the first one, but again
sometimes it's out of reach for various reasons outlined earlier.
Use a test build of the application on the device it's intended to run on.
Test using the native web browser on the device it's intended to run on.
Test using a device simulator of the device it's intended to run on.
Use the desktop browser with a similar rendering engine as the mobile web browser such
as Webkit for Mobile Safari.
In the case of MRAID, you can view compliant ads in the MRAID web tester located at http://webtester.mraid.
org , but you can also download the source code and run your own web tester on your own domain. There you'll
be able to simulate an application environment using the MRAID API and validate whether your ad's functions are
I think you'd agree that testing is a challenge for in-application advertising, but I predict this getting much easier
as time moves on and as more ad spend moves into this market. In fact, Apple's iOS 6 and Mac OS X Safari allow for
testing and inspecting on devices such as iPhones and iPads through desktop Safari using the Safari's Developer tools.
Designers and developers can now view their applications, web content, and advertisements as they render in real
time on the actual device.
At the end of the day, testing on a device within the application is ideal. But if you need to settle for what you
can get access to, use simulators for iOS, Android, and other mobile OSs, and if you need to, drive to your nearest
electronics store and test on the floor models (seriously, I've done this). Remember, it's tablets and phones today, but
next it will be TVs and other appliances and vehicles. We can't be expected to own and test on every refrigerator, can
we? Fight for getting that testing application from the publisher, especially if you plan on doing more than a one-
off campaign with them. Building, testing, and debugging will go much more smoothly when you do, and if you're
an application maker or publisher, use tools like TestFlightApp ( http://testflightapp.com ), which allows you to
pass around your apps to various team members over the air (OTA). This is especially helpful if your production and
development team is stretched all over the globe!
MRAID is still fairly new in some regard, but the promise is that this will be the standard going forward when working
with advertising inside applications. Publishers take a while to adopt new practices, but MRAID support is a huge
push in the industry and even a bigger one by the IAB. As I write this, the IAB is currently going through many tests
and discussions for future versions of MRAID and releasing certification tags to publishers and ad servers that state
they are MRAID compliant. While I personally wish they'd police this a bit better so publishers and ad servers had to
prove that they're MRAID compliant, I guess it'll do that they state that they are. Hell, we can always call them out if
The truth is if you have a campaign coming up that requires you to serve into an application because it's outlined
in the media buy, first make sure that the publisher's SDK is MRAID compliant. Second, perform a test flight to
ensure everything is ironed out before running an actual campaign. This will allow you to comfortably scale across
many publishers and applications with ease and with the certainty that your ad will be functioning correctly in any
and all applications that support the API. There is no longer a need to handle the SDK fragmentation in this space.
We all know developers have much bigger things to worry about, especially with the fragmentation in other areas
in the industry. If you do in fact run into an issue with a publisher or application stating it's MRAID compliant but
your tests prove otherwise, tell the IAB about so it can enforce compliance ( http://iab.net/guidelines/508676/
compliance/2153679 ). Again, this is for the betterment of the industry as a whole, not to point fingers.