Categories
Business Community Tips

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?

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

How Many Users Is Realistic?

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.

Categories
Business Platforms

The Darker Side of App Store Optimization

As long as there are algorithms impacting revenues there will be people trying to game them. In the world of mobile apps there are two sorts of algorithm that can be routes to success, chart rankings and search rankings. Chart rankings are very simple and typically just use some time-weighted download volume. Search rankings are much more complex, involving keywords, reviews and other social or similarity-based data as well as downloads. Developers can use a range of tactics to improve their ranking in these algorithms, some of them much more legitimate than others.

There’s no such thing as a bad download

Whilst there are very good practices for optimising search ranking, such as using tools that monitor competitors and analyse their keyword usage to suggest improvements to your own, the single most effective way to improve all rankings is to increase downloads. For paid apps, all downloads generate revenue, whether the app gets used or not – temporarily reducing the price or making the app free is an effective technique for boosting downloads, which boosts rankings and subsequent revenue when the price is returned to normal. For apps that are free anyway, it can similarly be worth spending some of the revenue earned through advertising or in-app purchases to increase downloads. On one level this is obvious, it’s worth spending money to market the app and try to reach new users. However, the winner takes all nature of app store discovery at present makes it worthwhile for some developers to chase downloads purely to enhance their rankings. Even users who will never open the app are worth attracting if they can be acquired for a low enough cost.

Paid placement

There are lots of advertising options available that drive users to your app in the store. The vast majority of them are pay-per-click and thus cannot be used cost effectively to inflate downloads of an app that doesn’t generate significant revenue per user anyway. Most of these are clearly advertising products, others look like app discovery tools to end users. Hooked is a good example of an app that blurs the line between discovery and advertising. They have a popular social discovery app for Android games where developers can pay to generate installs. For developers this is a very logical option because they have a fixed cost for installs which they can compare against average revenue per user. On the other hand, users may believe they’re getting a recommendation when in reality they are seeing an advert. It’s the same argument that surrounded paid placement for search results in the days before Google launched AdWords.

Cross Promotion

Another way to reach users is through similar apps. Apps promoting one another is a great way to reach a common user base. There are several cross-promotion networks with a variety of business models. Ironically the one with the name most suggestive of ranking manipulation, Chartboost, is at the most ethical end; they provide completely free technology for developers to organize their own cross-promotions and also a marketplace to connect developers where they take a cut of the transactions. At the same time, the most popular cross-promotion network (according to our latest survey), Tapjoy, plays much closer to the lines of acceptable conduct. One (and in fairness it should be emphasised only one of several) of Tapjoy’s services is incentivised downloads, a practice that Apple have repeatedly cracked down on – they pay users (in virtual rewards such as in-game currency) to download apps which have paid for that service (in cash). Clearly a large fraction of people who will download other apps to earn a bit of virtual currency are those unable or unwilling to pay for the same. These users almost by definition are unlikely to monetize, so the only obvious reason to seek them out is to increase rankings in order to be discovered by other paying users that would be more expensive to reach directly.

Shuabang!

At the extreme end of ranking manipulation, with no pretence of being anything else, is Shaubang. This manipulation is primarily practiced on Apple’s App Store, made possible by the fact that a credit card is not required for an iTunes account in China. Companies with millions of accounts make use of extremely cheap local labour to pay people to download and review apps. These services often guarantee to boost an app to a desired category ranking for a fixed fee. This practice is heavily frowned upon by store owners but also extremely hard to police, since it involves real users (sometimes bot-assisted for efficiency) with real accounts.

Where’s the harm?

Users are mostly getting what they want out of these deals and so are the developers involved. Store owners have higher download stats to boast about. Even at the extreme end we have job creation in China. The main people losing out are the developers not taking advantage of these strategies. However, if ranking manipulation becomes the norm rather than a fringe behaviour then two problems become very serious. First, the top ranked apps are simply the ones that paid the most to be there, rather than the best ones – this makes discovery of genuinely great apps harder and reduces the overall perception of app quality. Second, a feedback cycle further concentrates revenue at the top of rankings – only those who pay to be at the top can afford sufficient manipulation to stay there and the rankings will begin to stagnate. App store owners need to ensure their markets are as honest and fair as possible, or users and honest developers will suffer in the long run.

Categories
Business

The Six Biggest Challenges for App Businesses (and what to do about them)

In our Developer Economics 2012 survey, we asked developers about their biggest challenges. Here we discuss six of them, with some basic tips on what to do about them. The challenges are split between marketing and post-launch app and user management. The three biggest marketing challenges were: keeping users engaged, targeting the right users and identifying the right revenue model. The three biggest post-launch challenges were: Tracking bugs and errors, getting users to review your app and updating applications in the field.

