Categories
Business

Mobile Gaming’s Dirty Secret

Mobile gaming is a major growth industry. Revenues and profits are soaring and the most successful companies are attracting valuations in the billions of dollars. However the market dynamics are such that very few can succeed and those that do have incentives which are a long way from maximising fun for players. Where are all the revenues coming from? Is the market fundamentally broken? If so, why aren’t the platform owners trying to fix it?

Mobile Gaming's Dirty Secret

Spectacular Growth

[tweetable]In 2013, games accounted for around 40% of all app downloads across the iOS App Store and Google Play[/tweetable] but approximately 75% of the revenues (according to App Annie). Game revenues more than doubled year over year on the App Store and more than quadrupled on Google Play. By the end of 2013, revenue from games on Google Play was still only about 60% of the iOS App Store equivalent. Since Apple had $10 billion in App Store sales in 2013, we can estimate very roughly that [tweetable]there were around $10 billion of games revenues across the two stores[/tweetable]. This is not far from Gartner’s estimate of $13.2 billion for all mobile games in 2013, projected to rise to $22 billion in 2015.

Increasingly Freemium

According to Distimo 90% of all games revenue on the iOS App Store came from free apps with in-app purchases in November. The percentage of revenue attributable to freemium apps in the entire store grew from 77% to 92% across the year. [tweetable]On Google Play 98% of all revenue was generated by freemium apps in November[/tweetable], so the games revenue there clearly favours the freemium model to an even greater extent than on iOS.

Now there are very good arguments that all successful digital content will eventually use some kind of freemium model, here’s a good recent summary. However, there’s a special subset of freemium that’s really generating all the growth and revenue, so called free-to-play games selling virtual goods (e.g. coins, gems, lives). Only a small fraction of users pay at all, only 1.5% according to Swrve, then a fraction of those pay so much more than you could ever get for a paid download or unlocking levels that the average revenue per user (ARPU) is higher than all other models – at least when the game mechanic and purchases are well designed to optimise for this behaviour.

Winners Take All

The games with a combination of high ARPU and broad appeal (so they get high conversion rates on user acquisition spending) can afford to bid the most for new users, squeezing others out of the best user acquisition channels. This creates a feedback cycle with the store charts, bringing in even more users organically. Our Developer Economics survey data confirms this: the typical games developer monetising via freemium and in-app purchase business models makes only about twice as much on average as those using the roughly equally popular paid download and advertising models. This difference is nowhere near enough to account for the highly skewed revenue distribution in the app stores. A large fraction of the total revenues are being made by a handful of top publishers.

Who’s Paying, How Much and Why?

Up to this point it sounds like the industry has hit on a fantastic profit formula to be emulated by all. However, if you look at the numbers and their implications then things start to look a little darker. Of the 1.5% of players who pay anything for their “free” games, 10% of those account for more than 50% of the revenue (see Swrve report above). Indeed just 1% of paying players, that’s 0.015% of all players, account for 13% of revenue; contrast with 11% of revenue from the bottom 50% of payers. Even with the astronomical size of mobile user bases, some basic arithmetic suggests the top 1% are spending more than $10k a year each on these games, even the top 10% are spending hundreds of dollars.

The free-to-play games industry likes to call these high spending players “whales” after the high rollers in the casino industry. However, high rollers only account for a small fraction of revenues in the gambling industry and they have a very real chance of winning big too, even if the odds are tipped in the favour of the casino. A better analogy from the gambling industry would be the slot machine addicts who generate a large fraction of the revenues. In fact, these mobile games are designed to be “addictive” it’s just that for some players the addiction becomes very real and they lose all rational control of their spending. So rather than hunting for the high-spending whales, this part of the industry is really exploiting vulnerable digital narcotic addicts.

If you want to see an example of what that looks like in real life, read the New York Times interview with George Yao, a long time top player in Supercell’s Clash of Clans. He spent $3k of his own money on the game in 3 months before wealthy clan mates started to bail him out. At one point he was taking 5 iPads into the shower with him to help maintain his ranking. In his own words about the experience:
“Looking back, I think I must have been insane,” he told me, with a mix of pride and revulsion. “I was so immersed in it at the time. I knew it was abnormal, but never to the extent that I see it now.”

What Next?

Apple and Google could easily stop this with some sensible limits on monthly IAP spending per app. That could cut off billions in revenue through the stores of which they take a 30% cut. However, the revenue itself is not that significant to either business. More important are the headline revenue and growth figures enabled by this that maintain developer interest in the platforms. As such we’re likely to see external regulatory action before any strong voluntary action on the part of the stores. Apple have already created the Kids section in their store which has extra review criteria to protect children from IAP and targeted advertising but they’re not currently doing anything to stop apps targeting children with purchases that aren’t attempting to list in this new “safe zone”. In most countries, children are not the only consumers protected from questionable business practices. The EU has just announced meetings with the app industry to discuss consumer protection issues – this is likely to repeat elsewhere until the real cost of “free-to-play” games is made more clear to consumers.

If you are interested in Business Models in Mobile Gaming, have a look at the three part series on battle insights by a mobile game CEO.

Categories
Business

How We Learned to Built Hardware, the Agile way

I ‘m part of a hardware research group at Telefónica Digital called “Physical Internet Lab”. Three years ago we started a small group under the Emerging Technologies area of the company focusing on the Internet of Things. The commitment of the group was (and is), in ambitious terms, “to democratize the Internet of Things” opening it to as many makers, developers and users as possible. Our goal has been not entirely altruistic: Telefónica as a network operator has a lot of value to add in the Internet of Things economy.

