Why am I getting such a low eCPM?

At the moment we are making most of our (very modest) advertising revenue from one app;  FB Viewer.  Currently about $75 / week from that app and another $5-10 / week from our other 8 free apps. 

The impressions for this app has been steadily growing over the last 7 days but the low eCPM is killing us.  (See graphs below) The last few days we've had over 16,000 impressions each day for FB Viewer but with an eCPM which has today hit an all time low of 0.44 USD this isn't equating to much.

FB Viewer Impressions

FB Viewer eCPM

 Most of our other app such as Beat My Drum, Timezone Converter and Camera Flashlight are getting eCPMs that are well above $1. In fact Beat my drum has been consistently between $4 - $7 over the past 3 months. Today it's $5.83.  If only FB Viewer was getting an eCPM of this amount we'd be making around $700 / week from this single app.  (Based on 16602 impressions * 5.83 / 1000 eCPM * 7 days = $677.53 ).  


So why am I getting such a bad eCPM???

The truth is I don't really know. No one outside of Microsoft does. I've searched the pub center forums and read various blogs on this and there is a lot of theories but no solid information. From what I can tell the main factors affecting eCPM are as follows:

• Click-thru rate - The more users that click on ads the higher the eCPM.
• Country the ads are being served to - To make any money you really need to have lots of impressions in certain countries.  I make all my revenue from adverts served in USA, Canada, Great Britain, Germany, France and Italy.  I make almost nothing out of any other countries.  For example I have thousands of ads served in countries such as Australia and Taiwan but I get an eCPM of $0.00. I read somewhere that this is because pub center is just doing beta testing in those countries.
• Stickyness of users - I have heard conflicting reports about this.  But there is theory that advertisers will pay less if their ad is being served to same users over and over again.  So although having an application which keeps users coming back again again is great for increasing impressions it seems this may result in a lower eCPM. This seems true in my experience as my two most "sticky" applications are XKCD Reader and FB Viewer.  Both currently have an eCPM of under $0.50.
• Who the advertiser is -  It seems the amounts paid by various advertisers vary greatly.  Unfortunately it's impossible to know which advertisers and which categories will pay the highest amounts as this information is kept secret.  However when I decided to block ads from McDonalds.com and McDonalds.co.uk the eCPM's on all my apps went down noticeably. (For reasons why we didn't want to serve ads for McDonalds see Morgan Spurlock's awesome 2004 documentary supersize me )

The more research I've done the more I've realised there is very little I can do to try and improve the eCPM I get.  However the following (very loose) guidelines may help you if you're developing wp7 apps and using pub center to serve ads:

• Try to make your app relevant to people in the USA as this is where most advertisers are and where the highest eCPM can be achieved.
• Try to choose ad unit categories relevant to the kind people who will be using your app in order to maximise your click-thru rate.
• Try to choose atleast one broad ad-unit category to reduce the chance that the same advert will be shown to users over and over again. (I realise this will not always go hand in hand with the point above.  So to find a middle ground I would suggest choosing 2 very specific and relevant ad unit categories and 1 broader one. )
• If you are going to make your app available in languages other than English then German, French and Italian might be a good place to start as in my experience all of these markets are paying a decent eCPM.

 If you have more information on this topic leave a comment or hit us up on twitter.

Timezone converter for windows phone

Our tenth app has just been approved on the windows phone 7 marketplace.  Sweet!

It allows you to choose a point in time in one timezone and see what the equivalent time will be in another timezone.  Great for organising overseas phonecalls and online meetings etc.

Check it out.

Beware of the longlistselector.

I just finished and submitted our new app 'Timezone Converter' and feel I should warn people about a few issues I encountered with the longlistselector control.

The November 2011 update of the wp7 toolkit includes a longlist selector which is great for grouping together a long list of items. We used it for timezone regions. See screenshots below.

 

Overall the list worked great and in a fairly short amount of time I was able to populate the list with world timezone regions which were nicely grouped together under click-able headingss that allow the user to easily jump to different sections of the list.  (For information on working with timezones in wp7 see my earlier post on using the zoneinfo api in wp7).

Unfortunately I encountered two bugs in the control which I ended up wasting way too much time on.  The first problem is that binding the selecteditem did not work.  If you are using mvvm you will find this especially annoying.  The issue as well a workaround is described in detail here.  

The second issue (for which I found no information on the internet) can be repeated as follows:

• Create an app and with a long list selector.  
• Set it's visibility to collapsed
• Include a button which when clicked sets the longlistselector's visibility property to 'visible'.
• Run the app.  Click the button so that the long list selector is displayed then hold down the back button on your phone and switch to another application.
• Hold down the back button and switch back to your application.
• It will now hang on the resuming screen and eventually terminate without throwing an exception.

This bug was an absolute pain to get to get to the bottom of.  I tried to workaround it by just changing the margin of the grid containing the longlistselector so that it was either in view or out of view but this did not help. I also tried removing it from a grid and placing it in a stackpanel as well as just updating the longlistselector's visibilty directly but had no joy with that either.   In the end the workaround I used was simple.  I left the longlistselector as always being visible and just placed the grid containing my default form in front of it.  Instead of toggling the visibility on the longlistselector grid Ijust toggled the visibility of this default form and everything worked fine.  

Another obvious workaround would have been to just embed the longlistselector in a different xaml page and navigate back and forth between my main page and the longlistselector page.  However as my app was already working other than this bug I chose the first option.

I hope this helps someone as it took me quite a while to get to the bottom of both of these issues.