Category: Business

Categories
Business

Prototyping: needless effort or driver of perfection?

Mobile apps are becoming more and more sophisticated every day. They evolve together with mobile devices, giving us even more pleasant, intriguing and unique experiences. Design, usability, functionality accompanied by various touch interactions, animations, and transitions are integral components of apps.

Building an app is not easy. It involves various stages in a long development life cycle. Apps require time to build, time to test, and time to iterate for improvements. Iterations are not easy especially when extensive code changes are required and that’s where usually things get messy.

There is one solution to avoid the trap that lies ahead when developing apps: prototyping. A prototype is an early sample or model built to test a concept or process, or to act as an object to be replicated or learned from. The prototyping step is often skipped due to the extra cost and effort it adds to the lifecycle of a project. However, it is widely accepted in the development world today, that undermining this vital part of the design and build process may lead to miscommunication between developers and clients, pitfalls, over budgeting, and bad quality products. Prototyping allows developers to conduct proper user trials, iterate before coding and send the app to production only when it is perfected.

Graphic designers, user experience designers, usability experts, interaction designers, and developers use different ways and tools to create prototypes. The most popular methods used for prototyping apps are paper prototyping, presentation software, mobile apps (usually for tablets) designed to allow people to prototype mobile applications on actual mobile devices, source code and prototyping applications and tools either web (offered as SaaS) or desktop apps.

In the following section I will briefly describe the prototype tools vendor landscape and the main needs that these tools serve.

Vendor landscape

If we ignore for a moment the paper prototyping and source code, where no specific tool is used, then we are down to three main types of prototyping tools: presentation software, mobile apps and mobile prototyping applications.

prototyping-tools-landscape

Presentation software like Keynote or Powerpoint, are in the market for decades and peeple are well trained to use them in different ways. The way people use them for prototyping, is by linking sketches, or design comps together in a presentation since such tools support animations and screen transitions. Some UI libraries like Keynotopia have UI components of popular mobile operating systems like iOS and Android, designed for presentation software. Presentation software are built for an entire different purpose and they are limited in prototyping functionality but are still valid in some user cases. Diagramming software like Omingraffle and Gliffy are sometimes also used for prototyping.

Mobile apps for iPad and Android tablets designed for mobile prototyping allow real device testing which is their main advantage. Some of these apps provide UI libraries of major mobile UI components like App Cooker and Interface HD. Others, like Popapp allow taking photos of sketches and linking them together. Most of these apps are limited to single device prototyping and usually lack sharing and collaboration tools but are very useful when it comes to quickly validating an idea.

Mobile prototyping applications are web or desktop applications designed specifically for mobile prototyping. These applications vary from simple traditional wireframe applications (including mockups) to advanced prototyping tools that are able to provide a varying degree of mobile-specific functionality such as touch events and gestures, interactions, screen transitions. Most importantly these tools provide the ability to preview a prototype on the actual device.

There are three different types of such mobile prototyping applications:

  1. Hotspot apps are usually web apps that allow you to upload your mobile design comps and link them together usually with a single event (click or touch) without (or at best simple) transition effects. These apps are useful especially for collaboration as most of them allow comments and annotations. Although some of these tools make real device preview possible (i.e. preview on the actual device that the app is built for), they are not really eligible for proper user trials as they do not allow multiple interactions such as touch gestures and other important mobile specific features. Applications in this category are Fieldtest app, Invisionapp, Popap and are usually web apps offered as Software As A Service or mobile apps for tablets and Smartphones.
  2. Wireframe or Mockup tools are tools that allow the development of still wireframes or mockups. Usually these tools have a large number of UI components libraries available. Some of these tools have been in the market for years as they were designed for website mockups or wireframes, but many of them have been changed in an attempt to embrace needs specific to mobile apps. Many of these tools are very advanced in functionality and features, offering a range of useful companion tools for collaboration and more. Most of these tools are limited to single tap interaction (or mouse interactions, as they are designed for web sites) and no or limited animations and transitions. Tools that fall under this category include Balsamiq, MockingBird, UXpin, Pidoco and others and they can be found as web apps available on a subscription basis or as desktop apps.
  3. Prototyping tools are web applications or desktop software designed from the ground up and specifically for mobile (or web) prototyping. These applications go beyond traditional wireframe or mockup applications, to provide functionality for mobile touch events and gestures, interactions, screen transitions and most importantly provide the ability to preview a prototype on the actual device. Many of them come with UI libraries for iOS, Android, Windows mobile and Blackberry and offer collaboration tools and functionality. Tools and software in this category include Axure, Indigo Studio, Proto.io and many more.

