Archive for July, 2009

And ah ha! This is why we disabled test modes

July 17, 2009

One of the reasons why we disabled test modes for ads is that we’ve heard a few unfortunate stories from developers who, before AdWhirl was around, deployed applications running an ad network’s ads in test mode (doh!).  Being locked into one single ad network and lacking control over your ad content is bad enough; locking yourself down to a single network and _also_ locking your self down to test ads is utterly worse!  When that happens, a developer has to redeploy their application with test mode OFF (of course, after kicking himself/herself over it).  By the time the new update with the fix is launched onto the appstore, weeks and perhaps even months may have elapsed.  During that time, the developer will have lost the revenue from the application due to the lack of real ad inventory flowing through the app.

So due to the infinite concerns that we have for our developers and ensuring that they are safe and taken cared of, we disabled test modes entirely and figured that such issues are forever dead and gone.

Yet, we did not have a concern for our sample AdWhirl application key that showcase AdWhirl. As you already know, you can control your ad content by changing configuration information attached to your own application-specific key. However, you cannot control the configuration data attached to the sample application key.  But apparently, and to our surprise, there’s a risk with the sample key as well when a developer forgets to deploy their application with their own AdWhirl application key and ends up deploying with the sample AdWhirl application key instead!  In comparison, before AdWhirl, this is like deploying your application to the AppStore and running only Quattro Wireless’s ads with test publisher keys! 🙂

We didn’t even realize this until we downloaded the application and saw a test ad that is attached to the sample AdWhirl application key.


But not to worry, we’ve given ownership of the sample application key and along with its settings to the developer, so now the developer is still in full control of their ad content.  Also, all of the revenue that the developer made from the application is sent to the developer as well.

And this is especially important since HIS APP IS THE TOP 1 FREE APPLICATION ON THE APPSTORE!  That’s top 1 free out of the huge number of free apps that are on the appstore (and in total, we’re looking at 65,000+ free and paid applications on the store).  The ad revenue wasn’t too shabby either, to say the least. 😛

So guys, remember that AdWhirl is completely transparent and that you have full control over your ad content through your AdWhirl application key.  But more importantly, remember to deploy your application with your AdWhirl application key, because you own the configuration and customized ads for that application key, and not for the sample key.  AdWhirl’s servers will transparently route the configuration information and custom ads you’ve applied for your application key down to your application users.  So make sure that you’re deploying your application with your own AdWhirl application key, otherwise we’ll have to work extra hard to convert a sample application key into a real production application key just so that you can control the content.  Which is quite a bit of work so please save us from that work!  🙂

Quite humorous, isn’t it?  But in retrospect, isn’t it just great that we were able to save a developer from this mistake that wouldn’t have been possible before AdWhirl?  Since we were able to give our developer the sample application key, and thereby allowing him to fully control his ad content again, isn’t it great to know that the developer doesn’t have to redeploy their application back to the appstore?  This is why we love AdWhirl, because not only are we able to help foster the app ad market ecosystem and offer meaningful value to our 1600+ developers, we can also save them dynamically in more ways than one.