Categories
Tools

Parse leads with 28% but competition for second spot is heating up as BaaS rises in popularity

As mobile apps become more sophisticated and expand their user base, the requirement for remote storage and user management becomes more important in terms of both functionality and scalability. This capability is usually provided at the backend that manages the application data. Off-the-shelf mobile Backend-as-a-Service can save a considerable amount of time for developers that require backend support for their apps. At the very basic level, mobile BaaS services offer a managed, cloud-hosted database that scales as the user base grows. All BaaS services provide additional functionality on top of this basic layer that may include user management, push-notifications and large-file storage among other.

Backend services used by 14% of developers

Backend services are currently used by 14% of developers, but their use is more frequent among developers working on 16+ apps per year (25%). Backend services are used slightly more on iOS (18% of iOS developers) than on Android or WP (both at 15%), while BlackBerry developers use these services much less (9%), perhaps as a result of limited support among these tools for BlackBerry.

DE13-21-01

Parse in the lead

The clear leader in the BaaS sector is Parse, considered by many as the de-facto BaaS provider and used by 28% of all BaaS users, followed by enterprise-focused CloudMine, used by 11% of developers. Sencha.io and Appcelerator, both commanding a 10% share among developers using BaaS, are solutions that are well integrated with their corresponding development frameworks (Sencha and Appcelerator) and therefore not directly competing with services such as Parse or StackMob. While the BaaS market is crowded, services address different niches that differentiate them among competitors. As a result we have yet to see any service dominating the sector to the extent observed in other developer services such as advertising or user analytics.

While the core features may be common among BaaS providers, there are significant differences and advantages to each of these services that may make the selection easier. For example, exporting data may not be available on all services so if this is a key requirement, then a number of these services can be ruled out. Developers often find BaaS restrictive for their application requirements so several BaaS providers such as Parse, CloudMine, StackMob and Kinvey allow developers to implement custom business logic. However, developers frequently opt for a custom-built backend solution rather than a BaaS for greater flexibility.

Selection criteria

The main selection criterion for developers is, as in most third-party developer services, availability across platforms. However, the richness of the feature set is almost equally important as is the flexibility of the service, e.g. the ability to implement custom business logic. Ease of integration and use, stability and performance are important to 25% of developers using backend services.

Another important aspect of backend services is the pricing flexibility, i.e. the way costs scale with usage. Many developers whose apps experience a sudden surge in user base may find it extremely difficult to scale their costs as usage grows: a free service using a third-party backend that suddenly amasses hundreds of thousands of users will incur significant operational costs as access to the backend rises with the number of users. Developers should keep this in mind when designing their apps and backend service providers should aim to align pricing strategies with developers’ business models.

Backend features

We asked developers using backend services to highlight the most important feature for them. 28% (of developers using backend services) indicated data management and 18% indicated user management and authentication. Next most important features are push notifications and content management highlighted by 11% of developers using backend services. Less important features include analytics (9%), file storage (7%), cloud code (custom logic) (6%) and social graphs (3%).

The backend service sector is relatively young and expected to grow as developers familiarise themselves with such services and realise their potential. At the same time, there is much room for improvement as BaaS providers better understand and adapt their services to developer needs such as flexible and customisable business logic.

[doritos_report location=’DE13 Article – BaaS’]

Which BaaS services 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.
  • In this graph, “Other” was removed as a possible answer. A lot of respondents used the “Other” answer to indicate that they use an in-house solution, which is not a “Backend-as-a-Service” at all.[/toggle]

    Find the best BaaS service for you!

    [sectors slugs=’backend-as-a-service’]

Categories
Tools

Advertising is the most popular developer service, AdMob dominates (65%)

Advertising is the most popular developer service

Among those developer services that we benchmarked the most popular is ad networks and exchanges, reflecting the widespread popularity of advertising as a revenue model. Advertising is the most popular revenue model, while ads can also act as a promotion channel that facilitates app discovery.

With advertising being the most widely used revenue model among developers, advertising services attract considerable developer interest taking the top spot among the developer tools that we benchmarked. Providers of ad services monetise their service by taking a direct cut of advertising revenue generated by developers. With 100+ ad networks and exchanges, there is intense competition, regional specialisation and niche solutions. In spite of this, several ad services are not profitable.

