Month: March 2013

Categories
Tools

TapJoy (53%) leads in cross-promotion networks, Flurry and Chartboost are chasing

Building a great app is not enough – to get lots of users, those users have to be aware that you exist. As app stores focus on top apps, which amount to less than 1% of all available apps, discovery has become a major problem for app makers. One solution is to band together in a cross-promotion network: “advertise” apps within other apps, making it easier for users to discover similar apps to the one they are already using.

Numerous models of cross-promotion exist

Cross-promotion networks (CPN) are used by developers both as a means for promoting their apps and monetising apps. When used for promotion purposes, there are numerous models out there, some being free, based on traffic exchange between apps, enabling developers to run low cost or free promotions. However, several CPNs operate on a cost-per-install basis, with developers paying for each user acquired. A special case of cross-promotion is incentivised installs, a practice that Apple has been trying to restrict on App Store.

Used by 7% of developers overall, usage of cross-promotion services is not very high and does not vary significantly by platform. Usage is higher among developers that develop games (13% of all games developers) and higher than average among developers working on comms & social networking apps (9%), entertainment apps (10%) and music & video apps (10%). These app categories are mainly addressing young consumers with limited purchasing power; using CPNs and incentivised downloads in particular, allows easy access to this target audience, which would otherwise not be able to acquire such apps. Developers who use CPNs tend to use one network (59%), but 18% use more than three networks. Overall, developers using CPNs will use 1.7 CPNs on average.

CPN usage increases with the number of apps developed, rising to 15% among developers who work on more than 16 apps per year. CPNs provide opportunities to cross-promote across one’s own apps, allowing developers to leverage the popularity of the most popular apps to drive usage of less popular or new apps. For developers working on several apps it usually makes sense to cross-promote across their app portfolio.

DE13-22-01

Tapjoy leads, with Flurry and Chartboost following behind

TapJoy is leading in the cross-promotion space, used by 53% of developers that use CPNs. Flurry AppCircle and Chartboost, follow at some distance and are competing for second spot (20% and 18%), while there are numerous other providers who have over 5% market share.

The most important selection criterion for cross-platform tools is the number of users reached (36% of developers using cross promotion networks) but it is only marginally higher than cross-platform availability (35%) and ease of integration (34%). Obviously, depending on how developers use these tools, the decision criteria may vary. For those developers who use CPN for promotion purposes, cost is important. We found that, on average, the typical CPI (cost-per-install) was $0.60 among iOS and Android developers, with no notable difference between these platforms. When used as a revenue source, the revenue potential becomes important, as indicated by 25% of developers using CPNs. About a fifth of developers rely on recommendations for selecting a CPN.

[doritos_report location=’DE13 Article – Cross-promo networks’]

Which cross-promotion networks are other developers using?


[toggle title=”Important things to know about this interactive graph”]

  • All the filters in the graph refer to survey questions in which respondents could select multiple answers. This means that there is no direct link between the filter and the use of the tool. For example, filtering on “Android” means that the respondents develop Android apps. It doesn’t imply that they use the tools for their Android apps specifically, or even that the tool supports the Android platform. Use filters as a guideline only.
  • Keep an eye on the sample size. If the sample size is low, the graph doesn’t offer strong conclusions about the popularity of different tools. Use your good judgment when making decisions.[/toggle]

    Find the best cross-promotion tool for you!

    [sectors ids=’45’]

Categories
Business Tips

How to Optimise Ad Revenue

Optimise Revenue

On the surface, advertising seems like a fairly simple and easy to implement business model for an app. Decide on some places to display ads, integrate one or more third party ad services and wait for the money to start rolling in. If you do this without a clear plan for how and why users will interact with ads in your app you’ll probably find the revenue disappointing. Optimise revenue by growing your user base, increasing engagement and improving your fill rate (how many of your possible ad slots actually show an ad) and eCPM (effective cost per thousand impressions). The challenge becomes apparent when you try to improve these metrics and find them somewhat opposed to one another. Show too many ads and users either use your app less or abandon it altogether. Make the ads smaller or display them less prominently and your click-through ratio (and hence eCPM) goes down. Show a lot of irrelevant ads (higher fill rate typically has less relevance on average) prominently and users start ignoring all of them by default. Make your ads prominent and they’d better be relevant. If it’s hard to target your audience well then keep the advertising low key and count on volume to make up the revenue. It turns out that getting the right balance is very difficult and not many developers manage it.

