breakdown of advertising revenue leading to a change in direction

Since my previous post about why I'm getting such a low eCPM things have steadily improved.  Our total advertising revenue is now about $140 / week.  This has mostly been a result of an increasing number of impressions.  We'e now hitting about 25,000 / day for fb viewer.  The eCPM has been fluctuating a little but this week is closer 0.60 (for fb viewer) which is helping as well.  (See graphs below)

fb viewer revenue over past 4 weeks

fb viewer impressions over last 4 weeks

fb viewer eCPM over last 4 weeks

Unfortunately a large majority of our revenue is still coming from this one app.  We have 8 other free apps, 3 of which are making a pitiful couple of dollars / week. The others are performing even worse making no more 0.50 / week.

So the numbers really indicate that social media apps are our best chance of making some decent advertising revenue and therefore this is where we will start focusing our resources.  Stay tuned for news about our new app Social Mix which we hope to release over the next 2 months.

Timezone converter v1.1 is out

Timezone converter v1.1 is out. New features include:

• search/filter functionality.
• gmt offsets displayed next to city names.
• contact developer button added to about page.
• progress bar added

Thanks for all the feedback including emails, tweets and reviews which helped shape the direction for this update.

Enjoy!

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. 

Using ZoneInfo api in wp7

Over recent months I have found planning convenient times for skype meetings between myself and my business partner (who is on the other side of the world) to be a pain. I have been travelling quite a bit so my timezone is constantly changing. I thought "there really should be an app that helps with this"!  I already have world clock for wp7 but this just tells me what the time is now.  I wanted to be able to work out something along the lines of "at 9am tomorrow here in Estonia what will the time be in Brisbane Australia?". 

After a cursory search of the marketplace I couldn't find an app that did this so decided to build the capability into a unit converter app that  I was working on. 

Having worked with timezones in .net before I thought "this will be dead easy". I dived in and built the ui.  Next step was to populate the UI with all of the world time zones so the user can choose which time zone they want to convert from and which time zone they want to convert to.

Unfortunately I soon realised that this would not be as easy as I thought.  In wp7 the TimeZoneInfo class does not have the getsystemtimezones() method. As mentioned in this post.  I'm not sure why? maybe it is because they are trying to keep the wp7 api as lightweight as possible.
Fortunately after some more searching I found http://zoneinfo.codeplex.com/.  A brilliant little .net api for using the tz database of world timezones.

Unfortunately it can't be used with wp7 out of the box, but after a few small modifications it worked great.

I Just did the following:

1. Downloaded the source code from http://zoneinfo.codeplex.com/
2. The library is not accessible via silverlight so I needed to create a new silverlight library and copy the classes from the zoneinfo library into it.
3. I also had to copy the tz database files into the silverlight library and set their build action to resource.
4. The loadfile / loadfiles methods in Database.cs had to to be altered so that I could pass the uri's of the tz database files.
5. Lastly I needed to alter the loadfile method to read the file uri and create a StreamReader object.

That's was it.  Now I can convert timezones in wp7.
    //convert local time to the time in Brisbane / Australia
   Zone theZone = Database.GetZone("Australia/Brisbane");
   DateTime d = theZone.ConvertToLocal(DateTime.Now.ToUniversalTime());