[sectors slugs=’prototyping-mockup’]

Current challenges with prototyping tools

Prototyping tools are still in their infancy. They have been around for two years or less must be in sync with the ever changing mobile industry. New mobile devices become available on a daily basis, new versions of mobile operating systems and new functionality that needs to be supported makes the chase even more difficult. The main challenge is the ability to test the prototypes on the real device. In order to achieve this more tools render their prototypes in HTML5 so that they can run on a native mobile browser without the need of installing and maintaining various mobile apps.

Another major challenge is performance and by using HTML5 features such as animations render much slower on a mobile browser than they would on a native app, making the experience a bit far from real and as such defeating the purpose of doing a full prototype in the first place. Nevertheless, some of these tools have reached a maturity level that allow professionals to create fully functional, interactive mobile app prototypes of their apps that look and behave exactly as their app would. This allows the teams to conduct user trials, gather feedback, and iterate for improvements. Furthermore, a proper prototype narrows the communication gap between designers and developers (coders) as well as with the app team and the stakeholders.

Future opportunities with prototyping tools

Prototyping tools gain larger audiences as mobile technologies progress. As mobile apps become more sophisticated, more detailed prototyping is required. The mobile market grows and the prototyping tools market will continue to grow with it as more Operating Systems and newer more capable devices are released. New devices come to life every day, from car navigation systems to refrigerator panels, all having in common touch and interactive interfaces.

Categories
Business Community

The state of App Search Optimization (ASO)

The reason why ASO is getting so much attention right now is because in today’s charts-driven app stores 10% of apps gets 90% of downloads. For developers, the only effective mechanism to catch attention is buying large amounts of app installs to catapult their app into the top 25 charts where people look for inspiration. But this approach has become very expensive as app install prices soar.

Indie developers who have limited resources struggle to compete and get their app in front of users’ eyes. At XYO, our goal is to change this and enable long-tail app discovery by helping users discover what they want even though they can’t express it. To build our site XYO.net we looked into search behavior to understand how people find apps. What we learned is that the majority of users has no real concept of how to search for apps and no idea about the vast supply of great apps out there, because they can’t see them.

The Super Early Days of ASO - A SImple Model To Compare SEO and ASO

To optimize for search it’s important to understand how users are searching. On the web, there is SEO as a proven tool for which countless SEO companies provide rich insights, and tracking success is easy. For mobile apps however, it’s mostly guesswork. “These are the super early days of ASO”, said Tomasz Kolinko founder of ASO specialist Appcod.es. App Store Optimization (ASO) at the moment boils down to optimizing a list of keywords for queries that users are likely to type.

So how do users search? Based on our data on XYO.net and by looking at the publicly available studies by Chomp (acquired by Apple last year), we have identified four types of users in app search.

Our main findings conclude that app search is dominated by vaguely expressed intents and very generic queries. Users are inexperienced in how to find apps and have difficulties navigating cluttered app stores.

80% of user searches are generic category or interest searches

XYO Insights - types of search queries

Most app searches happen with only a generally expressed intent. The majority of users (around 75%-80%) type general app categories into the search box. Examples of such categories are ‘social networking’, ‘education’ or ‘racing games’. Our findings are consistent with what app search company Chomp was publishing in its Monthly App Search Analytics study.

Around 10%-15% of all search queries look for simple inspiration: These users either type ‘games’ or ‘apps’ into the search box or add adjectives like ‘new’, ‘free’ or ‘fun’. Examples of such queries are: ‘addictive games’, ‘fun games’, ‘free apps’, ‘new apps’.

Only 5% of all users seek specific app brands or titles. Our data and other sources indicate that while some users are aware of mainstream brands like Angry Birds or Facebook, other mobile brands are mostly unknown.

For apps there is another category: functional app searches where the query describes what the user wishes to achieve. Examples of such searches are ‘crop photos’, ‘block calls’, ‘view movies’. Those functional queries are super important for classic web-based SEO – in mobile app search they are marginal at around 5% of searches.

Image: http://www.flickr.com/photos/jurvetson/5314774452/
Image: http://www.flickr.com/photos/jurvetson/5314774452/