Higher eCPM != higher revenue

A very small fraction of developers in our survey managed to achieve truly exceptional eCPM’s, greater than $5, sometimes even more than $10. These developers were almost all making multiples of the average revenue in total but they were also using more than one revenue model. It’s likely that most of their revenue was coming from another source and they showed very few highly relevant ads to get those rates. If we focus on the developers who only used advertising as a revenue model then those with eCPM’s below $0.25 were earning significantly more on average than those with eCPM’s from $0.25-1.50. So, for the majority of developers, those with higher eCPM’s make less money. To add to the confusion, size of active user base is also very weakly correlated with ad revenue; the simple concept of getting more users to make more money from ads doesn’t work on its own either.

Why iOS developers make more with ads

A good illustration of the complexity is to compare iOS and Android developers. As reported by several ad networks, iOS gets a higher eCPM on average than Android. However, our survey data suggests that the difference is all at the very high end. If we exclude the developers with eCPMs over $5, iOS actually has a lower eCPM than Android. For those only monetizing via ads, Android developers had a 37% higher eCPM and while the iOS developers only had 20% larger user bases on average, they earned almost 75% more revenue every month. This suggests that the iOS developers were seeing very much higher engagement with their apps and thus delivering many more ad impressions.

The fallback network fallacy?

There’s some popular advice that in order to maximise ad revenue, developers should use at least two ad networks, one with a high eCPM and low fill rate and another with a lower eCPM but very high fill rate. The theory is that this ensures they get the most relevant targeted ads with the best rates when they’re available but still don’t waste the inventory by filling it with less relevant lower paying ads when they don’t get filled by the premium network. This fallback strategy sounds logical but does it work? There’s some possible support for this in the fact that developers using more than one ad network make slightly more money on average than those who only use one (and 70% of developers purely monetizing through ads only use one network). However, this seems more likely to indicate greater sophistication than successful use of the fallback strategy. The ads from the two different networks are unlikely to fit the same presentation, positioning and format within an app well. There’s some fairly strong evidence against this fallback strategy within our survey data – developers with eCPMs above $5 are excluded from the following sample and so are those earning greater than $50k per app per month in revenue due to the disproportionate effect both tiny minorities have on averages.

Note that 67% of developers using ads selected neither eCPM nor fill rate as reasons for choosing their ad networks and that percentage is mirrored in the group only using ads for monetization. Those that selected one criteria or the other but not both generated slightly higher eCPM than average and significantly higher revenues. Developers trying to maximize both metrics to squeeze the maximum possible revenue out of the advertising space in their apps generated the highest eCPM but did far worse than average on revenues.

Optimise for engagement

This data suggests that developers should pick an appropriate advertising style for their app and try to go for either quality or volume of ads displayed but not both. Considering that the most popular advertising services use a cost-per-click model, the highest eCPMs are likely to simply reflect higher click-through ratios. In many cases the taps on ads may be accidental. Ads getting in the way of the content or usage of an app result in fewer users or lower usage and thus lower revenue. It seems that by far the best way to optimise ad revenue is to build app experiences that people want to spend a lot of time using and make sure the ads don’t spoil them. The extra volume of impressions generated by tens or hundreds of thousands of engaged users will more than make up for lower eCPMs or ad inventory not getting filled.

Categories
Business

Why Measurement Matters – the case for analytics

Measurement Matters

