To many companies and independent developers -- not just software publishers -- mobile apps represent something even more powerful and important than a brand-new platform to deploy apps on. It's a new and dynamic source of revenue, one with a lot of room to grow. And given how tough it can be to make money selling software at all, especially in this world of open-source and free Web apps, any proven way to make money in that field can become a magnet.
To many companies and independent developers -- not just software publishers -- mobile apps represent something even more powerful and important than a brand-new platform to deploy apps on. It's a new and dynamic source of revenue, one with a lot of room to grow. And given how tough it can be to make money selling software at all, especially in this world of open-source and free Web apps, any proven way to make money in that field can become a magnet.
Just like there's more than one way to deliver software in general, there's more than one way to monetize mobile applications. The various strategies aren't conflicting, but complementary. Each app can use the business model -- or models -- best suited to it.
With mobile apps, the purchasing process varies wildly, depending on which operating system you're dealing with. On the iPhone, everything's done through one interface: the App Store in iTunes. Windows Phone 7 supports direct payment via credit cards and third-party billing of the customer's service provider. Purchasing through a service provider is convenient, but I imagine people might still opt for credit cards to avoid the possibility of spurious charges on their phone bills.
But with Android, the dreaded "F" word -- fragmentation -- comes into the picture. The main way to pay for apps through the Android Market is via Google Checkout, widely criticized for its bad end-user experiences. You can also pay the app merchant directly and there are a number of other merchant mechanisms ... all different. (PayPal has also recently been added to the mix.)
What's most lacking in Android right now is a single, consistent interface for payments. The most seamless solution would be an API that allows app purchases to be added to the carrier's bill (with user consent, of course), which would make the process of purchasing an application all but frictionless. This hasn't happened yet, but Patrick Mork, vice president of marketing for GetJar, a cross-platform mobile app store, claims that it is "right around the corner" and that Google has made no secret of its negotiations with the various carriers to make this possible. Integration with PayPal is also a step in the right direction, even if not everyone uses it.
Less clear is whether such a sea change will require a new version of Android -- meaning those stuck on older handsets that aren't being updated to newer editions of the OS would be left behind. Because Apple and Microsoft both have ecosystems where the purchasing system is already pretty seamless, Android runs the risk of falling behind unless the vast majority of its existing installed base can be brought up to speed when new merchant mechanisms arrive. And because of the way Android is delivered to the end user -- by the handset maker rather than by Google alone, and with any number of gratuitous changes -- a good chunk of the existing generation of Android phones might remain stuck on the old-school merchant systems.
The need to make app purchasing as convenient as possible will only become more important over time, to both the people buying and selling them. Smartphones have become increasingly prevalent among consumers as well as business people; many new users have no experience with buying an app and don't want the experience to be more complex than a click or two. "Many apps are currently purchased on an impulse," says Ric Ferraro, founder of mobile start-up GeoMe. "People crave apps in the same way [as candy bars], and the longer it takes to buy the app, the less likely it is that the purchase will be completed."
Mork puts it another way: "The best purchasing experience is probably the one where you never have to leave the app."
Standing out from the crowd
Along with ease of purchase, discoverability -- how easily you can find a given app and pick it out from its competition -- will also become increasingly important. I've read more than a few comments to the effect that one drawback of the Android app stores is a proliferation of me-too apps that duplicate functionality to the point of redundancy.
From this comes the argument that an app store with a more carefully curated selection of products is more genuinely useful -- like the iTunes app store, for instance. But it's also possible to make an argument that the size of the store is not as important as the interface used to query it. Few people complain about the size of Amazon.com's catalog, in part because it's relatively easy to drill down and narrow the scope of a search.
Another possible solution would be a universal app catalog -- "a single store or a single set of standards which can be accessed independent of the type of mobile device or OS it is running," as Ferraro describes it. "Some initiatives are being set up to attempt this -- for example, the Wholesale Applications Community initiative sponsored by the GSM Association could go a long way in setting unified standards and creating a single platform."
That wouldn't make things much easier for developers, who would still have to produce and test variations of a given app for different platforms -- but the app market is driven by consumers and not developers alone, and where the consumers go, the developers inevitably must follow.
The cost of selling
One other major factor that comes into play when selling an app is the cost of making the app available in the first place. Apple's iTunes store splits revenue 70-30, with Apple getting the 30%. Windows Phone 7's app store has a similar 70-30 split, but a portion of Microsoft's 30% is distributed back to the network operators. Both also have application requirements and yearly membership fees -- $99 for Microsoft, and from $99 to $299 for Apple, depending on whether you get the Standard or Enterprise iPhone software development kit.
The Android Market also features a 70-30 revenue split, but the 30% is distributed between the payment processor and the carrier. The registration fee for developers is also only $25, but an unlocked developer phone, either the Android Dev Phone or the Google Nexus One, can cost upwards of $500. These phones are not required, but they provide some major power-developer features: They can work with any GSM network, and the Android Dev phone also lets you install any custom Android system image.
Alternative places to obtain apps are also starting to become available. For example, Verizon is planning to open its Android V Cast apps store sometime in November, for which it will be offering a 70-30 revenue split. GetJar, an independent site, takes a varying fee for each app download, using a bidding system that starts at one cent per download.
Making a living at apps
All that being said, there are a number of different strategies that developers are using to earn money with their apps -- most outside the traditional pay-for-product model.
The freemium model
The first and most basic approach to monetizing a mobile app is to just sell the application itself. But even a method this elementary is fraught with complexities. After all, how much will people be willing to pay for a given mobile app? Set the price too low and you can't cover development costs; set it too high and nobody will touch it.
One quick way to resolve that problem is to adopt an approach that's been used in the PC world for decades: Give away a minimally functional version of the application -- sometimes ad-supported, sometimes just outfitted with nag boxes -- and encourage the user to buy the full version. The missing feature or features don't have to be significant but should be worth paying for. Another way to put this would be: Give away the app, sell the functionality.
The word freemium has been coined to describe this approach, and it has quickly become an essential means of bringing a mobile app to market. Ferraro described the freemium model in his blog as "a classic marketing tool available to mobile app developers to maintain the perception of a free service, while attempting to lock-in customers into some type of charging mechanism."
The key word here is perception: As long as people feel as if they're getting something for free, they don't mind as much if they have to pay down the line -- even if they have to pay again and again. What matters is the sense that they're getting something for their investment.
Online games have developed this to the level of an art form. As subscription-based games lose favor and "freemium" gaming comes to the fore, the game makers have come up with any number of ways to scare up revenue that don't depend on selling the game itself. Ferraro concurred on this point in an e-mail interview: "App publishers can monetize free by capitalizing on the audience they obtained, and promoting upgrades. This is particularly visible in mobile games, where more advanced gaming levels are only available at a premium."
That said, reluctance on the part of app makers has been one obstacle to use of the freemium model. "Publishers of well-known brands didn't want to be perceived as giving things away or devaluing the brand," says GetJar's Mork. "But this has changed in the past couple of years." Electronic Arts, for instance, has been moving toward a freemium model for its online games -- something enhanced all the more by its purchase of game publisher Chillingo, creator of the hit game Angry Birds. Chillingo's game-development SDK includes technology to easily create freemium applications, something useful to any company that wants to push out such applications across multiple mobile platforms.
Microsoft sensed, quite correctly, the need for developers to create freemium apps. The Windows Phone 7 SDK has direct provisions for this. The free and full versions of an app created with the SDK can be the same binary; all that's needed is an unlock code. No new download is required. This takes the work out of building a separate trial version -- and gives app developers that many fewer excuses not to offer both options.
The service-and-subscription model
A major business model for mobile apps is to sell access to a service and give away an application that's just a convenient front-end for that service. The biggest question is: What service is worth paying for?
It's not just a question of the service being useful. It's about the integrity of the data provided by that service as well. Consider Zagat, the venerable dining and entertainment guide, which has a subscription version of its review service accessible through its mobile apps for $24.95 a year. Zagat's main competition is from crowd-sourced services like Yelp, but Zagat's business model is based on the idea that its information has such a known pedigree, it's worth paying for. Yelp's database may be contributed to by a broader range of people, but it's arguably much messier and more inconsistent.
Another method for selling data involves creating applications that offer a repository of locally stored data. For example, let's say you worked for a company that is known for publishing foreign-language dictionaries, and you wanted to sell mobile versions of its books. You could give away the app itself, with a minimal version of the dictionary data thrown in on top of that (say, 2,000 words), then sell the full-blown version of the dictionary, either all at once or in a regularly updated, periodic-subscription version. This wouldn't stop amateur competitors from creating their own apps and data sets, but a free dictionary that's not very accurate would have less appeal to a serious language student than a modestly priced one that has a brand-name pedigree behind it.
The ad-funded model
A third way to generate revenue from mobile apps is a method ported directly over from the Web at large: advertising. But be aware: Ad-supported apps come with all the controversies associated with using advertising as a revenue model, plus a few new ones.
Ad-supported apps can serve as a way to hook people into buying a full version of a program without the ads. For example, the MixZing Music Player for Android has a free, ad-supported version; pay $6.99 for the full version, and you not only remove the ads (which are at least unobtrusive), but unlock a slew of extra features, like an MP3 tag editor.
The problem with ads in a mobile application is -- for lack of a better word -- acreage. On an ad-supported Web page, ads can run in banner or skyscraper elements confined to the edges of the page and don't have to be as intrusive. With a mobile app, the small screen means any ad is going to eat into the UI, and a badly integrated ad will turn people off. Ads placed too near controls, for instance, may mistakenly intercept button-press actions.
Another small drawback to advertising in mobile apps: The ad system is all but useless if the user doesn't have an active data connection. This will become less of an obstacle as more mobile devices are sold with some form of data plan included and as municipal Wi-Fi becomes more pervasive. (Also, an ad can still be effective, even if it clicking on it doesn't work due to a lack of networking. As long as it raises some awareness in the mind of the viewer, it's still doing its job.)
Another method of monetizing through advertising is using revenue generated through a search engine. This has been Mozilla's model with Firefox and could just as easily be applied to mobile apps as well. Whenever a user executes a Web search via Firefox's native search box, a certain percentage of ad revenue generated from the search goes back to Mozilla through an affiliate program.
The downside to this approach is that it lends itself only to applications that have some search component -- such as a mobile browser -- which make up a very small segment of the existing app mix. That said, it's entirely possible that creative methods of integrating search with mobile apps will make search-engine revenue that much more viable a choice.
No comments:
Post a Comment