The services we benchmarked are either advertising networks that provide direct access to their own pool of ads or ad exchanges (aka mediation engines, not real-time bidding exchanges) that act as aggregators, automating access to a large number of individual ad networks. Ad exchanges offer some flexibility to developers by allowing them to select between multiple ad networks through a single SDK – offering better fill rates and eCPMs. At the same time, ad network SDKs often provide access to more features available, than the generic features available through an ad exchange.

Ad services are most popular with Windows Phone and Android developers

Among developers using Ad services, 27% use an exchange, however, just 16% utilise an ad exchange as their primary ad platform. Most developers using ad services use just one service (61%), 25% use two services and 14% use three or more services. Overall, developers use 1.59 services on average. There is quite a large variance in the number of developers using ad services depending on the scale of development: those developing less than 5 apps per year tend to use ad-services much less than those developing more than 5 apps per year. Among developers that develop more than 16 apps per year, most likely working for large publishing houses, software services companies or agencies, about 60% use ad services in their apps.

Ad services are most popular with those who develop primarily on Windows Phone and Android (46% of WP developers and 43% of Android developers), and less so on iOS and BlackBerry (35% and 31% respectively). This is in agreement with our findings on revenue models being used on each platform, with developers on Android and Windows Phone relying heavily on advertising to monetize their apps.

DE13-16-01

AdMob dominates ad networks (65%) and Inneractive leads among ad exchanges (12%)

AdMob, a service acquired by Google in 2010 is clearly the dominant platform in mobile ad services, adopted by 65% of developers that use ad services. AdMob has recently expanded to ad exchange services, a move that aims to counter the threat that ad exchanges pose for Google. Second runners, each used by 12% of developers, are Inneractive, an ad-exchange/mediation service and InMobi, an ad network growing out of India to become a major player in emerging markets: InMobi’s mindshare is 17% in Asia and 33% in Africa. Apple’s iAd service comes fourth overall with 11%, and despite being quite popular among iOS developers, AdMob is the leading ad service on iOS, used by 66% of iOS developers that we surveyed.

Ad exchanges are complementary to ad networks. For example, developers will use one service with high eCPM but low fill rate and another with lower eCPM but nearly 100% fill to plug the gaps in the better paying service. When selecting an ad network or exchange, availability across platforms comes on top in both cases. Ease of integration is also very important, particularly so for developers using ad networks. Supported ad formats, revenue potential and fill rate are secondary selection criteria, and therefore differentiation factors across advertising services.