Creating a successful app business takes a lot more than a good idea and the skills to develop an app and upload it to a store. As we’ve discussed before, developers who promote their apps are almost 3 times as likely to break-even as those who don’t. This is the simplest difference with a massive effect on success. It seems obvious, no marketing means a good chance almost no-one discovers the app and thus no revenue, yet some developers still don’t do it. Picking the most lucrative platforms seems like another obvious candidate; considering only those developers who are interested in making money, those that develop for iOS are a little less than twice as likely to be above the “app poverty line” (38% earn over $500 per app per month) than those developing for BlackBerry (20%). Getting your revenue model right can also make a significant difference; according to our survey, developers using a subscription model earn nearly 2.5 times as much as those using other revenue models on average. Not all apps can use a subscription model, however, there is something that almost every developer can do which is correlated with more than double the chance of being above the app poverty line and earning more than 2.5 times the average revenue compared to those that don’t…

Measuring user activity and crashes

You managed to build an app and get people to download it but how many of them still use it? When do they use it and how often? What devices do they have and which firmware versions? What features do they use the most? Which parts of the app should you focus on improving? Do your changes to the app make users interact with it more or less? All of these questions require measuring the user interaction with the app by recording data and analysing it. Unless your app regularly interacts with your own backend service which you can collect relevant statistics from then this would be an expensive capability to build. Fortunately there are a number of third party usage analytics services to do it for you and the two most popular, Google Analytics and Flurry, are free to use.

Similarly, no app is perfect when it is launched and it’s almost impossible to test on every device and firmware combination out there in the market. If some of your users are getting crashes that you can’t reproduce and fix quickly then you’re likely to get a lot of poor reviews, which will reduce the chances that other users download your app in the future. Unless you have tooling in place to capture details of crashes and report them to you then it’s very hard fix them. Although there are libraries that can report crashes to you directly, unless you want to analyse every single one manually, you’ll want tools that do that for you and categorise them such that the ones with common causes are grouped. Without this there’s no good way of prioritising what to fix. Again, crash analytics & bug tracking service providers can handle this for you and one of them, Crashlytics, was recently acquired by Twitter and now provides all of its features for free. Other providers also have free tiers.

This is not to suggest that the free options are the best for every app, just that there’s very little excuse for not using these tools because there are free ones. If you need convincing, take a look at this infographic, which uses our survey data for just the respondents that were interested in making money and earning less than $50k per app per month (we exclude the very small number of top earners as they can distort the stats, although in this case they would only make the argument stronger).

Correlation is not causation

It’s really important that we note a strong correlation between usage of analytics tools and increased success for developers only. Correlation is not causation. It’s clear that simply integrating these tools and doing nothing with the data is not going to make the slightest difference to anyone’s results. They are trivial to integrate but provide no direct end user benefit at all and no additional revenue stream. It could be argued that most providers only make these services available for the leading platforms and the extra success is primarily due to that. This is not the case – restricting the data set to those developers whose primary platform is Android or iOS produces an almost identical pattern of results. Another argument is that crash analytics services are typically focussed on native stack traces, which don’t often provide much diagnostic value for non-native apps. However, anyone tempted to blame a poorer non-native user experience produced by development tools that are also less likely to support these analytics tools should note that cross-platform tool users make more revenue.

One valid argument is that until you have a successful app with a fairly large and diverse user base, collecting crash data and analysing it is not the biggest problem you need to solve, those who use the services may simply be the ones already big enough to have the problem. There are two arguments against this. First, integrating crash analytics after you’ve acquired a large user base is too late; how many users will give you a second chance installing at least 2 updates to a crashy app (you can’t fix it until the update after you integrate the analytics)? Second, this doesn’t explain why those integrating both types of analytics tool have a significantly greater chance of being above the poverty line than those that only integrate one or the other. Similarly, whilst there is almost certainly an experience factor at work here it is clearly not the whole answer.

The most plausible explanation for these results is that those with a more scientific approach to their app business tend to collect as much data as they can and use it to drive decisions about their development. This produces more successful apps than intuition and guesswork. So, sign up for analytics services, integrate them with your apps and act on the data they provide. This process can’t magically turn a bad idea or unwanted app into a success but it can help make a decent app into a much better one. If you apply some of this data-based reasoning and scientific methodology to deciding what to build and how you market it too then that’s likely to further increase your chances of success.

Got an alternative explanation for this data? Let us know in the comments below.

Categories
Platforms

Kids’ Educational Apps – An Indie Dev’s Final Frontier

VM_010