On day to day basis we build prototypes and products, usually connected objects or components like the Thinking Things building blocks.

Setting up the lab three years ago was no easy task. We wanted to work at the crossroads of the Internet, the Things and the People. But our development skills were almost 100% software related. In the process we built a team skilled on all three sides. And we figured out how to do agile hardware.

agile-hardware

Of Agility and Hardware

We ‘ve come full circle. Telefónica I+D (the Telefonica Digital development branch) was created 25 years ago to produce hardware innovations such as X.25 and ATM switches. We did that in the classical engineering fashion: writing long and rigid lists of requirements, splitting the work across solution providers, integrating and then testing following a waterfall schema.

Over time Telefónica I+D adapted quickly to the technology changes and by the mid-nineties we were developing mostly software. First we followed the same engineering process; then we moved towards more iterative methods. In the last 10 years we have adapted fully to agile methodologies.

As we were building the laboratory we found ourselves getting back to hardware. But the company now could not understand a slow-moving unit. The lab had to be agile. So we had to bring agile methodologies to hardware development.

The first difficulties came with the corporate facilities. Hardware work demands physical proximity and we could not afford to have a distributed team depending on collaboration tools on the Internet. At the same time, soldering fumes or drilling noises were not welcome in our modern, bright, open spaces. So the team had to move to a closed office in an old building in Madrid city center.

Moving to the city center was a boon: in minutes we could reach many shops and services, buying anything from hammers to plastic boxes. Visitors now found it easier to visit us in a centric garage-like office. This was great for our open approach as we wanted to help and interact with other companies and organizations.

Purchasing tools was another problem. The corporate procedures were tuned for large-scale purchases such as server farms or external services. Buying a handful of resistors for 10 euros could take several weeks, creating bottlenecks to our work. Fortunately the purchasing department showed a great deal of sensibility. We worked together to redesign the process. Now we buy any component or tool in a single day while still working by the book.

Putting together the Agile team

Hardware work implies multiple teams across several companies with extremely specialized profiles. When setting up the lab we opted for a small and autonomous team, able to build a hardware prototype with no external dependencies.

A small team allows us to work closely integrated, in the same location, continuously coordinating our work. A small team also means that budgets are smaller and is well suited to experimenting, failing, learning and adapting.

Basic agile methodologies such as Scrum expect some degree of overlap between the specializations of team members, so that different people can execute the same tasks naturally balancing the work load. But hardware work is different. It demands a lot of specialization. In our case most of the tasks can be executed only by one team member. As a result, the Scrum methods and tools have to be modified to reflect this reality.

Our internal workflow follows many steps. The first step is the Industrial Designer, a role which is somewhat of a novelty in the Telefonica Digital payroll. Carlos (that’s his name) starts his work in the CAD station designing the physical product: plastic pieces, metal straps, cloth, magnets. Then he builds the design using the currently available 3D prototyping tools such as the laser cutter, the CNC tool (i.e. a computer controlled drill) and a variety of 3D printers. These tools give much flavor to the lab.

In some cases we start from an existing object that we hack so that we can explain a new concept. Carlos at the same time designs and builds, which is a bit out of his job profile. Software developers are multi-taskers, too – they design and type, while software architects can also code. In the hardware industry this is somewhat unusual and typical engineers expect someone else to physically build what they have created. In the lab we follow the software philosophy. It is leaner, and gives the designer a real feel of the piece or circuit construction. This approach demands some tolerance and patience from engineers who have to get their hands dirty.

The same philosophy applies to the next step in the workflow: the electronics engineering part. The electronics engineer first designs new circuits, then prototypes them. We even design and build the PCBs to check that everything fits in place.

The agile doctrine underlines the importance of early user testing. Early use provides rapid feedback focusing the most important characteristics of the product and showing what isn’t relevant for customers. To shorten the time-to-test we use 3D printing and prototyping technologies.

In electronics engineering we massively use Open Hardware. Open Hardware gives us access to lots of ready-to-use designs that we can employ in product testing. In a sense, Open Hardware behaves now like Linux and Open Software in the mid-nineties. It allows us to focus on the real technical or design challenge rather than reinventing the wheel for every test.

Electronics and physical design teams work side by side, so they can verify in real time how components fit in the same object. Our objects become more than simple plastic boxes, as they are tightly coupled with the internal electronics.

Electronics engineers work also with the firmware developers. The firmware developers write the code for the embedded microprocessors. They also have to deal with connectivity issues and power management.

In our Physical Internet Lab, electronics and firmware engineers work side by side. In most situations knowing what will firmware do simplifies hardware design. Similarly, software developers can ask for fine changes in the hardware designs nearly in real time.

On the other side of firmware sits backend development. In our typical systems architecture, distributed devices communicate with a backend service in the cloud. We push as much intelligence as possible to the backend service, so our designs can evolve without touching the deployed hardware or executing firmware updates. We like to think that the back-end gives every object nearly infinite computing power and knowledge, as it can interact with any other Internet service.

Again back-end and firmware developers work side by side. This tight collaboration resolves any integration problems before they appear, and encourages electronics and firmware developers to take issues to the more powerful (and more agile) back-end platforms.

The final technical step is the front-end development, usually based on web and native apps. Again we do a lot of work locally in the lab, well integrated across the team.
The frontend is also tested in complete end-to-end scenarios. Automatic testing tools execute scripts that run against the firmware and the frontend.