Keeping users engaged

Keeping users engaged was the challenge cited most often overall, by 39% of developers, irrespective of primary platform. This is consistent with data from analytics firm Flurry, who report that user engagement falls sharply over time, with only 24% of consumers continuing to use an app after three months from download. “Developers must focus on tracking user engagement & usage patterns rather than just on downloads” notes Jai Jaisimha, founder of Open Mobile Solutions, a brand-to-developer matchmaking service.

There are many techniques for improving user engagement and retention. Social buttons like Follow or Like, especially when integrated with social networks are known to increase engagement. “‘Follow is the most common social feature used by our users” notes Yiannis Varelas, co-founder of Weendy, a weather app for surfers, with 6,500 monthly active users and 80% retention rate (in May last year). Where direct social integration doesn’t make sense, push notifications are another tool to help keep users engaged.

Gamification is another retention technique that rewards users for achievements (e.g. FourSquare-style badges) or for inviting other users (e.g. for each user you invite to Dropbox, you get another 250MB free storage space). Moreover, Tom Hume, founder of Future Platforms, argues that developers need to fundamentally rethink user retention. “To improve retention, developers need to build up value for the user that increases with usage. A natural way to do this is to build in a history of usage data – for example in the Nike Plus the value and stickiness of the application increases as more data is recorded in the application”.

Targeting the right users

The second most oft-cited challenge is targeting and getting through to the right users – mostly because existing app stores offer little in the way of user targeting. App stores, for example, provide no means for developers to reach existing customers or gain information about them. The only way developers can target users via app stores is via coarse-grained methods based on app categorisation or keyword selection.

Consequently, we found that developers using app stores are more concerned about targeting (39%) and engagement (46%) than developers using most other distribution channels. The situation in carrier portals is even worse: around 55% of developers using them are challenged by targeting and engagement.
Customer information, as with any business, is a key source of competitive advantage. As such, app stores have little incentive to share customer data with app developers. Apple has done so in part, after considerable pressure, but only to Newsstand publishers, and only where customers opt in. There’s more to it than just control: app store owners are loath to jeopardise user privacy contracts, lest their platforms become marketing “wild wests.”

The inaccessibility of customer information will likely remain a thorny issue, and one that hampers developers’ marketing potential. For the moment, it generates a flurry of innovation, as evidenced by the proliferation of in-app and external app marketing channels. However, seeing as this will remain a pain point, there may be opportunities for app stores to differentiate, if they manage to balance their priorities against those of developers – as Apple arguably has with Newsstand publishers. In the meantime, app developers would be wise not to wait for the app stores to fix this. Try to reach the right users for your app wherever they are currently, via blogs, forums and more traditional media. Arrange cross-promotions with similar but complementary apps. Experiment with alternate discovery solutions and find out what works for your app.

Identifying the right revenue model

Developers were becoming increasingly confused (36%) about which revenue model to use. There are over 10 revenue models to choose from and no guarantees as to which revenue model will work best in the long run in terms of reach vs. monetisation. Moreover, the revenue model needs to be optimised to the platform and app category. The decision should also take into account factors such as customer paying propensity (which varies across platforms), competitor pricing and positioning (which varies by app category). For example, paid downloads are extremely unpopular on Android, whilst apps aimed at children often need to use that model, since parents are very uncomfortable with in-app purchase or advertising based models for apps their children are using. User needs should also come into perspective when considering
your pricing strategy. “You may only need one Facebook, sports or weather app, but you will want to play many games. Mobile games are like movies – users are always looking for the latest one,” notes Markus Kassulke, CEO at Germany-based HandyGames.

Overall, we found that pay-per download was the revenue model used most frequently, by 34% of developers irrespective of platform, followed closely by advertising, which was used by 33% of developers. Wherever possible, the best advice we can give for now is to try some sort of freemium or virtual goods model using in-app purchases. The growth of in-app purchase revenues across iOS and Android is significantly outpacing paid downloads.

Tracking bugs and errors

Tracking bugs and errors was, by far, the most frequent post-launch headache, as reported by 38% of developers in our survey – and particularly so for WP7 developers. There is no direct feedback channel between users and developers, and no out-of-box
means to monitor the performance of an app. App reviews work and feel more like post-mortems, rather than a live feedback tool. As a result, developers will often find out what’s wrong with their app too late, through users’ negative feedback. “Our biggest headache after launch is the lack of a two-way communication channel with our users” notes Hong Wu, Director of Android Engineering at Peel, makers of a personalised TV guide app.

The first line of defence here is to remove as many errors as possible before launch, both through good engineering practices during development and extensive beta testing. The second line of defense comes in the form of crash analytics and bug tracking services. These services track app errors by monitoring crashes and reporting the type of error, platform, device and environmental variables like location, time and transaction flow. As such, they can provide useful insights, helping find and fix errors before they drive users away.

