Analysing Android Application Sales
Analysing Android Application Sales
Join the DZone community and get the full member experience.Join For Free
Get the Edge with a Professional Java IDE. 30-day free trial.
One of the reasons that I’ve chosen to get involved in mobile app development in recent months is because I wanted to experiment with the economics of selling software. The new world of mobile app stores provides an ideal opportunity to do just that. For an eye-watering 30% of your revenue, Google and Apple will provide all of the distribution and payment-processing infrastructure so that you can concentrate on making and marketing software. Given that I’m already experienced with Java and that Google puts fewer barriers in the way of developers than Apple, Android was the obvious platform choice (I have since also started exploring iOS development, perhaps I’ll talk about that in a later post).
I have already related details of my initial forays into Android app development, the results of which were my first two (very basic) paid-for applications. The Beep Test app has sold a decent number of units considering its modest functionality and that it was only written as a “my first app” introduction to Android. We’re talking hundreds rather than thousands but that comfortably beats the “one genuine non-refunded sale” target that I set for it. The second app on the other hand has been, by all financial metrics at least, a total failure.
Try again. Fail again. Fail better.
Fortunately I was not banking on getting rich from these simple applications. They were a means to an end, an Android familiarisation exercise, phase 1 in a longer term plan that has more than one possible successful outcome.
Since then I’ve released a couple more apps, though much of my time has been occupied generating real revenue for Rectangular Software through paid development work. Like the vast majority of Android developers, I’m still awaiting the promised riches of the smartphone revolution. I have no sense of entitlement in this respect. I don’t expect to make a year’s salary from an app that took two weeks to write. A more realistic goal is two weeks’ salary for two weeks’ work, acknowledging that an app will not generate all of its revenue in the first month – it may take a year or more to make a decent return. Of course, like most apps, it may never make a decent return.
If you can make a modest amount from one mobile app, you can make 20x a modest amount from twenty mobile apps. Applying the arithmetic of unspecific numbers, 20x a modest amount equals a reasonable amount. The logic is sound but the approach only scales so far. In the absence of a genuine hit among your 20 apps, substantial wealth may not be forthcoming. Adding more unfocused development effort is unlikely to be sufficient.
At this point I’ve written a page of text and not gotten to my point. My point is that, to stand a chance of financial success, the average mobile developer needs to figure out how to maximise the return on their development effort. Marketing, economics, and all the other non-technical stuff. The goal is to make sure that you leave no money on the table. You’ve written the software, sell it.
You can’t control what you can’t measure
I’m not the person to tell you how to increase your sales (maybe you should start with Andy Brice’s series of articles about promoting your software). I’ve already established that I am a very long way from making a sustainable income from mobile development. You should also know, if you haven’t deduced it already, that I am not an economist. As for marketing, I make that up as I go along. I do however have an extensive collection of quotations ready to deploy as the situation demands. Enter Benjamin Disraeli:
“As a general rule, the most successful man in life is the man who has the best information.”
When optimising computer software better information leads to better decisions and better outcomes. The same is true when optimising for financial performance. It’s why insider trading is so profitable (and so illegal).
If you were selling software from your website rather than somebody else’s app store, you would use Google Analytics or similar to record and digest the information that you needed to optimise sales. There are some partial equivalents in the Android world such as in-app analytics, which only tell you what happens to your software after it’s been bought, but a complete picture will not be possible until Google starts revealing more Android Market data to developers. For now we have to work with what we’ve got. What we’ve got is some fairly detailed information hidden away in Google Checkout. Again, it won’t tell you about the people who didn’t buy your apps but it does give some insight into who is buying.
You can download this information in CSV format. When I looked for a tool to process this data, I didn’t find anything. So I wrote my own. This has helped me to identify some interesting trends.
Perhaps most informative is where I’m making sales. The top five countries are all (predominately) English-speaking countries. This is to be expected since my software is currently only available in English. These five countries account for 94.8% of all my Android revenue. Take a close look at the figures for the UK and France. These are two neighbouring Western European countries with almost identical population levels and similar levels of wealth. Assuming similar levels of Android adoption (which seems reasonable but I don’t have any figures to back up this assumption), it should be possible for me to make as much money from France as from the UK. Instead I make over 50 times as much in the UK. This leads to the obvious hypothesis that I am leaving money on the table by not translating my applications into French. Germany, an even bigger market, is similarly under-represented. This is easily remedied – there are online services that will do the necessary translations for somewhere in the region of $20 – $50 per app for a single language.
The second interesting thing about this data is that the figures for the UK and the US are broadly similar despite the latter having five times the population. In this case the discrepancy cannot be due to language. The data is from the last 3 months or so. In the last few weeks I have seen a sustained jump in US sales and a corresponding dip in UK sales. I can only speculate that this is related to the recent Android Market change to display app prices in the user’s local currency. My figures for October to date are 52.5% for the US and only 25.5% for the UK. Australia is also slightly up.
There are several other ways to digest the Google Checkout data. The above chart shows how revenue is distributed throughout the day. Here you can see that my most productive period of the day is between 4pm and 6pm UK time. Filtering the orders by country shows that 4pm – 5pm generates more money from UK users than any other time of the day, which I find surprising, whereas 5pm to 6pm (12pm – 1pm Eastern / 9am – 10am Pacific) is peak time for US users.
The point in the article where thinly-veiled product placement becomes blatant advertisement
Still reading? OK, that tool I mentioned for analysing Google Checkout data is my fourth Android application, Appmonger, which is on the Android Market for the bargain introductory price of £1.99. It automatically fetches the Google Checkout CSV data and generates various charts, which you can share via e-mail and social media. You can find out more about it by following the link or by watching the poorly shot video on the right. Appmonger has already been through a couple of iterations to incorporate feedback from early adopters and I hope to extend the functionality in future releases, so feel free to make suggestions.
Opinions expressed by DZone contributors are their own.