And of course, there is a Quality Assurance side. We are extending continuous integration, test driven development and automatic testing to the embedded firmware. At the same time we have to handle more hardware specific tasks such as sensor calibration, assuring robustness and strength.

Physical Interaction Design

The web/application interface and physical design are the two endpoints of the “development chain” of our group. They form the two interfaces exposed to the final user. At the final part of our workflow, the physical interaction designer, works with both web / app and physical design.

The physical interaction designer is responsible for the design of the connected object as a whole. He takes care of building a single object with a coherent interaction model in the physical world and in the Internet.

Without the physical interaction designer we would have to separately design the physical object and the application or web interface. The result would be a split-personality product, usually an amalgamation of data stuck on top of a square box. The physical interaction designer combines the capabilities of the physical object and the Internet interface in a coherent manner.

Physical interaction design, bringing together the Internet and physical objects is a completely new field. There are a handful of specialized schools in the world, and we are working too with UX designers with strong industrial design background.

Everyday physical objects have usually long stories and designs optimized through centuries of use. We still have a lot to learn on how to take the Internet beyond of the smartphone/tablet/PC onto this physical object world. Customers will not adopt Internet of Things devices if they are a step behind of the design standards they have become accustomed in software interfaces.

Agility plays a role here, once again. Developing and prototyping quickly we can try interaction designs with users, test our assumptions and build a sizeable bunch of knowledge around user interaction with connected objects.

External providers

Of course we have to work with external providers, especially when dealing with complex technologies or industrialization. For development we often use online services for as PCB manufacturing or 3D printing. They are extremely easy to use, robust, fast, and offer a direct web interface instead of long negotiations with a salesperson.

For the final manufacturing we interact with real, serious manufacturers. Agile, as a software development doctrine has no solutions to this task. But Agile can be seen as a spin-off of Lean philosophy, which was created to deal specifically with manufacturing issues.

One of the main lessons from the Lean methods is that service providers have to be tightly integrated in the business process. We have found this is very important also for us. The lab has spent considerable efforts building trust relationships with service providers and manufacturers, integrating their teams with the lab. Schedules and plans are shared under an openness philosophy. We have established even real time communication so their teams get continuous feedback from the engineers in the lab.

The future of agile hardware

We have yet a long way to create a truly Agile Hardware lab. Physical work is sometimes slower than software development. Some other times (especially when prototyping on Open Hardware designs) they are blindingly fast and have to pause and wait for software components. Speed differences keep the group working on different “user stories” at the same time.

External dependences are many, and the lab will never be, in that sense, completely autonomous. But we can find yet faster service providers and build leaner and more integrated workflows with them.

Regarding Quality Assurance we have to handle correctly the physical device characterization and fit the expensive and slow certifications in the product workflow.
The bright side is that Agile methodologies provide and require continuous improvement. Every sprint or work cycle forces us to learn and adapt our methodology and organization, looking for a better process. Perhaps in a couple of years we’ll have a completely different process in a completely different lab, and it will be all right.

Categories
Business

Flappy Bird vs Angry Birds – a tale of Hobbyists and Hunters

Here are the stories of two successful birds on the app store. See if you can spot the difference.

Angry Birds vs. Flappy Bird_639px

Flappy Bird was a mobile game developed by Dong Nguyen, a Vietnamese indie game developer, in a few evenings after work. He launched the game in May 2013, but only 7 months later (in January) did it unexpectedly gain immense traction. It reached the top of the US charts, and Nguyen was reportedly earning about $50,000 per day from ads. He couldn’t cope with the pressure and abusive comments however, saying it “ruined his simple life”, and removed the game from the app store on February 10th.

Angry Birds was developed by Finnish game maker Rovio Entertainment. It was a runaway success… on the 52nd try! (That’s how many games the good people at Rovio had developed before Angry Birds). Rovio has expanded to be a successful franchise and merchandising business, counting its revenues in the hundreds of millions of Euros. Today, Rovio employs over 700 people according to its website.

Why did Flappy Bird become a flappy Icarus, crashing after flying too close to the sun, and not a new Rovio? In truth, Nguyen and Rovio represent very different groups of developers. Their motivations are not at all alike, and so neither is their behavior.

Developer motivations wildly differ

Dong Nguyen and his indie game studio .Gears sits on the border of a Hobbyist and an Explorer profile in VisionMobile’s developer segmentation model. Hobbyists are motivated by the fun of making an app, and like Nguyen often do it in their spare time after work. They don’t care about success – killing off a successful project that interferes with their sense of fun and peaceful life wouldn’t seem strange to them. Arcade games like Flappy Bird and the other .Gears projects are a typical project for Hobbyists (professional game developers rarely touch the arcade category).

Our Flappy Bird protagonist also shows traits of an Explorer, however. He presents a formal face with the .Gears studio, complete with email address and copyright notice. Put simply, Explorers are “practicing” to become successful app developers (either as contractors or with own apps): their main motivation is learning how to become professionals and they define success by knowledge gained as well as having a lot of fun developing. Some speculate that Nguyen might have tried to artificially boost the app using review bots, which would be more Explorer than Hobbyist behavior. (Nguyen himself denies having done any kind of promotion.)

