Monetizing the App Store: Guest Post, Fergus O’Reilly, SAP
Fergus O’Reilly is a chief solutions expert at SAP. In this guest post, he explores the drivers of Apple’s success with the iPhone/App Store system and what it means for rival app stores, telco developer communities, and your core billing systems. Telco 2.0 Europe delegates were notably concerned that app stores were turning into “Crazy Frog 2.0”, and that not enough effort was going into enterprise CEBP, as the chart below shows. Crazy Frog 2.0 would characterise a market dominated by impulse buys of low value products by consumers, with minimal stickiness or brand awareness.
Clearly, our delegates preferred the possibility of a bigger and more sustainable market in the enterprise, and one that would preferentially consist of recurring service revenues rather than one-off sales.
Which of the following markets are most profitable for telcos to focus on?
Apple wowed the world with the iPhone (I am a happy owner) and then had more glory heaped on them for their App Store concept. Since the App Store was launched in July 2008, the demand for mobile applications has exploded and more and more companies - from telecom operators to wireless device manufactures to media companies - are racing to launch their own versions. For instance, RIM has launched the BlackBerry App World, Google has the Android Market, the TV set-top box maker Roku will soon launch their own version, and BMW recently introduced its Concept BMW Application Store.
While the app store is arguably the hottest topic in the telecom and high tech industry right now, the concept of paying for downloading apps to your phone is not new. Operators have been doing it for years. Starting in the late 1990s, end-users would pay either a one-time or basic subscription fee to download small arcade games, ringtone, etc. on a mobile web browser or microbrowsers. In addition, the concept of a device manufacturer or other non-operator entity running the store is also an old idea; check out what was done in the past by Palm, Handspring, Handango and many others.
What Apple did when it introduced its App Store was to revitalize the idea with some tweaks to the model:
- Better platform: the iPhone offers a development environment and a developer-relations community that has triggered a race among handset manufacturers to match it.
- Better revenue share model: the simple Apple 30% / developer 70% split is generous to the developers while covering Apple’s costs plus a little margin. Apple is interested in shipping lots of iPhones and that is where they make their revenue. Encouraging application development makes the iPhone a more attractive device and Apple will sell more phones. They do not really need to make money off the applications sales directly. This is an advantage any device manufacturer can have if they have a proprietary platform. Operators have not and cannot use the same business model.
- Better retailing: Apple did some simple things in their store like allowing consumer ratings and rankings of popular apps per category. Simple stuff that Amazon showed the world how to do 14 years ago! But many of the operator walled garden portals did not even do this. There is still plenty of room left to improve the store with application recommendation systems - “people who bought this also bought those.”
App Store or Services Platforms?
Right now, the App Store is very much a product-centric model: you buy an application, it is an atomic transaction: you pay once, you own it. Apps have unitary prices which are the same for everyone shopping in the store.
A Services Platform would be quite different. Instead of buying applications you would sign up for services. This is much more like the telecom operator model. Service pricing would depend on who you were, how you used the service, whether you bought related services or optional extras. So service pricing requires packaging, bundles, cross-product discounts, rewards and discounts for regular users. There are already a number of developers on the Apple App Store that complain that they do not have this kind of pricing flexibility available on the platform.
Service pricing could also be used as an incentive to attract high-end developers. In this increasingly competitive market, cultivating and fostering the app developer community is critical. This means efficient and repeatable partner on-boarding, such as putting in place a rapid submission and approval processes and offering packaged access to secure test environments, sandboxes, beta testing services, etc. It also means allowing developers to choose between charging a set fixed price for their apps or a services pricing model with recurring fees, bundles, discounts, promotions, etc. The developer sign-up and contract negotiation process needs to look different and follow different approval rules when a small developer applies compared to a large brand powerhouse. But it all needs to be automated to allow for scaling to tens of thousands of developers.
A Service Platform would also support online services and give developers a platform to connect to and use for creative mash-ups. For instance, your phone knows who you are and your SIM card provides watertight identity management. A Service Platform could leverage this to provide things like single-sign-on, anonymized identity management, or user preference management across all online apps like Facebook, Twitter, Yahoo! email, etc. This turns an operator platform into a Network-as-a-Service (NaaS) offering. And if operators band together to standardize how these NaaS platforms are accessed, using unified APIs and ensuring inter-carrier interoperability, then that becomes a very powerful value proposition for developers: develop once and deploy across multiple global carriers, reaching hundreds of millions of subscribers.
Are Your Systems Ready to Support Services?
For many of those entering this space, figuring out how to monetize their assets is an enormous challenge. In contrast to a product-centric model, service-based business models are necessarily multi-sided and highly interlinked. As this app space continues to develop, there is likely to continue to be much experimentation in the areas of pricing, packaging and revenue sharing. Those who can establish a firm place controlling the flow of transactions between users, developers and advertisers, stand to gain the most. Business model flexibility is therefore a strong requirement, as is putting in place the right revenue billing and revenue sharing solution to handle:
- End-Customer Billing: all services built by the community of developers should be promoted using a mix of eCommerce-style onetime payments and subscription or usage-based pricing models. Although pricing and promotions for a third party application or service should be under the developer’s control, the operator should be able to manage packages and pricing for groups of services sold together as bundles.
- Operator Revenue Sharing: operators running an app store for their developer partners need to craft win-win revenue sharing deals depending on the partner and the application.
- Developer Billing: direct billing of third party developers for their use of the NaaS platform itself and the different operator services and APIs that are exposed on it. This needs to support a wide range of different types of developer from large enterprises with negotiated volume discounts, to small independent developers or individuals who may need to be on credit-limited or prepaid plans to protect against credit risk.
- Billing-on-behalf-of: developers who roll out applications can choose to charge their customers in a direct relationship.
- Inter-Partner Settlement: some partners may use services developed by other partners in their applications, consequently inter-partner settlement should used reconcile shared revenue.
- Multi-lateral Clearing: The operator is the platform provider who sits in the middle of the money flow between all the different customers and partners and can, potentially, take the valuable position of managing the credit risk for all parties while doing a form of multi-lateral netting (i.e. offsetting the receivables and payables among the different players, with corresponding periodic payments to or from the platform provider).
To meet these demands requires radical changes in business models, business processes, and business support systems. Companies will require a pricing and charging system, such as SAP Converged Charging, that allows them to monetize services dynamically and in real-time, manage revenue sharing between diverse business partners, and sustain massive transaction volumes while rapidly changing their business models and optimizing profitability. In addition, they need to be able to define pricing strategies, test and apply them in real time, manage transactions between partners and feedback historical usage data into the evolution of pricing policies. All of this assured with accurate forecasting and follow up in order to secure profits. The tools to do this are already available today - all companies need to do is apply their creativity to use them to their full extent.
[Ed. - SAP will be giving a stimulus presentation in the M2M session at the 8th Telco 2.0 Executive Brainstorm in Orlando from the 9th-10th December.]