I am wondering if you know that there is an SXSWedu event. Well I can’t blame you if you don’t, it is the third year it is running and it sounds a bit off when you think of SXSW and “Keep Austin weird”. If you don’t then it will even come more as a surprise to learn that Bill Gates delivered the closing keynote to a standing-only room of 2,500 people.  On top of that, Apple revealed to TechCrunch a couple of weeks ago that they have sold more than 8 million iPads to educational institutions worldwide (4.5 million to U.S. schools).

You might have started thinking that putting together an educational app may not be such a bad idea, I mean how hard can it be? How about checking out the App Store’s top 200 paid list of iPad educational apps? Just by going through it, even if you don’t know who is who, you will see a lot of indie developers. Let me save you the trouble and give you the rundown. Of the top 200, 70% are kids’ educational apps. Out of these, roughly 80% are by independent developers, and only 20% from well-known publishers like Disney, Nickelodeon, Sesame Street, etc. This is really impressive to say the least.

But before you team up with a teacher and start coding that idea, hold on. For every developer who is succeeding, there are 20 who are struggling to see noticeable sales. To make matters worse, only 20% of the developers present in 2009 were still active in 2012 (iLearn II – “An Analysis of the Education Category of Apple’s App Store”).

All of this translates to the indication that there are still great opportunities in kids’ educational apps right now, but there is also a lot of risk. That is why the kids’ educational apps market is an indie dev’s “final frontier”. So before you set off to “boldly go where no man has gone before”, here is a survivor kit to keep in mind when navigating those treacherous waters:

1)    App stores lack specific categorizations

No single app store has a separate category of kids’ educational apps. So kids’ educational apps are all scattered in a number of categories. In the Apple App Store they are scattered across Education, Games/Educational, Games/Kids, Books, etc., and in the Windows Phone Marketplace between Education and Kids + Family. Keep that in mind as you pick your category and since there is no right or wrong,  don’t be afraid to experiment.

2)    Never ever forget market segmentation

It is an easy assumption to make but it is one that you must always keep in mind. Education differs across countries considerably, it is not only the language and cultural barriers, but also that educational topics are approached in different angles. In the US the past three years the Common Core Standards initiative has been put together that provides a clear understanding of what students are expected to learn so teachers and parents now what to do to help them. CCS can be a very useful roadmap when you are thinking of your app. Lastly always factor in that localization will not be easy and it will cost more than it would normally do.

3)    You have limitations on your monetization strategy

With stories of a 5 year old spending $2.500 on iPad apps in 10 minutes hitting the news frequently be very careful of your monetization strategy. I am not arguing to exclude In App Purchases but be very cautious about your implementation and disclose this information to parents.

4)    Be wary of COPPA

Talking about disclosures you need to get up to speed with the Children’s Online Privacy Protection Act. You need to have a privacy policy, provide disclosure about data practices and take responsibility for data practices of 3rd party code. Lorraine of Moms With Apps has put together a great reading list on the subject here, which is always updated.

If then you are up to being one of the risk-takers that Bill Gates mentioned in his speech, help change the face of education and make money on the way keep in mind his closing words “In this space, we either improve the quality of education or we stay flat, like we have for the last few decades”, put your soul into it and make great educational apps.

Categories
Platforms Tips

A/B Testing on the Amazon Appstore

App Store

In December Amazon launched a new A/B testing service for Android apps on the Amazon Appstore. Integrating A/B testing, particularly for in-app purchase related events, in the store portal is a welcome addition. Slightly disappointing considering this comes from a store provider is that the A/B testing service does not support testing different copy or icons on the storefront itself, purely in-app A/B tests, for which there are already third-party alternatives.

Not a “leaner” alternative store

When we looked at the developer platform “lean factor” for Android previously, we were only considering Google Play. Android came out on top due to the ability to publish new versions to the store almost immediately, enabling much faster iteration. However, the Amazon Appstore does have a review process which introduces significant publishing delay. As such even with the convenient addition of A/B testing baked into Amazon’s store, Google Play still offers a better environment for implementing lean development.

Testing in a smaller market