Whether Hobbyist or Explorer, Nguyen clearly wasn’t in it for the big money. Contrast that with Rovio, a clear Hunter company. Hunters are revenue driven: their goal is to build a successful business and make money from apps. The 50+ games that Rovio built before Angry Birds are a testament to their persistence in achieving that objective. Success is measured strictly in business terms: app revenues (in the case of Rovio enhanced with merchandising) and user reach. Hunters are professionals, out to build real, lasting companies, exactly what Rovio has achieved. The difference couldn’t be clearer.

Understanding the motivations of developers is key to understanding the choices they make. This includes fundamental choices, like the one between lifestyle and business success that Dong Nguyen faced when his project became a huge success overnight. It also includes all the minor and major decisions that app development involves: business models, tools, platform selection, and much more. [tweetable]If you’re working with developers, gaining insights in their motivations is crucial[/tweetable].

— Christina & Stijn

Categories
Business

App monetisation tip: Go for niche markets, not user reach

Mobile apps have enabled some developers to reach unprecedented scale in an incredibly short time. The companies that do this best have hundreds of millions of users and are typically valued at billions of dollars. The winners in this battle for mass market attention and appeal are either backed with millions of dollars in venture capital or created by companies already worth billions. Can developers without quite so many resources behind them achieve a smaller scale of success by following the same formulas, or might targeting a smaller niche achieve better results?

VisionMobile

Categories
Business

Developer Economics: Ecosystem wars drawing to a close

Welcome to the brand new Developer Economics report! Now in its fourth year and 6th edition, the latest Developer Economics survey reached over 7,000+ developers across 127 countries, setting new standards in developer research.

DNAapps

Get your free copy here and read about the movers and shakers in the app economy. Dive deep into our rich dataset and discover how developers select and prioritise platforms, which developer tools they use and how their choices translate to revenues.

As always, we have a lot more data available so get in touch (moredata@visionmobile.com) to get the data you need if you can’t find it in the report.

The mobile Developer Mindshare

The latest Developer Economics research shows that 84% of mobile developers are now developing for Android or iOS (or both), the two clear winners in the developer mindshare race. While Android amasses hundreds of millions of new users every year, sales of iDevices are still rising, attracting developers that are more interested in revenues rather than reach.

3b_mobile_mindshare

HTML5 continues to play an important role in mobile development, providing diverse development paths for those developers that want to extend their web skills or web assets onto mobile. [tweetable]37% of developers rely on HTML5 for developing mobile websites and web apps[/tweetable], but more developers use HTML5 to target native platforms via hybrid apps or converted or translated HTML5 code.

Microsoft remains the outsider in the ecosystem battle but has gained some ground in the past few months owing to rising sales of Lumia handsets. Windows Phone still faces a long and thorny road in its quest for mobile mindshare. Meanwhile [tweetable]Windows 8 remained stable at 21% Mobile Developer Mindshare[/tweetable] – the Q4 uplift in Surface sales is likely, however, to generate some developer interest that could push Windows 8 ahead.

Getting your priorities right

Developer Mindshare tells just one side of the story. In a multi-platform race, mindshare is nice to have but what matters most is getting developers to prioritise your platform against the others. This means more, better-quality apps and faster updates, keeping users happy. [tweetable]Android is now the priority platform for 37% of developers, with iOS at 32%[/tweetable].

2_platform_distribution

But there are large variations in developers’ priorities: iOS is still the priority platform in North America and Western Europe, with Android claiming pole position in most of the other regions. There are also significant differences across developer segments: [tweetable]Android is very popular among hobbyist developers who may find the start-up costs somewhat lower[/tweetable], but iOS is preferred by Hunters, who target app-store revenue and Guns-for-Hire, who target development contracts.

HTML5 is prioritised by 14% of developers, although a large number of these developers target Android or iOS via hybrid apps, rather than building true cross-platform apps. With 83% of developers prioritising Android, iOS or HTML5, the other platforms face a mighty challenge: if they are to become key players in mobile, they need to convince iOS or Android developers to switch their priorities. But looking at the revenue distribution for developers across platforms, it becomes clear that that is not a compelling proposition for the majority of developers.

Revenues

We’ve often argued that revenues are not the most important factor for all developers. But at the end of the day, you need to make money, whether that is via app stores, advertising, e-Commerce or any other way you can think of (selling t-shirts to your users or accepting bitcoin donations).

We calculated median revenues to demonstrate the revenue disparity across platforms. The revenues shown in the graph below are the revenues that developers can realistically expect to earn per app per month.

18a_median-revenue

This graph is a picture saying a thousand words and reveals why more than half of the developer population are still investing in a platform that has less than a third of the user reach of Android.

There’s a lot more information on revenues and revenue distribution across platforms in the report, and a lot more graphs and data points that you need to know about if you’re in the app business. We don’t want to spoil the fun so go ahead and download your copy of the report and tell us what you think.

If you don’t find the information you need, then do get in touch at moredata@visionmobile.com to see if we can help.

Follow me on twitter @PappasAndreas

Categories
Business Platforms

Mobile Gaming And The Pyramid Of Scarcities

Distimo - App Revenue Distribution

According to Distimo’s latest report, apps with “freemium” business models, i.e. free apps monetized by in-app purchases (IAP), have dominated revenue charts in 2013. This spurred me to take a deeper look at the “economics of free” and explore new opportunities for innovation in these business models.

The Economics of Free

Let’s begin by taking a brief look at the “Economics of Free” or the “Economics of Abundance”, as described by Mike Masnick. Here’s a short, 2 minute video introducing the concept:

Economics is essentially a social science that examines the best possible way to allocate “scarce” goods or resources, i.e. ones with meaningful marginal cost and limited supply. However, digital goods like apps are abundant because the marginal cost of creating an additional copy is zero. Given the nature of near-efficient competition in the digital world, price naturally approaches the marginal cost of zero.

This explains the decline in popularity of paid app downloads and the decline of numerous traditional business models. However, cheap or free content allows developers to reach a much wider audience which consequently increases demand for related scarce goods or resources. In the music industry, the advent of digital music precipitated a steep decline in US recorded music sales from $14.6 billion in 1999 to just $6.3 billion in 2009, but concert ticket sales grew from $1.5 billion to $4.6 billion over the same timeframe. In other words, digital music converted a scarce resource (recorded music albums) into an abundant resource (cheap, easily downloadable singles), which then increased demand for a related scarce resource, i.e. concert tickets.

  1. Marginal Cost – Cost of producing an additional unit
  2. Efficient Competition – Participants do not have the market power to set prices

The Pyramid of Scarcities

This particular study focuses on scarcity-driven monetization opportunities available to developers of free-to-play (F2P) games like Candy Crush Saga, Angry Birds, etc. As shown in the image below, the scarcities created by F2P games can be segregated into 3 categories, in order of increasing scarcity (or decreasing availability)

  1. Induced Scarcity
  2. Scarcity of Goods
  3. Scarcity of Time or Access

Pyramid of Scarcities

1. Induced Scarcity

Induced scarcity is one that does not exist in reality, but is created artificially — for example, in-app purchases of digital goods. The availability of these goods isn’t really in question and therefore, the value placed on each purchase or transaction is quite low. Consequently, effective monetization depends on maximizing transaction volume from these low-value digital goods, i.e. micro transactions. This strategy is most effective when scarcity is induced because of direct player engagement, and not when it is forced onto players. Game design plays a critical role here as in-app purchases need to be naturally blended into gameplay elements. King’s games like Candy Crush Saga are perfect examples as players pay for boosters to help them progress through difficult levels. In fact, King’s revenue is expected to top $1 billion this year, almost exclusively driven by micro transactions on Facebook and mobile games.

However, exclusive use of this monetization strategy also brings up some challenges. King’s “Games Guru”, Tommy Palm, recently said that 70% of the players on Candy Crush Saga’s final level “haven’t paid anything”. While this is a great sign for consumers, King seems to be losing out on monetizing their most engaged players and biggest fans (excluding a minority population of “whales”). The only reason these players haven’t become paying customers is because they don’t consider digital goods to be scarce enough. The solution isn’t to create “paywall” equivalents, but to explore additional monetization opportunities with even scarcer products.

2. Scarcity of Goods

Scarcity of goods refers to physical products that have a tie-in with an F2P game — for example, branded or licensed merchandise. Since physical goods aren’t as abundant as digital ones, the value placed on each transaction is automatically higher. However, this comes with the trade-off of lower transaction volume. Rovio’s Angry Birds franchise is a great example of a successful merchandising strategy. Led by sales of Angry Birds plush toys, merchandising and IP sales made up 45% of Rovio’s $195 million revenue in 2012. This year, Hasbro sold over one millionTelepod” figures within a month of Angry Birds Star Wars II’s launch. This year, King also dipped its toe into merchandising with a range of Candy Crush themed candies and socks.

These products are likely to appeal to fans of F2P games even if they have never purchased digital goods. However, the biggest fans and most engaged players may be looking for something even scarcer.

3. Scarcity of Time or Access

Scarcity of time or access can be leveraged through a direct connection with the most ardent fans — for example, events like gaming competitions or conventions. Conventions tap into scarcity of time from key personnel like game designers, while social gaming competitions tap into scarcity of access to exclusive benefits and direct competition with other “superfans”. The monetization opportunity from events is likely to be immense, even though the actual frequency may be low.

So far, very few game developers have utilized this particular strategy — a related example from the non-F2P space is Mojang’s Minecraft Convention or MineCon. 7,500 tickets to the event sold out in roughly 5 minutes, generating roughly $1 million in revenue. This may seem like small change for large gaming companies, but it’s important to keep in mind that Mojang may view MineCon as more of a promotional event. Expanded ticket sales and advertising partnerships could easily make gaming events a significant revenue opportunity. Given the competition in allied industries like mobile hardware, there will certainly be no dearth of advertisers.

Opportunity for Innovation

The monetization opportunities outlined in this post show that the free-to-play mobile gaming industry still has a lot of room for growth. Most publishers have focused on just one of these strategies and I have no doubt that we will see more business model innovation from these companies as we move forward.

Having said this, these strategies are only useful for companies if their games remain popular. The gaming industry has proved again and again that companies cannot rest on the laurels of a single mega-hit. Therefore, developers need to focus on continuous innovation across a wide catalog of games. What’s most important is to ensure that players have fun. After all, isn’t that the entire point of playing games?

– Sameer

This post was originally posted in Sameer’s Tech-Thoughts blog – you can find the original article here.

Sameer is a business strategy professional with expertise in mobile ecosystems, asymmetric business models and disruptive innovation. Over the last 6 years, he has held various roles in strategy consulting, investment management, M&A and venture capital. During this time, he has developed a keen interest in the intersection between technology, innovation and business strategy. You can follow his work on his blog at Tech-Thoughts, on Twitter @sameer_singh17 or on LinkedIn.

Categories
Business

