The previous chapters focused solely on the customer. We researched how numerous they are, investigated their motivations and needs, and chose app features expressly for them. Everything has been about them – now it’s time for them to give something back.
Web app pricing is both an art and a science. Our objective over the next two chapters is to maximise the science part.
In this chapter we examine common business model options that you have to generate app revenue. Keep in mind that these models are not mutually exclusive: you can implement a combination of revenue streams for your app.
Under the subscription model the customer is charged a regular, recurring fee to use the app. Typically, the frequency of payments is monthly, which fits comfortably with personal customers (monthly salaries) and the business market (monthly accounts).
Annual billing cycles have pros and cons. On the downside, you commit to provide the service for a year, you can’t easily increase the cost, cash flow isn’t as smooth, and some merchant accounts won’t let you charge for a service you haven’t provided yet. Most importantly, if you only offer annual billing you introduce a higher financial barrier to entry and greater perceived risk for potential customers.
On the plus side, your payment processing fees will be lower (fewer transactions) and the customer commits to payment for a full year. Some larger businesses may find it easier to be invoiced on an annual basis, especially where the individual buyer of your service doesn’t have a company credit card and must raise an invoice to purchase your app.
As a rule of thumb, if your app is targeted at enterprise customers or the total annual price is around $25 or less, it makes sense to consider (or at least offer) annual subscriptions. Otherwise, it’s safer to stick with a monthly subscription model.
Should you impose a minimum contract length? Almost certainly not. On rare occasions an app will incur significant marginal costs for each sign-up, costs that need to be recouped over a number of smaller payments. If your app isn’t one of these, there’s no reason to impose a minimum contract.
You’ll be better off because you won’t need to build the functionality to enforce the minimum contract, which is more complicated than telling customers they can join or leave whenever they want, and they will be better off because they’re treated fairly.
Variations on the subscription model include:
Freemium is really a special case of the variable price subscription, where one of the subscription options (with the least features, capacity or users) is free.
Although this pricing model is fashionable, it’s only recommended if you know your numbers and margins inside-out. Freemium is a marketing tactic and is only a sensible approach when the average profit per user (including paid and free users) outweighs the equivalent marketing cost to attract those paid customers.
Consider freemium if all of the following conditions are met:
In this model the app is provided free to the end users; app revenue is collected from a third party in return for a service.
One or more third parties place clearly defined adverts in the web app. Variations include image banners, text adverts, inline links, pop-overs and interstitial adverts. These are normally charged by cost per click (CPC), cost per action (CPA), or cost per thousand impressions (CPM).
It’s difficult to estimate how much revenue adverts are likely to generate for a new app; it varies depending on the quantity, position and style of adverts, the type of app, the audience, and the advert network.
Many people choose to use Google AdWords because of its simplicity. If you want to make a conservative estimate using CPC figures you might expect an average click-through rate of anywhere between 0.2% and 3%, earning revenue of between $0.10 and $0.30 per click. If you estimate that your app generates 50,000 advert impressions a month (say, from two adverts on an interface that is displayed 25,000 times), this equates to $10 per month at the lower end or $450 at the top end.
Web apps that are used by customers to find important information or perform a specific task are more likely to generate higher click-through rates than those used for entertainment or social purposes. Similarly, web apps associated with high-value topics (such as insurance, medicine or health) are more likely to produce high-value revenue per click, up to multiple dollars per click.
An app generating 50,000 advert impressions per month that highlights which bars your friends check in to will generate revenue at the lower end of the $10 to $450 range, whereas a car maintenance app can expect to reach the higher end of the range or more.
One or more third parties become the official sponsor(s) of the web app, either permanently or for a fixed period of time. In return for a sponsorship fee you might offer prominent adverts, incorporation of their branding, or data licensing agreements if your app data is valuable. Of course, never sell personally identifying customer data.
If your app delivers lists of results (maybe it’s a niche search engine, comparison app, entertainment listing or job board) third parties might pay to be included in the results or to have highly visible, prioritised listings.
Paid content is the equivalent of an ‘advertorial’: third parties pay to include marketing-led content in the web app. This model is usually better suited to content-rich websites than functionality-rich web apps.
Third parties are allowed to re-use the content or data (not customer data) from the web app for their own purposes, usually republishing, adding value to their own app. This might come in the form of an authenticated API.
The users of the app make individual, ad hoc transactional purchases.
The user is charged a fee to use an online service, either for a single use, or for a limited time. This includes the credits model, for example, ten uses of the service for a fixed cost.
The traditional e-commerce model: the user purchases one or more physical products, which typically have non-arbitrary costs associated with their production.
The user purchases a digital product that typically has a negligible cost of replication. These include virtual gifts, in-game items, and other virtual assets. This model also includes the sale of related applications in support of a free main app, like an accompanying paid-for iPhone, Android or other mobile app.
The web app relies on voluntary donations. Some apps acknowledge users who have donated by highlighting their usernames on public interfaces with an icon.
With these models a substantial user base must be established before revenue can be generated from the app.
This variation is most suitable to apps that store user-generated content: books, posters and other products for sale are repurposed out of original app content. For example, many free online photo albums provide a service to buy printed personalised calendars and mugs.
The web app establishes a new development platform (in the manner of Facebook and Twitter) and third parties are charged to participate once a significant audience has been established.
Build a public profile for yourself or your company or both by maintaining a highly visible relationship between you and the app. The success of the app becomes closely associated with your professional abilities, enabling you to generate money from associated conference presentations, workshops, books and consulting work.
This is the least strategic of the models, in that you don’t worry too much about having a revenue model but instead rely on the eventual success and popularity of the app to generate interest from buyers, making revenue generation someone else’s problem (see: YouTube).
In many cases, large technology companies such as Google and Facebook acquire small web apps for the talent or team behind them, rather than the apps themselves, so be prepared to eventually move home and work for a larger company if acquisition is your goal.
Choose a pricing model that suits your app and market.