That said, there is at least one interesting use of this new service. Amazon’s Appstore has historically had a much higher proportion of users paying for downloads and in-app purchases than on Google Play – so much so that in early 2012 many developers made more money on Amazon’s store despite the much smaller audience. A smaller market with a high proportion of paying users is ideal for A/B testing improvements with the most important user group, particularly improvements to in-app purchase flows. Testing new variations on Amazon’s store and then rolling the successful ones out to a Google Play version might be a useful strategy for increasing revenues.

But how much smaller?

A final question is how much smaller is Amazon’s store in terms of downloads? They are notoriously silent when it comes to absolute numbers and even the relative numbers they give are ambiguous. In the press release for the A/B testing service linked above they say that app downloads have grown 500% over the previous year. This was in a release at the beginning of December with no fixed reference point given for the comparison. As can be seen from the relative growth chart produced by Distimo at the same time last year below, the launch of the original Kindle Fire at that time produced similarly massive growth.
Distimo_Amazon_AppStore
Dependending on where the comparison is made, a 500% increase could be anywhere from slightly behind January’s download level to 6 times the December 2011 peak. Until they provide some concrete numbers the best advice is to try it and see what your own results are like. The only major difference we’re certain of between the app buying users on the two stores is a higher proportion of tablet users at Amazon’s.

Categories
Languages

HTML5 Adoption and the Importance of Independence

HTML FUD

Last year was quite a bad one for HTML5 in terms of developer mindshare. At the end of 2011, developer sentiment seemed to favour a shift away from native and towards HTML5 for a large range of application categories. As the year went on, there were more horror stories than successes and the tide of opinion swept the other way as Facebook publicly declared that HTML5 wasn’t good enough for their mobile apps. With a title declaring the importance of independence you’d be forgiven for thinking this article would be about a need to reverse that trend to get away from the tyranny of walled garden app stores. Nothing of the sort we promise.

Look out for sampling bias

Independent surveys and statistics are the important thing referenced in the title. HTML5 adoption just happens to be the subject of one of the best bad stats examples in the midst of last year’s shift. Apparently last summer, just after Mark Zuckerberg’s revelation that betting too heavily on HTML5 for mobile apps was the biggest mistake he’d made at Facebook, 94% of app developers were betting on HTML5 winning. Of course this survey came from Kendo UI – a vendor of HTML5-based tools for mobile app development. It’s unlikely they set out to create a useless survey but they did want some data to support their tools. So they asked web developers if they were using, or planning to use web technologies – amazingly most of them said yes! This is clear from the fact that the number one reason for using web technologies in the survey was “familiarity of languages”. Such a high proportion of developers working with web technologies should be excellent news for upcoming web-app only platforms like Firefox OS and Tizen, however, the huge number of native applications being created across all the platforms suggests the real figures are nothing like this. It’s a clear case of sampling bias. Kendo UI recently published another survey in which a more realistic 50% of developers built some apps with HTML5 last year but a rather less credible 90% were planning to use it in 2013. Contrast this with our latest mindshare and intentshare data, which agrees with 50% use last year but sees only 15% of those not already using HTML planning to adopt it.

Seek transparency and independence

In our developer economics survey we make a big effort to ensure we collect data from a wide range of developers and we publish the breakdown of platforms developers are working with along with the results of all the other questions. Where appropriate we weight or normalize results according the the proportion of different groups in the survey. Of course it’s not possible to avoid all bias in the sample and there is undoubtedly an element of self-selection – developers with an interest in the commercial aspects of app development are much more likely to answer a survey entitled “developer economics”. To a certain extent, that’s deliberate – serious developers who are trying to build businesses that involve apps want to know what other like-minded folks are thinking and doing.

If you’re looking for reliable information on the app market, particularly if you want to make business decisions using it, you need the most independent and transparent sources. We’re doing our best to be one of those sources.

Categories
Business Community Tips

Developer Story: Lyft

developer story: Lyft