The Android Monetisation Myth: iOS still rules the west

[tweetable]Revenues from Android apps saw tremendous growth in 2013[/tweetable]. If you look at the headline global figures then revenues from Android apps on Google Play are rapidly closing on those from iOS apps on the App Store. It looks extremely likely that 2014 is the year that Android will overtake iOS in total app revenues. However, dig a little deeper and you’ll find the distribution of revenues, both geographically and across apps is rather different. If you’re planning your platform strategy for this year then a dive into the details might prove invaluable.

Almost a year ago, I wrote about two important app market trends to watch in 2013, which were continued growth of app revenues (they’re still growing, Android significantly faster than iOS) and revenue distribution (it’s getting even more concentrated at the top). According to Distimo:

“On a typical day in November 2013, we estimate the global revenues for the top 200 grossing apps in the Apple App Store at over $18M. For Google Play, our estimate is about $12M. In November 2012, these estimates were at $15M for the Apple App Store and only at $3.5M for Google Play.

That’s 20% annual growth at the top of the market for iOS and just over 240% annual growth for Android. Add to that there are also alternate stores for Android that have been growing revenues too. These figures and relative growth rates make it seem as if Android is the place to be in 2014. It might be, if you can make it to the very top. If we look at AppAnnie’s report for a similar period, they estimate that total iOS App Store revenues roughly doubled year over year*, while total Google Play revenues were a bit more than triple their year ago levels. So although Apple seems to be improving the revenue distribution slightly, it’s getting even more concentrated at the top of the market on Android.

Even the wider distribution of revenues on iOS may not be quite as good as it looks when we also consider geographic spread. Although the US is still the top revenue earner for iOS, the bulk of the growth is in Asia, particularly China and Japan. The top grossing charts in these countries look very different from the global top grossing apps and this may account for much of the widening range of high revenue apps. [tweetable]On Android, the bulk of the growth and total revenue is in Asia and thus so are the top grossing apps[/tweetable]. Japan has overtaken the US as the top revenue earning country for apps overall mostly due to growth on Android. The vast majority of the increased revenue is in free-to-play games and App Annie’s report shows that in Japan, almost all of this was attributable to just five publishers. Two of those publishers were existing major games powerhouses before the mobile era and they have several well known franchises. Two more reached the kind of scale where TV advertising became a viable route to market and exploded from there. The last of the five is LINE, who built a messaging platform with over 300 million users as a channel to promote their games.

This concentration of revenues amongst five publishers in Japan is mirrored elsewhere in the world. Consider Supercell (makers of Clash of Clans and Hay Day) were at $2.4M per day in revenues in April 2013, when they were still only publishing on iOS (they’ve since launched on Android) and were in the middle of expanding through Asia. That’s more than 10% of daily global App Store revenues for the top 200 grossing apps made by one publisher with 2 apps. Supercell aren’t unique either – according to Think Gaming’s estimates, King.com’s Candy Crush Saga is making more than $900k per day, just on iOS in the US. Indeed Think Gaming give us a better idea of the distribution. Their estimates show that the number 10 grossing game makes only a 10th as much as the top grossing game and by number 100 you’re down to nearly 100th of the revenue.

So, with revenue concentration at the top of the charts on Android even greater than on iOS, Android is the platform to target if you’ve got a world beating app with global appeal on your hands. Otherwise you’re almost certainly still better off on iOS first. Our own data, which considers revenue sources outside the app stores as well, agrees with this. If we only include the publishers earning less than $5M per month then iOS comes out on top, although if we include everyone with non-zero revenues then Android sneaks ahead. Significantly higher revenues for a tiny number of top Android developers pushes the average ahead of iOS (although the median remains way behind – there were more iOS than Android developers earning >$5M per month in our survey).

Android may become the top earning platform from App Stores in 2014 but it seems that only an elite few developers will reap the rewards. We’ve already shown that building enterprise apps and avoiding the app stores is a better bet financially but Android is not currently a lucrative platform in the enterprise market either. Still, it’s not all bad news for Android developers – the rising tide of revenues will lift all boats to some degree. Also, even 2014’s cheap Android device should be running at least Android 4.0 and have hardware capable of running almost any app well. This should reduce costs and increase the real addressable market for all Android developers. Last but not least, for an increasing number of developers [tweetable]it’s not a question of Android or iOS, it’s becoming ever more important to target both[/tweetable].

* Distimo’s year was November to November, while App Annie’s was October to October, so there may be some impacts from the relative timing of new product introductions.

Categories
Business

4 Reasons Not to Build Enterprise Apps

In an earlier post we showed how enterprise app developers make 4 times the revenue of those developing consumer apps on average. Targeting enterprises with apps can be very different from building consumer apps and not all developers prioritise revenue, so it’s not for everyone.

chapter1

Do you want the indie developer lifestyle, or to build a company? What sort of contact do you want to have with your customers? Do you like consulting work or do you prefer to build your own products full time? Do you have a strong development platform preference? Depending on your answers to these questions you might find one of the 4 reasons below keeps you focused on consumer apps for the foreseeable future.

1. You like to work alone

The creation of the app stores enabled vast numbers of individual developers to create and monetise their own apps. Amongst the revenue earning developers targeting consumers, almost 43 percent are in one person companies and practically all of those don’t involve anyone else in development. Of the developers building apps for enterprises, only 13.3 percent are in one person companies and those are almost exclusively doing contract work. The one person enterprise development companies earn 24% more revenue than the equivalents building consumer apps but it’s definitely not the independent developer lifestyle they’re living. In general the enterprise developers earn more than those developing for consumers at every team and company size, with the difference increasing with team size up to the 500 employee mark. Above that revenues from app development per person drop significantly, although on both sides a lot of large companies developing primarily for reasons other than earning revenue are included here.