Optimizing search for users who don’t know how to search

App Store search is based on app title and a keyword list. For Google Play the app description also counts, which opens up more opportunities for developers to add seasonal or trending keywords (e.g. ‘easter’ or ‘gangnam style’).

In general, it’s advised to use a keyword tool such as appcod.es, MobileDevHQ, SearchMan , and appnique.com. These tools give an idea of keywords competitors are using and where the sweet spot of high search volume and low competition lies for a specific app.

[sectors slugs=’app-store-optimization’]

“Longer phrases are 70% of search volume on the web (indicator), they’re less competitive, and probably see higher post-click conversion (download) rates because the user explicitly searched for ‘free video poker game’, Niren Hiro, CEO at SearchMan told us. His conclusion: Developers can take steps to get the No. 1 rank under each of their ‘long tail’ keywords. That is, developers can optimize their rankings for keywords that will give them better results on the App Store when users go searching for certain kinds of apps. Optimizing for the long tail is key, because generic keywords will have high search volumes but a lot of competition and often lower conversion.

“We go from low(er)-volume, high-conversion keywords (such as ‘golfcoaching’), all the way to what we call secondary and tertiary market keywords, like ‘coaching’ or ‘sports’. Conversion for branded and function searches are likely to have higher conversion rates than inspiration or interest searches – and interest searches may have even better conversion rates than inspiration searches,“ explained Patrick Haig, VP, Customer Success  at MobileDevHQ. If history from the web will repeat itself, then it will become cumbersome for users to browse results, and they will start entering more descriptive phrases to get relevant results fast.

Apart from optimizing the keyword list, an app’s title is of utmost importance. We recommend including the most important keywords in the title to get found.

Showtime: App description and screenshots increase conversion

When users browse search results, two things matter most to increase conversion: app descriptions and screenshots. Over and over again we see the first three lines of description wasted by developers babbling about achievements that are meaningless to new users. Sure, a “Game of the Year” award is great news – but it’s secondary information as long as users don’t have a clue what the game is about. That’s why the app description should explain what the app does in the first 2-3 lines. Bullet points can be used if necessary, as well as precise and short copy. Later in the text authoritative reviews can make sense to build trust, especially for Android where this text is also indexed for search. “For Google Play, it’s even better if you can include reviews that include targeted keywords,” said Patrick Haig.

Screenshots have gained relevance significantly and are a popular medium for developers. Users rely on screenshots to see if they like the look and feel of an app they’re about to download, and –again– to find out what this app actually does. Jai Jaisimha CEO at Appnique: “Moment of truth: iOS6 design increases importance of the screenshot because that is mostly what they see in the App Store client on the phone.” That’s why adding explanatory text is useful – and developers should get creative about it. Patrick Haig: “Treating screenshots like a stop-motion commercial can be powerful.”

Reviews turn users into app ambassadors

Once a user has downloaded an app, ratings become priority because they are crucial for ranking: “We have an article here from Inside Mobile Apps that illuminates how important ratings are, segmented by each store (Google Play and iTunes). Also, it’s becoming even more important for publishers to improve upon their current version rating, as that’s the only rating seen by a searcher in-device (i.e., searching on their iPhone or iPad). Users have to dig in order to see the All Versions rating, which just doesn’t happen,” Patrick Haig from mobiledevHQ told us.

Source: http://imgs.xkcd.com/comics/star_ratings.png

Though important, ratings are not that meaningful to base a download decision on: The average rating is 3.8 making it difficult to see the nuances within the star rating system. To increase conversion, internal and external reviews are getting more and more significant. Being proactive in asking for reviews can save a lot of pain: Prompting users for feedback makes them convey a problem before they post a negative review, recommends Appnique.

Conclusion

At the moment, a big trend in app store optimization (ASO) is trying to overcome the obvious discovery problem by stuffing app’s titles with keywords, longer descriptions or almost complete sentences. The race for the best phrases keywords is in full swing. Obviously user experience will suffer in the process if keyword optimization will be used too excessively by a large number of developers. A backlash might be the result, similar to when Google punished some of the shadier SEO practices with their Panda update.

The ASO tips presented above are not meant to be a ‘silver bullet’ for app discovery. ASO is a useful set of techniques used to increase discoverability through keywords, complementary screenshots and –most importantly– understanding how users are looking for apps. But it’s just one of many approaches to attract attention in a crowded app store, the main one being: having a great app that’s worth discovering in the first place.

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
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
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
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.