Sebastian Brannstrom, Lead Engineer for Lyft at Zimride, talked to us about their app and the business that the technology enables. Sebastian has been working in mobile software since 2006, initially on Symbian and then transitioning to iOS, Android & Web by way of a side project, created in collaboration with designer and product manager Anna Alfut. In 2011 he joined VC-funded startup Zimride, who at the time only had a handful engineers, to create social ride-sharing services. Zimride’s initial service was an online marketplace for people to sell seats in their car on longer journeys. It was (and still is) growing but relatively slowly by Silicon Valley startup standards.

App Background

The company decided to create a new real-time marketplace for shorter trips and hence Lyft was born in 2012. Lyft has iOS & Android apps with two modes, driver and passenger. Lyft drivers are thoroughly screened, background checked, trained and insured with a $1M excess liability policy. Passengers can use the app to request rides that are tracked by the service, which suggests a minimum donation to the driver at the end. The driver mode notifies drivers of a nearby pickup request and gives them a short time window to accept it before it’s passed to another driver. The whole system enforces use of Facebook for identification to provide some additional security.

 

Track Record

The concept caught on and quickly became the main focus of the company. The engineering team has roughly tripled in size and the growth of the service is only being limited by how quickly they can recruit, screen and train drivers. Whilst they advertise for drivers on services like Pandora, Spotify and Craigslist, they have never marketed to passengers at all, apart from their signature giant pink mustaches on participating cars. Word-of-mouth marketing at its best, straight out of Seth Godin’s Purple Cow playbook. They have hundreds of registered drivers and tens of thousands of passengers in their first city, San Francisco. The company was nominated for three Crunchie awards and named runner-up in the “Best New Startup of 2012” category. According to TechCrunch, they very recently closed a $15M series B round of venture capital funding and have also just launched their service in a second city – Los Angeles. Open job vacancies make it clear they’re planning significant further expansion.

Competition

The disruption of transportation enabled by near ubiquitous smartphone adoption is an opportunity several startups are attempting to exploit. Lyft faces direct competition locally in San Francisco from SideCar, whilst Uber provide a high end alternative and have stated an intention to create a direct competitor in the lower cost segment. Fairly high-profile competitors with similar technology but not yet competing in the same geographical markets are Heyride, HAILO and Taxibeat, although the latter are enabling existing taxis with similar technology rather than encouraging peer-to-peer ride sharing. There is also indirect competition from existing taxi services.

Business Model

Lyft do not monetize their apps directly, it’s free to download and there are no in-app purchases for new features. Like almost all online marketplaces, Lyft make money by taking a cut of the transactions on the market. In this case the transactions are donations from the passenger to the driver. These are entirely voluntary (which gets around legal issues with drivers using their vehicles for commercial purposes) but the app provides a suggested donation and drivers can set a minimum average donation – passengers that don’t pay much/anything are likely to find no-one will accept their requests very quickly.

Lessons Learned

A successful service is much more than an app. The technology only enables the business at Lyft. Sebastian was quick to point out that the key to the success of the company is the operations team, building a community of drivers and passengers. If they’d simply built the technology and put it out there to see who wanted to use it, it’s very unlikely they’d be enjoying the growth they see now.

Projects will expand or contract to fill the time available to them. The initial concept for Lyft was originally scoped out as an 8-week development for a team of 5 (3 engineers, a designer and a product manager). One of the founders, playing devil’s advocate, said “what if you’ve only got 2 weeks to do it”. This forced them to really cut the concept down to a true Minimum Viable Product. They eventually got the first version built in 3 weeks (server and iOS app) – even today there are still several of their original requirements sitting at the bottom of their backlog unimplemented. The things you think will be essential parts of a service can often turn out to be unimportant for real users.

Team chemistry is essential. It would have been impossible to build such a complex service so quickly without fantastic collaboration. The relationships and collaborative working mode are more important than physical location – Lyft has been hiring top talent from around the world and sorting out visas and relocation to San Francisco afterwards. Sebastian was based in London when he was hired, their iOS lead was in Uruguay and the Android lead in Russia (the extreme time difference was sometimes an issue in the latter case).

What’s in the Lyft toolbox?

Like many successful development teams, Lyft use a lot of third party tools to help build their product:

Also, although they have built their own backend service, creating a highly responsive notification system was a challenge they solved with a combination of polling for updates when sending driver location, the Apple Push Notification Service, Google Cloud Messaging and a paid service from Pusher. However, the latter was initially a source of many crashes due to immature client libraries (Pusher only provide official support for a JavaScript client library, other platforms are community supported).

Sebastian’s desire for the tools space was very much in-line with our outlook in the latest developer economics report – consolidation. Fewer SDKs to integrate and fewer monitoring consoles to log into.

King for a day

Finally, if Sebastian could change just one thing about the platforms he works with, what would it be?

Better support for web/native hybrid app development (Lyft explored and abandoned that approach), with the Android WebView particularly in need of improvement, was a close contender but the top of the list for fixing was the Apple App Store review process.  5-10 days of waiting and they can see from their server logs that the reviewer doesn’t even login to the app with Facebook Connect before approving it. There must be a better way.

Categories
Business

How Much Is An Active User Worth?

Revenue per user

App store analytics providers have been telling us that almost all of the growth in app revenues in the last year has been through in-app purchases. However is that just because the model has become more popular? Or because revenue has been concentrating at the top of the market where the strategy is very popular (particularly in free-to-play games)? Probably a bit of both but it’s also the case that subscriptions and in-app purchase do produce the highest overall revenues. If you exclude the developers of top apps (anyone earning over $50k per app per month on average and with over 500k active users) then it turns out that aside from apps that provide enough value to justify a subscription model, the important thing is acquiring users and keeping them engaged. The average revenue for an active user is fairly constant, regardless of the monetization method.

How much do you think is an active user worth? Take the Developer Economics Survey and have your say!

For the purposes of our survey, freemium could be a limited free app with a separate paid version promoted by the free one, or a free app with a premium upgrade via in-app purchase. In-app purchases can be any content, features or virtual goods purchased in the app, which itself can be paid or free. Paid downloads, advertising and subscriptions are hopefully self-explanatory. Note that it’s possible (and indeed quite common) for developers to use multiple revenue models, either on separate apps or within the same app – e.g. freemium with advertising in the free version. The average number of revenue models per developer in the sample above was 1.7. However, if we only look at developers using a single revenue model, the pattern is very similar (and average revenues are lower across the board).

Make the core functionality free if you can

For the majority of developers, an active user is worth around $0.04 per month. All other things being equal, unless you have a sufficient reputation or well known brand association that you can get paid downloads in large numbers, then it’s better to avoid the user having to pay directly for the core functionality of your app. This results in more downloads and a larger user base. Freemium comes out badly here, it seems that the free trial may get lots of downloads but overall slightly fewer active users (and paying users) than a straight paid download. Advertising and in-app purchases had almost identical user bases and overall revenue. Subscription apps had the smallest active user bases but by far the greatest revenue, however, this revenue model requires some kind of ongoing service that is external to the app, which will have associated costs.

In-app purchase beats advertising at the top end

The picture is a little different if you include the highest earning apps. At this point paid downloads fall far behind, both in terms of ARPU and overall user base and revenues. This is not to say you can’t have a very high grossing app with a pure paid download approach (Minecraft is a great counter-example), just that the probability of doing so is much lower. Subscriptions still come out on top but not by so much. The lower ARPU for subscriptions at this level suggests that the top subscription apps have a very popular free tier. Freemium does slightly better than paid downloads for active user base size and significantly better for revenues, suggesting that top quality paid apps with a higher price may sell better with a free trial of some kind. Finally, in-app purchases and advertising both generate the largest active user bases by offering their core functionality for free but a well designed in-app purchase scheme beats advertising for monetization by some distance.

Beware service costs eating all your revenue

In addition to revenue model selection there are also implications here for apps which connect to backend services. The average monthly revenue from an active user needs to exceed the costs of providing the service significantly to make a profit. If the majority of developers are only making $0.04 per user every month on average then say a Kinvey (purely because they price per user for iOS and Android, making the comparison easy) BaaS at $0.03 per user (for 200-5000 users at current pricing) does not leave much for the developer.

 

In-app purchases or ads?  Take the Developer Economics Survey and have your say! You may win awesome new gear.