2. Direct sales repels you

As you can see from the charts above, enterprise app developers tend to work in larger companies than those targeting consumers. There’s also a bigger company size to team size ratio. The difference here is likely to be sales, marketing and support teams. In general, larger customers need more direct contact. In the consumer apps space it’s possible, although unlikely to be successful, to launch an app and sell it without ever having contact with anyone that uses it. However, although the costs of direct sales staff may seem high, consumer apps with large revenues and user bases typically pay to acquire a decent fraction of users (e.g. via in-app ads, Facebook app install ads, cross-promotion networks). We don’t have any data to compare the cost of sales for these developers but I wouldn’t bet that the average cost of sales as a fraction of revenue for the successful consumer app developers was significantly lower.

Whilst subscription revenue is by far the best earner for consumer app developers, it is one of the worst revenue models for enterprise developers. In the enterprise market per user/device licensing and other sales outside of app stores is a key revenue component for most successful businesses. This aspect of a business can often be very unattractive to developers.

3. You want complete creative control

On average [tweetable]enterprise app developers earn a much greater fraction of their revenue from contract work[/tweetable] (consulting). The most successful enterprise app businesses earn 25-75% of their revenue in this way (we only have 25% bands). It’s likely that there’s a lot of custom integration work involved in selling to larger enterprises. Even those selling to SMEs often offer customizations.

Developers who consider their apps an art-form and build them primarily to earn a living doing something creative they love will probably want to stay away from areas where a lot of contract work is involved. Those same developers are also not very likely to be inspired to help automate business processes or other similarly mundane but useful enterprise app functions.

4. You love Android development

There are some very major differences in the revenue models and revenues of enterprise app developers depending on their primary platform. The really big revenues are currently being earned by HTML5 developers (> $100k per developer per month). Next highest revenues are for iOS developers (a little over $50k per developer per month) but it seems that [tweetable]a lot of iOS app enterprise development is currently outsourced[/tweetable], since more than 70% of these earn >75% of their revenue from contract work and 40% earn 100% of their revenue in that way.

Compared to these two, the Android developers are the poor cousins. Despite having a much wider range of revenue models, their average revenue per developer is much lower (about $14k per month). Enterprise development still pays very slightly better on Android than building consumer apps but given the other trade-offs discussed above, it might seem like a relatively poor deal.

Running out of excuses?

When we published the last article, showing that enterprise developers make 4 times as much revenue as those targeting consumers, a lot of responses suggested that this difference was all in the large enterprise sales market and required large direct sales teams. While there is definitely some advantage to scale, this is certainly not the case. Not all enterprises are large and there’s a very big market of SMEs looking for mobile software to make their businesses more efficient or convenient. Although the most profitable enterprise app development companies are in the 51-500 employee range and solo developers are only marginally better off targeting enterprises, a 2-5 person company makes more than 4 times as much revenue on average by choosing to build enterprise apps. The 2-5 person enterprise app business is much more likely to be building HTML5 hybrid wrapper apps rather than the native iOS or Android apps of a similar sized consumer focussed business. They are also likely to be spending more of their time (although far from all of it) doing contract work. If neither of those things bothers you then it might still be worth considering the enterprise market for your next app.

Categories
Business

Why are you still building consumer apps? Enterprise pays 4x more!

Consumer apps are the focus for all the excitement and media attention in the industry. Enterprise software is dull and boring, right? Not if you care about making money! Our data shows [tweetable]enterprise developers generate 4 times as much revenue as those targeting consumers[/tweetable]. Besides, what’s so dreary about reinventing the way people work in a mobile and connected world?

Print

“Wait”, I hear you cry, “what about BYOD and the consumerization of IT? Surely the future is all about selling computing tools directly to professionals?” Well the data from our April-May 2013 Developer Economics survey says that future isn’t here yet. In any case, if you’re going to collaborate with colleagues then you all need to be using the same tools, so most of the time the company still has to choose and buy them.

We asked developers which type of customer they primarily targeted from a selection of Consumers, Professionals, Enterprises, Other and Not Sure. Using this data we can compare the fortunes of developers serving each of those audiences.

It’s entirely natural that a new consumer-focussed computing market for smartphones and tablets spawned a large industry of consumer focussed app development organisations. The market is rapidly maturing now, with smartphone penetration above 50% in all developed markets and tablet adoption not far behind, yet still almost 75% of companies involved in app development are focussed on consumer apps. Traditionally software spending has been much higher in enterprises and although there is a shift towards employees selecting their own technology and tools it is surely not happening as fast as the shift to mobile computing. This leaves a gap in the market for developers focussed on apps for the mobile enterprise to fill.

A little over 12% of the money-making developers in our survey were targeting the enterprise yet they made on average almost 4 times as much revenue (per person involved in development) as those targeting consumers and typically had more than 4 times as many people involved in app development. Developers targeting professional users rather than their companies only made about 50% more revenue per person than consumer focussed developers and had about twice as many people involved in development. So, while this is a promising market, [tweetable]independent app developers are not replacing the enterprise IT department just yet[/tweetable].