Updating applications in the field

Updating apps was highlighted as a challenge by 25% of developers irrespective of platform. Interestingly, the difference in the update process between iOS and Android has no impact on developers’ attitudes – as both iOS and Android have their own update challenges. On iOS the process requires full certification and approval by Apple, plus explicit opt-in by the user. On Android, the update process can be automatic and near-instantaneous. This however requires that users opt-in for automatic updates for specific applications. In effect, these challenges with the update process on both iOS and Android increase the average application “age” and escalate both code maintenance and customer support costs for developers.

One solution to this is to have the app check for the availability of a newer version at launch. Although it may not be possible to have the application download the update, it could prompt the user to do so. Another option here is to track application versions via analytics and send push notifications to users with sufficiently old versions, highlighting the benefits of updating to the latest version.

Getting users to review apps

Last but not least, another frequent post-launch challenge was getting users to review apps, reported by 30% of developers irrespective of platform. At the same time, there have been some success stories of apps boosting their review numbers, usually by nagging users after they have used the app for some time. For example, to solicit reviews, DrawSomething shows a motivating alert where “Rate 5 stars!” and “Remind me later” are the only two options, wrapped in a friendly pop-up box. The example shows that the runaway success of DrawSomething was more science than luck. However, DrawSomething’s grossing ranking was declining in the run-up to the all-important Christmas sales season, showing that even successful and well funded apps with highly social components can struggle with our first challenge – keeping users engaged in the face of all the other shiny new offerings in the app stores.

Categories
Business

The “Onboarding” Problem

With some types of mobile app, getting a user to download it is just the beginning of the problem. If the application is going to be personalised to a user’s preferences, or allow them to interact with others via some online service, then they’ll need to provide some data before they can start using it. Typically the more information a user provides about themselves, the better job an app or service can do of tailoring the experience to them. Unfortunately, the more steps a user has to go through before they can start using an app, the less likely they are to complete the signup process. Getting this wrong can catastrophically alter the economics of user acquisition.

Categories
Business

Which apps make money?

[This post by Andreas Pappas, Senior Analyst at VisionMobile, first appeared on the VisionMobile blog on 13 November 2012.]

[Andreas Pappas takes another look at the results of VisionMobile’s Developer Economics 2012 survey and comes up with interesting new insights on app monetisation: how does app revenue vary by app-category and by country? Is there a correlation between time spent developing an app and they money it makes?]

VisionMobile - which apps make money

In Developer Economics 2012 we discussed app revenues and how they vary across platforms. We found that overall, around half of all app developers that are interested in making money did not earn a sustaining income, i.e. they were below the “poverty line”, which we drew at $500 per month per app. Of course the real poverty line will vary widely across countries and regions: while $500 per month may not be enough for a San Francisco-based developer, it could be more than enough for a developer based in Bangalore where average living cost is less than a third, according to Numbeo.

Categories
Business Platforms Tips

App Promotion: make or break your app

With well over one million total apps available on Apple and Google app stores combined, plus hundreds of thousands on the other platforms, the competition to get on consumers’ handsets is fierce. As hundreds of apps are added each and every day, app discovery remains a largely unsolved challenge which is only getting worse. With a rapidly changing landscape of app store ranking algorithms, mobile advertising products, cross-promotion networks and specialist marketing services it’s very difficult to decide how to begin app promotion which is cost-effectively. The one very clear piece of advice we can give is what you shouldn’t do – nothing.

Categories
Business Platforms Tips

Freemium beats Premium, says App Annie

App Annie Intelligence, which tracks more than 700,000 apps, reports that freemium apps – free apps that have in-app purchases – are experiencing impressive revenue growth worldwide, far outpacing premium apps in both iOS and Google Play stores. Over the last 24 months, worldwide revenues for freemium apps on iOS have more than quadrupled. In 2012, worldwide  revenues on Google Play have grown 3.5X. Now, apps generate 69 percent of the worldwide iOS app revenue and 75 percent of global Android app revenues. Meanwhile, premium revenues for both app stores remained relatively flat in these time periods.

This confirms earlier reports of this trend by Distimo, IHS iSuppli and others.

 

Categories
Business Platforms Tips

Methods for Monetizing a Mobile User Base (or Are Mobile Apps the New Internet?)

Mobile apps are a huge and rapidly growing business. Mobile developers have access to a greater number of users and more simple ways of monetizing their creations than any software developers before them. However, selling digital content and services directly, or advertising to users of those services are only two of many, many ways of generating revenue through mobile apps. Which methods are likely to dominate in the future?