Categories
Business

Revenue Haves and Have Nots

Revenu Distribution by Platform

While not all developers are in it for the money, most would like their apps to provide an income and the majority of those struggle to earn revenues that will sustain further development. We defined $500 per app per month as a reasonable global “poverty line”, in some countries this is very low while in others it’s a very good income. It’s also worth noting that many developers have multiple apps in the market so it doesn’t represent total income. As we’ve highlighted previously, the revenue distribution on the app stores is highly skewed toward the top and this is a major issue for the health of developer ecosystems going forward. Some developers may feel that the level of competition on Android and iOS is too high and they are thus tempted to try one of the smaller marketplaces in search of revenues. Our survey says that this is likely to be a mistake, there is indeed a wide variation in revenue distribution by platform, but the smaller markets have an even higher proportion of developers below the poverty line. The reduced competition is more than offset by the smaller user base at present.

Developer Economics 2013 - Revenue distribution by platform

Around 18% of 3,460 respondents in the Developer Economics 2013 survey indicated that they are not interested in making money from apps. Nevertheless, out of the vast majority of developers that are in it for the money, 67% are not making enough to sustain them or their business, i.e. they are below the “app poverty line” of $500 per app per month. For the majority of developers, app development is not financially rewarding.

Overall, less than 1 in 5 Blackberry developers make more than $500 per app-month. The situation is almost as challenging on Windows Phone where just 19% of developers generate more than $500 per app-month, with 61% below the poverty line. The findings of our survey are somewhat better for Android and iOS although these platforms too, are far from a developer paradise: 55% of iOS and 54% of Android developers are below the poverty line. Excluding developers that are not interested in profit, 62% of iOS developers and 67% of Android developers are not making more than $500 per month per app.

HTML seems a surprise here with just 45% of HTML developers under the poverty line, far lower than any other platform. However, there are fundamental differences between HTML and native platforms which are responsible for the differences observed here: developers using HTML for web development have access to a much larger user base comprising desktop and mobile users, irrespective of platform. Among HTML developers, subscription-based revenue models are much more popular than on native platforms pointing to established online content or service businesses that have expanded on to mobile.

[doritos_report location=’DE13 Article – Revenue Distribution’]

Categories
Business

How Many Users Is Realistic?

Users

One of the most common mistakes developers make when planning the business case for a new app is dramatically overestimating the number of users they will be able to attract, particularly for their first app. The typical argument goes something like this: “My app will be compatible with 400 million devices, if I can reach just 1% of those, that’s 4 million users”. The trap here is that 1% sounds like a very conservative fraction of the installed base to target but in reality it is incredibly high. Of the 664 respondents in our latest survey who integrate user analytics and provided us with their information about the active user base for their most popular app, only 6% had over 500,000 users. The nature of store charts and limited promotional space means that those who break the half million user barrier are quite likely to gain many, many more users than that, however, what’s a realistic figure for everyone else?

One of the more interesting findings we published was that, excluding those with more than 500,000 users, the mean average active user base for iOS developers was 70,000 users vs. 51,000 users on average for Android. The median user base, is 27,500 users for iOS and 15,500 for Android. The percentage difference between means is much smaller than that between medians, suggesting that the distribution of active user bases in general is worth further investigation.

As can be seen from the chart above, 200,000 – 500,000 users is the least common user base size, despite being twice as large an interval as the 50,000 – 200,000 option immediately below it. This suggests that there is a threshold level somewhere near 200,000 users, such that if you break that level you’re likely to “get noticed” and end up with significantly more users. There’s a similar bump near the bottom end of the scale where 501 – 2,000 users is more commonly reported than 2,001 – 5,000 users. This is likely to reflect the difference between apps which are not (effectively) marketed and those that are.

In addition to the platform differences noted above, there are also interesting differences in user base size by revenue model and app category. For example, apps using advertising as a revenue model (and therefore presumably free downloads) are more likely to gain over 50,000 users than other models, whilst freemium shows a very similar distribution to paid downloads. The games category is incredibly competitive and developers there are less likely to have more than 50,000 users, whilst developers in the music and video category had the highest probability of breaking both the 50,000 and 500,000 user barriers. The combinations of revenue models and categories are almost endless but the chart above has dynamic filters so you can explore the opportunities in your own app category. Please let us know about anything interesting you find in the comments below.