At the bottom of the revenue pile it’s no big shock to see that developers who aren’t sure about their target market make by far the least money. How do you build a great product without knowing who it’s for? The small number of respondents who felt their audience didn’t fit one of our categories, selecting “Other”, may possibly be targeting too small a niche since their revenues are not far above half those of developers building consumer apps.

It’s important not to get confused by the similarity of the increased development team size and higher revenue figures – the chart shows revenue per person, so the effect multiplies. That is, the average enterprise focussed app development organisation is making around 16 times as much revenue as the average consumer focussed one in total. That makes the total revenues of the enterprise developers significantly greater than those of the consumer developers, even though there are around 6 times as many of the latter. Averages hide a lot of detail though. You don’t have to build a large company to be extremely profitable in the enterprise mobility market – smaller development teams actually have much higher revenues per developer. More details on that and important differences between consumer and enterprise app developers will be the subject of a future post.

Agree with our figures or disagree? Drop us a comment.

– Mark (@__MarkW__ )

Categories
Business

Are you using the right app revenue model?

The most popular revenue models appear to be those that are easiest to implement. The developers using them tend to have lower revenues. This may be due to greater competition or it might just be a result of less sophisticated app businesses producing less valuable apps. There are some interesting differences between platforms but [tweetable]subscriptions appear to be a relatively untapped gold mine everywhere[/tweetable], although maybe not for everyone.

VMMoneyNote2_800

Revenue models versus average revenues

Our research shows some significant variation in average developer revenues depending upon the revenue models being employed. An investigation of the relative popularity of revenue models versus revenue generated across the major platforms produces some useful input for app development strategy and planning. Unsurprisingly, the simplest revenue models to implement, like paid downloads and in-app advertising, tend to be the most popular. The often repeated stereotype that “Android users don’t pay for apps” also leads to a strong preference for ad-supported apps on Android, while iOS developers prefer paid downloads. Slightly more surprising is that although Android has a larger user base who seem less inclined to pay up front for their apps, freemium and other in-app purchase schemes are less popular than on iOS. It would seem that on average [tweetable]iOS developers are more sophisticated in their approach to the app business[/tweetable].

Revenue distribution

When considering revenues it’s important to note that the distribution of revenues in the app business is highly concentrated at the top and there are a lot of hobbyists who earn nothing. We exclude most hobbyists, those who’ve not started earning revenue yet, the mega-rich chart toppers and large publishers from our analysis by only counting developers with between $1 per month and $5 million per month in revenues here. Even so, there is a fairly large “middle class” of smaller independent developers with a lot of users and high revenues. As such there’s a massive difference between mean and median revenues even in this subset.

The revenues shown in the chart above don’t necessarily all come from the platform or revenue model they are linked to – [tweetable]developers use multiple revenue models and multiple platforms[/tweetable]. For example, amongst developers who target iOS first the in-app advertising model appears to do much better than for those who target Android. Although iOS advertising rates are higher, this isn’t the primary cause, since very few of our iOS respondents derived most of their revenue from ads. The actual reason is that many of those using ads also used a freemium upgrade model (presumably paying to remove the ads and possibly add features) and derived a significant fraction of their revenue from that also. The same strategy does not appear to work as well on Android. Although not entirely accurate, we’ll refer to revenues by platform and revenue model as a shorthand in the rest of this post because it’s a reasonable approximation in most cases.

Less popular, more people, more revenue

Interpretation caveats aside, one thing that seems clear from this data is: [tweetable]the more popular the revenue model, the less successful the developers using it[/tweetable]. The exception here is contract work, which shows much higher revenues on iOS and lower on Android relative to its popularity. Although there’s some evidence that contract development rates for iOS are slightly higher, the difference is mostly due to where the platforms are most popular with developers. Otherwise, most revenue models show slightly higher mean revenues on Android but significantly lower median revenues. There’s also a link between the average number of people involved in app development in an organisation and the revenue model. More people involved, may signal more complex development for the associated apps. The fact that this is also associated with increased revenue is possibly related to using the extra development complexity (or team size) on a more sophisticated revenue model. It is not the case that more people involved results in higher average revenues per person in general. In fact, there is a very strong peak in mean revenue per person for organisations with 6-10 people involved in development – there are probably some significant efficiency losses above this size.

The subscriptions gold mine

Across both Android and iOS, [tweetable]subscriptions generate by far the highest mean revenues[/tweetable]. Median revenues for subscriptions are also higher than every revenue model except contract development. At the same time, only just over 10% of developers use a subscription model and the average number of people involved is lower than for all but the simplest revenue models. Mean monthly subscription revenues for Android-first developers are 3 times higher than for their iOS-first counterparts. It seems that Android users not paying doesn’t apply to subscriptions. However, median monthly subscription revenues on Android are less than half those on iOS, so there are a smaller number of very big winners with Android-first subscription businesses.

Should more developers be trying to build subscription-based businesses? Almost certainly yes, but they’re not for everyone. While 53% of developers using the paid download model and 45% of those using in-app advertising are in 1-person companies, that’s only the case for 20% of subscription businesses. In fact 53% of the subscription businesses in our survey had more than 5 people, not all of which are directly involved in app development. This is because many popular subscriptions include continuously updated content and there’s significantly more work (and cost) involved in providing ongoing content for subscribers. Our survey has also shown that money is not a primary motivator for lots of developers and managing the content side of the business may not be something they’d want to be involved with. For entrepreneurs looking to build successful app businesses, the subscription model is definitely worthy of further investigation.

– Mark