[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 ad service for you!

    [sectors slugs=’ad-networks-exchanges’]

Categories
Business

Does Cross-Promotion Work?

App cross promotion

The concept of app developers banding together and promoting one another’s apps in order to increase awareness and download numbers for all concerned makes a lot of sense. Beyond developers promoting their own apps, or a couple of friendly developers getting together and agreeing a deal between themselves, it can get difficult to decide what’s fair with the wide variation in active user bases and engagement across apps. This suggests there’s a clear place for independent brokers to step in and create a market, which a large number have done. Some solutions offer direct trade in promotions between apps but most are simply app-specific advertising networks, charging developers to advertise and paying them for displaying ads. They key difference with pure ad networks is that ads are tracked right through to subsequent install (and sometimes app open) before any payment is made, rather than just a click on the ad.

When viewed as just another form of advertising, with a cost-per-action model, in theory this should work out fairly well for developers. User acquisition costs are predictable for advertisers and those displaying ads have reasonably good targeting built-in before any extra targeting logic used by the cross-promotion network – everyone viewing the ad has a smartphone and downloads apps on it! How does the theory work out in practice?

[sectors ids=’45’]

More users, more revenue

On average developers using cross-promotion networks (CPNs) have larger user bases and make more revenue than those not using such networks. Restricting our analysis to those developers interested in making money, able to report their revenue to us and earning less than $50k per app per month (the handful earning more than this will be discussed later): the average number of active users for the most popular app of those using CPNs was 181,800 vs. 76,600 for those not using CPNs. For the same groups, the average revenues were $3457 vs. $2487 per app per month respectively. As with most things related to the apps market, averages can be deceiving – 56% of developers using CPNs earn less than $500 per app per month. So while cross-promotion clearly works, the better question is who does it work for?

Higher CPI, more users & revenue

We asked developers using CPNs what their typical cost-per-install (CPI) was, without differentiating between usage of the networks as an advertiser, publisher of ads or both. Given this lack of differentiation it’s interesting to note that there’s a strong correlation between CPI and revenues, as shown in the graph below.

It’s also interesting to note that when you include the very highest earners, only $0 install costs and those above $1 are affected. Presumably very successful developers can and do effectively use some of these third party tools to cross-promote their own apps. Whilst it’s extremely likely that only those developers earning high ARPU (and thus almost certain higher than average revenues too) can afford to buy users at >$1.00 per install, it’s not at all obvious that those earning a higher CPI would be earning more revenue in total. Indeed with pure ad networks the reverse is almost true – high earners often have very low eCPM. This suggests two possible explanations, either there is a “high value” end of the market for cross-promotion where successful apps both advertise and publish ads, or only advertisers are making good money and the CPNs are taking a large cut.

High value customers, high value promotions?

Within our survey data there’s a clue that such a high value sub-market exists within cross-promotion networks. We asked developers about their reasons for selecting the networks they use; of all the reasons given, only two were correlated with significantly above average earnings for the sector. Both “Revenue share”, a publisher concern, and “Targeting options”, an advertiser feature, were correlated with more than 2.5 times the sector average revenue. A lot of the very low revenue apps using cross-promotion appear to be primarily targeting a low-income demographic (teenagers) who are unable to buy paid apps or in-app purchases directly and are therefore willing to earn them by either watching ads, downloading other apps or performing actions within them. It’s logical that these apps don’t generate a lot of revenue for publishers or advertisers. On the other hand, apps targeting more affluent users who do pay real cash for their app usage will be attractive cross-promotion partners for developers of other similar apps.

This really just comes down to basic business sense – if you want to make a decent amount of money, build things for people that have it to spend. It’s possible to make up for very low ARPUs with volume but it will require lots of apps and lots more work. Whichever route you decide to take it appears that cross-promotion is a viable monetisation option. If you’re aiming at low-ARPU users it may be that cross-promotion networks are your only advertising option but you’ll also need to find other marketing channels to get enough scale.

[doritos_report location=’DE13 Article – Does Cross-Promotion Work?’]

Categories
APIs Tools

Which apps make more money? App monetization insight from our Developer Economics 2013 report

[This post by Andreas Pappas, Senior Analyst at VisionMobile, first appeared on the VisionMobile blog on April 3, 2013.]

[How do app developer revenues vary by country, or platform? Does the number of platforms make a difference to app revenues? Which models bring in the most revenues? We revisit Andreas Pappas’ November analysis of app monetisation with more insights from our Developer Economics 2013 survey across 3,400+ developers – while launching our latest survey, which is available here]

Developer-Economics-volume-5

Back in November, we looked at which apps make money based on research on how app revenues vary by platform, app category, country and more. In this article we update our analysis on app monetisation based on the latest research from Developer Economics 2013 across 3,400+ app developers, including analysis that did not make it into the report.

We ‘re also proud to launch our very latest Developer Economics survey, which reaches across thousands of app developers and provides the data for our famous state of the developer nation reports. Thanks to the sponsorship by BlackBerry, Mozilla, Intel and Telefonica it possible to provide these reports and additional insights, for free, to the entire mobile community.

Take part in the survey, spread the word and help us drill deeper into the app economy and what makes it tick. We have prizes aplenty for developers, with 7 devices up for grabs (one iPhone 5, two Samsung Galaxy SIII, two Nokia Lumia 920 devices and two BlackBerry Dev Alpha handsets) – plus an AR Drone 2.0, a Nest Learning Thermostat and a Nike Fuel Band for participants who also subscribe to our developer panel. Last, but definitely not least, our friends at Bugsense are giving away one month of free crash reporting to each and every participant.

Survey Q1 2013

 

Developers in North America lead the revenue leaderboard

We’ll start by taking a look at income distribution by the region where app developers are based. Last time we saw that US developers earned almost double the revenue of UK developers. Based on our Developer Economics 2013 data, North America (and particularly the US) is still in the driving seat of the mobile app economy with developers in North America generating about 30% more than their european counterparts, who in turn generate 47% more revenue than developers in Asia. To some extent higher revenues for NA developers are explained by higher consumer spending in the US and higher penetration of iOS, which as we will see later on, still generates higher revenues than other mobile platforms. Note that across this analysis we are restricting our sample to mobile app developers, and have excluded the top 5% of revenue earners in order to minimise the effect of outliers.

North America leads app revenue leaderboard

While app development activity is booming in Asia, the average app-month revenue is quite lower than in the US and Europe, although developers in Asia develop, on average more apps and use more mobile platforms. As we explained in the previous article, there are multiple reasons for this revenue gap, but the prevailing reason is the fact that paid apps are not popular in most of Asia, the country that drives the Asian app economy. Instead, developers in Asia rely much more on advertising revenue, which, according to our findings is the least profitable revenue model.

iOS still monetising better than other platforms

iOS continues to dominate platform revenues, generating, on average, 30% more revenue per app-month than Android. The revenue gap has reduced by 5 percentage points compared to that reported in our Developer Economics 2012 report in June 2012.

iOS continues to dominate revenues

At the same time, Windows Phone has caught up with Android and seems to be doing slightly better. Although the 5% advantage is arguably within the margin of error, Windows Phone has significantly improved its position relative to the figures reported in the Developer Economics 2012 survey, when it generated, on average, about half as much revenue as Android. How has the landscape of platform monetisation changed in Q2 2013? Join the survey and help us track the state of the developer nation.

Multi-platform developers earn more

Developers using more platforms earn more

There is a wide revenue gap between developers/publishers using 6+ platforms and those using 5 or fewer platforms, with those developing for 6+ platforms generating, on average, 75% more revenue. However, only a small part of the developer population (4%) develops on 6+ mobile platforms; these are probably established services with a large footprint that want to ensure that their apps are universally available (e.g. Facebook, Skype etc.) or large software houses with a large enough pool of resources to target multiple platforms for their customers.

Those developers employing just one platform are probably solo, amateur developers or have not yet had the success that warrants (and allows) an expansion onto more platforms. As developers become more successful, they will expand onto new platforms and generate more revenue. So while, expanding on more platforms is not sufficient to generate more revenue on its own, those that do find success are likely to invest in a multi-platform strategy.

Extending apps to new markets is a profitable strategy

We asked app developers how they decided on which apps to develop or work on next and then looked at the way revenues vary depending on their strategy. While most developers will develop apps they want to use themselves (50%), this is apparently the least successful strategy and should not become the sole deciding factor for your next app.

Extending apps into new markets pays better

Developers that use some form of market research such as discussing with users, monitoring apps stores or directly buying market research are much better off, generating at least double the revenue of those who just develop the apps they want to use. However, market research is not widely used among the developer population: only 24% of developers discusses with users, highlighting a lack of business maturity and also a gap in frictionless 2-way communication channel between developers and users.

Overall, the most successful developers are those that extend apps to new markets, either to new geographies or different verticals. To some extent, these strategies rely on copying the recipe of an already established and successful business: these are apps that have been tried and proven in at least one market and are generally less risky options or “low hanging fruit” for developers. Why start from the ground up when you can stand on the shoulders of giants?

The most lucrative revenue models are off limits for most developers

When talking app monetisation, there are over 10 different revenue models to chose from. Device royalties and distribution licensing fees are the top-grossing models but are quite rare among app developers due to their high barriers to entry. These models imply deals with device manufacturers and distributors which means long, expensive sales cycles and a successful app to start with. Among the rest of the revenue models, commissioned apps (development for hire) come on top since they come with a low risk and guaranteed income for developers that work under contract.

Royalties & licencing fees pay better

The next most lucrative revenue model is the subscription-based model but this also comes with caveats: a subscription service implies a significant investment in licensing, and maintaining quality content or services that keeps users engaged on an ongoing basis.

Among the revenue models that are most popular and more accessible to developers, In-app purchases come on top, generating, on average 34% more revenue than Freemium and 43% more revenue than Pay-per-download. In-app purchases and Freemium models are becoming increasingly popular, now being used by a quarter of developers as they seem to be appealing to consumers. We ‘re revisiting the topic of most lucrative revenue models in our latest survey. Join in and help us size the app economy.

Smart developers use smart tools

Finally, we take a look at how developer revenues correlate to the use of third party tools and services. It’s interesting to see how app revenues correlate with usage of performance tracking and management tools like user analytics and crash reporting. Developers using crash reporting and bug-tracking tools such as Crittercism or BugSense generate on average, three times more revenue than developers who don’t use these. Similarly the usage of User Analytics (e.g. Flurry, Apsalar) services is also associated with much higher revenues, with those using user analytics services generating 168% more revenue than those who don’t.

Higher revenues for developers using dev tools

Both user analytics and crash reporting services are used by experienced developers who recognise the importance of optimising for user acquisition, activation and retention, while reducing in-the-field crashes and the resulting user churn.

Track the state of the developer nation

[tweet_this content=’App developer? Take the new Developer Economics survey and win prizes!’ url=’ http://www.visionmobile.com/DS13PortalBlog’]These insights are made possible by our ongoing surveys. Join the latest Developer Economics survey to help us draw deeper insights into monetisation, the size of the app economy and the debate of HTML5 vs. native. In this survey we ‘re focusing on the population of iOS, Android, WP, BlackBerry and HTML5 developers, across countries, app categories and developer types. If your are a developer take the survey, or otherwise spread the word and watch this space for an update on revenues, platforms and the state of the developer nation.[/tweet_this]

And don’t forget to fire away with those comments, rants, criticism, praise or simply feedback on what you ‘d like to see next.

Andreas (follow me on twitter @PappasAndreas)

Categories
Tools

Capturing More Value with Voice Services

Voice Services

Of the tools and services for developers we asked about in our last survey, one category stands out by miles as having the wealthiest developers: voice services. If we exclude developers earning over $50k per app per month (as we typically do for other tools categories since a small number of successful developers can heavily distort the data) from those interested in money and reporting their income to us, then those using voice services earn an average of $4379 per app per month. This is a similar level of revenue to those using crash analytics services, which we’ve already shown is correlated with financial success. However, excluding those earning over $50k per app per month is rather unfair for voice services since this is almost 10% of developers using this tool category; if we include them, the average rises to $13410 (the comparable figure for those using crash analytics is $8764). Of course there’s a lot of variety in the voice services sector and the revenue is not at all evenly distributed.

Popular is not always profitable

In order of popularity, the most used services in our survey were Twilio, Skype, Mircrosoft & Tropo. Of those, the best in terms of revenues, Tropo, had 77% of developers above the “app poverty line” of $500 per app per month, whilst the worst, Microsoft, had 77% earning below that level of revenue. Outside of the top four services by popularity, there was a wide range of developer success but the average revenue was very close to the average for the whole category.

Skype is an extremely popular consumer service but their services for developers, particularly mobile developers, are quite limited in scope. SkypeKit, which is their offering for embedding Skype functionality in devices and other apps is not permitted to be used in mobile devices. Although Microsoft has similar capabilities to Twilio and Tropo through their acquisition of TellMe that is not yet fully integrated into their standard developer offering. If they try to use their capability to differentiate the developer offering for Windows Phone then it’s likely to remain limited by the success of their mobile platform.

Isn’t voice commoditised?

Whilst having voice services tied to a single platform is not ideal, cross-platform availability is not critical. Developers whose main reasons for selecting their service included cross-platform availability earned a below average for the sector but still very respectable $8120 per month. Those focused on call quality did slightly worse, while developers whose primary concern was cost did very poorly at only $2280 per month on average. At the top end of the spectrum, the only reasons correlated with revenues above $20k per month were feature set and scalability. The feature set breakdown in our survey makes it much clearer where the bulk of the money is being made by users of voice services. Fortunes are not being made by delivering generic VoIP services to giant user bases; in fact, the average number of active users for the most popular apps of developers across the whole voice services sector is only about 27,000. On the contrary developers using voice services for inbound calls averaged $25k per app per month, while those using intelligent call routing and/or Interactive Voice Response (IVR) systems averaged $30k per app per month. While it is possible that there are some developers doing good business using these cloud services to replace legacy IVR services or extend the reach of such services to smaller businesses, it’s very likely that many of these developers are building customer services channels for their own apps. In this case there’s some survivorship bias here – only fairly large and successful businesses would build out such complex customer services systems. Also it’s quite likely that businesses that need voice and SMS based customer service channels are about more than just an app, in which case the revenues associated with the apps may reflect sales of external goods, services or content and are thus not directly comparable with those of developers purely monetizing through paid downloads, advertising or in-app purchases (although all of these revenue models are used by some developers using these voice features).

Consider the costs

When you consider that numbers rented, call minutes and SMS’s sent all have associated costs from the voice services provider it’s not so surprising that a typical voice services developer has higher revenues – they need to in order to stay in business! The existence of these voice platforms is strong evidence that basic voice is commoditised and there’s very little room for differentiation or profit simply packaging and branding such services for consumers. So, while the revenues for all kinds of voice app are higher than average, the associated costs are higher too. Those developers that capture significant value with voice services are using them to add value to some other service, rather than trying to re-sell them directly. That said, these services are very easy to use and relatively inexpensive. It’s worth thinking about ways you could use them to build better relationships with the customers for your app business.

Categories
Tools

Voice on the verge of break-through? Going beyond telephony with Voice Application Platforms

Voice communication is one of the core functionalities of every mobile phone. However, telephony is up for a big shake-up, as Internet telephony companies like Skype and voice application platforms like the ones below are challenging century-old assumptions about how people speak with each other remotely. (You can read all about this trend on the VisionMobile blog: here and here.)

Indeed, voice is no longer the domain of telecom operators alone. Voice Application Platforms allow you to make creative solutions that integrate voice communication deeply in your app: as voice messaging, click-to-call, person-to-multiperson, voice search and more.

Voice platforms cater to many use cases

Voice APIs allow developers to integrate voice functionality within their apps, bypassing the telco services that traditionally provided these capabilities. Developers use Voice services to enable a number of use cases such as voice calls, conference calls, video calls, voice transcription, IVR services etc. Telcos such as AT&T and Verizon are reacting to this trend (for over-the-top services) by opening up access to their services via APIs.

While Voice services cater to a number of different use cases, their use is relatively low among developers because, contrary to other tools in the Developer Economics 2013 survey, they are specialised tools that provide functionality within an app rather than support for the app or the business (as, for example, user analytics or ad services).

The different services surveyed cater to a different mix of use cases, and therefore do not always compete against each other. Developers integrating voice services in their apps tend to use them primarily for enabling voice call capabilities within their apps, including Conference calls (33% of developers utilising Voice services), Outbound calls (29%), and Inbound calls (24%). About a quarter of developers using voice services, are interested in Speech recognition while 20% use them to implement IVR applications. Callback function is also quite popular as indicated by 20% of developers utilising using voice services.

DE13-17-01

Skype (39%) is leading, with Twilio (31%) following

Skype leads in developer mindshare when it comes to voice services, used by 39% of developers that integrate Voice services within their apps. However, Skype does not provide services through an API but rather through URIs that redirect the user to the Skype client which must be installed on the user’s device. Developers using Skype use it primarily for conference calling (55% of developers utilising Skype), Video calls (43%) and Outbound calls (37%).

Twilio follows at a short distance, utilised by 31% of developers implementing Voice services. Twilio API allows developers direct access to voice services within their apps. Twilio users mostly use the service for Outbound and Inbound calls (43% and 41% of developers using Twilio respectively).

Microsoft Voice services, used by 27% of developers using Voice services, use it mainly for Speech recognition (44% of Microsoft voice services users) and Speech transcription (30%). Telco APIs such as those provided by AT&T and Verizon are less popular (17% and 10% of developers using Voice services), while OneAPI, a joint attempt by telcos to react to the OTT threat, seems to fall far behind at 4%. The AT&T API is mainly used for Conference calls and Callback (36% and 32% respectively). The latest AT&T Call management API, powered by Voxeo Labs Tropo Platform, allows users to link their cellphone number to OTT Voice services provided via AT&Ts API, negating the need for a new phone number. Tropo, by Voxeo Labs is used by 5% of developers using Voice services and is mainly used for Conference calls (50% of developers using Tropo), Speech recognition (41%) and IVR applications.

Quality is still key selection criterion

Most developers (39% of those using voice services) highlighted performance and quality as a top selection criterion for Voice services. Voice quality is not guaranteed on mobile data networks but is critical in most use cases where voice services are used, particularly in real-time voice such as conference calling. While network quality is often out of the direct control of voice services providers, there is still a lot that can be done on the service providers’ side such as optimising encoding algorithms and scaling the architecture of their voice infrastructure. Ease of integration and availability across platforms, the prevailing selection criteria among all third-party tools and services are also important when selecting a Voice services, as highlighted by 35% and 34% of developers using Voice services, followed by cost (27%).

[doritos_report location=’DE13 Article – Voice platforms’]

Which voice services 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 voice provider for you!

    [sectors slugs=’voice-platforms’]

Categories
Business

Backend-as-a-Service Economics

BaaS

There are a wide variety of products that can be considered Backend-as-a-Service (BaaS) offerings. At the time of writing we list 43 of them on our sector summary page. We have previously discussed whether or not they’re a good idea and how much development effort you could save by using one. In our most recent survey we asked developers about their use of some of the most popular options. By comparing developers’ use of BaaS with their average revenues and active user bases, we can determine how well these products are working for them.

BaaS, what’s BaaS?

An interesting point to note is that a lot of developers don’t appear to know what BaaS really is yet, suggesting there’s plenty of room for growth in this sector. Almost 20% of the developers in our survey who indicated they use BaaS solutions said they were using their own proprietary backend; this is just a backend service and not BaaS, since it is built in-house rather than re-using a more generic backend solution from a third party. We exclude all of these people from this analysis. Technically it’s only really BaaS if the provider hosts it for you too, although we include options like Deployd, which is an open source project that combines with a PaaS offering like Heroku to give all the features of a BaaS (and more flexibility).

[sectors slugs=’backend-as-a-service’]

Show me the money!

Developers using BaaS solutions have an above average interest in making money. Only 11% of BaaS users were not interested in money vs. 20% of non-users. This is probably because the costs of running any kind of backend service are a deterrent to hobbyists. Of the remaining developers who are interested in making money (excluding those who were unable to report their revenues, or earned over $50k per app per month) 43% of BaaS users were earning more than $500 per app per month vs. 31% of those not using BaaS. The average monthly revenue for BaaS users was $3223 vs. $2482 for non-users. So, developers are more likely to earn enough to cover the costs of running a backend if they use a BaaS and also earn more than enough extra revenue to pay for hosting/service costs on average.

More backend features = more revenue

Not all BaaS solutions have the same feature set. The more comprehensive offerings typically have user, content and data management, along with push notifications, social integration and some kind of location data support built-in; most are also able to be extended with custom code. Less complete solutions generally only offer a small subset of this feature set, with different vendors providing different subsets. Some services are well integrated with cross-platform tools (e.g. Appcelerator Cloud Services and Sencha.io) and although they are quite comprehensive, their results appear to be more influenced by the CPT itself than the use of the BaaS – that said, users of these services also make more revenue than other users of the CPT, with Sencha coming out significantly ahead of Appcelerator in both cases. Finally, Deployd and Apigee Usergrid offer more flexible/configurable options, where users can add features from a fairly comprehensive base.


As can be seen from the graph above, users of the more comprehensive BaaS offerings make significantly more revenue than other BaaS users. On average their active user bases are only about 20% larger, so it seems the more feature rich backend services are translating to higher value generated for end users.

Which features are most important

We also asked developers which features were most important to them when selecting a BaaS. The majority of users were interested in user management and data management, features available in almost all BaaS offering and thus unsurprisingly correlated with approximately average revenues. Those primarily interested in using a BaaS for push notifications or file storage had almost half the average revenues (these are fairly easy to achieve without the overheads of a BaaS, possibly indicating a lack of sophistication) while those interested in content management made about 50% more than average and those most interested in analytics more than double the average. This outperformance for developers focussed on server side analytics mirrors that on the client side, suggesting it’s the developers’ approach and not the feature itself with produces the improved results.

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.