The number of APIs and cloud services continues to skyrocket as more and more companies seek to get developers onboard with their services. All too often, a “build it and they will come” mentality guides strategy and marketing decisions for these products, leaving them in a crowded marketplace without enough differentiation, underlying value and visibility to succeed. We’ll cover technical factors of successful APIs in a future issue; for now, we’ll answer the question of how you can build a valuable API, which must be the foundation of any success.
Hardly a day goes by without an announcement regarding a new API for mobile developers. ProgrammableWeb, a popular site that tracks APIs, now lists more than 12,000 open APIs developers can use, with growth accelerating – it leapt from 5,000 APIs to 6,000 in its listings in just three months (for comparison, it took PW more than 2.5 years after its launch in 2005 to get to its first 1000 APIs). Meanwhile, all variety of cloud services are launching, from fully integrated backend-as-a-service platforms to push notifications to storage.
The situation isn’t totally dissimilar to what’s happening with mobile apps in appstores. The number of products is growing, the market is getting more crowded and it’s becoming more and more difficult to standout, particularly as the market is flooded with substandard products that make it hard for consumers to find the best solutions. There is a tendency to see this issue – whether it’s for apps or APIs – as a marketing or advertising issue, but it’s much more fundamental than that. Marketing does play a role, but it can’t be a crutch to overcome a low-value or otherwise poor product. The most fundamental aspect of an API or cloud service’s success is the value it delivers to developers.
Value is a function of two main components: the benefit a product delivers, and its cost. This raises two basic questions for API and cloud service providers:
What are the services developers want, and see benefit in?
How should the service be monetized and priced?
What do developers want?
There are a few ways to assess developer demand for APIs and cloud services. The first is to examine which ones are currently being used the most. It is very difficult to assess the most-used APIs in mobile apps, but research from the analytics firm Mopapp indicates that Twitter has one of the most popular APIs, with 63% of the top 200 free apps in the US integrating it (compared to 21% for Facebook).
We can take a look at the wider developer space through ProgrammableWeb’s directory of mashups and APIs, which indicates the following APIs are the most widely used in Web mashups:
Google Maps
Twitter
YouTube
Flickr
Amazon eCommerce
Facebook
Twilio
eBay
Google Search
Microsoft Bing Maps
(Note: this is historical data and should be seen as indicative rather than conclusive.)
This hits on some of the most popular areas: maps and location services, social networks, content, commerce, search and messaging, and match up with a recent IDC/Appcelerator survey that asked mobile app developers the cloud services they were most interested in connecting their apps to (see right).
Both of these sets of data should be taken with a grain of salt, though. They’re essentially backward-looking and focused on what’s already available in the market, rather than services or products that haven’t yet emerged. But they do show the general areas in which developers are looking for help from outside services and APIs: social integration and identity, storage, content (really social content, such as photos, reviews and sharing), and so on.
What is it that makes these areas so attractive to developers? It is their ability to deliver one or more key benefits:
Reach/audience – A service like Facebook, Twitter or LinkedIn delivers a large and valuable audience to developers, easing the path to adoption for their user base.
Ease of use/functionality – Services like login/account management or push notifications can be implemented by developers themselves, but require infrastructure investment, time or other constrained resources.
Access to valuable data or content – There are many kinds of useful data and content developers want to integrate into their apps, such as maps and location data, sports scores, videos, news content, music and so on.
Access to markets or monetization – If an API or service can deliver customers or revenues to a developer (such as through auction listings, affiliate sales or another means), it is incredibly valuable.
Focusing on these benefits (and being careful not to overestimate how you deliver on them) will help result in a valuable service. But a service that has value for developers is only part of the challenge; the other side is choosing a service that has value for your business as well.
One of the problems of developing services based on their presumed popularity from the above data is that it only looks at the demand side of the equation, and not the supply in the market. That is to say, while something like mapping APIs and services are widely used and highly popular, the market for them is also highly saturated and competitive, particularly for basic offerings. The same could be said for something like SMS messaging services, where the basic services offered are commoditized. Without being able to significantly alter either the benefit or the cost of services in these areas, they may not be attractive ones to enter.
A good example here could be Twilio’s SMS API. While it offers largely the same functionality as any other SMS API, operator or messaging aggregator, it was able to significantly increase the value of its offering over competitors by emphasizing and enhancing its ease of use. With all other factors held equal, it then becomes extremely competitive, even at the same cost level, as competitors.
What is valuable to your business?
Creating an offering that is valuable and attractive to developers is the key starting point, but that offering needs to be made attractive to your business as well. Capitalizing on developer demand for your service requires the right business model and monetization strategy.
WIP’s observation has been that many APIs and cloud services are typically launched with one of two models:
a per-dip model, where each function or call carries a distinct charge
a free model, with hope for some form of magical indirect revenue generation.
While both models have their merits, they must be correctly applied!
Before determining a business model and pricing strategy, you must consider the goal of your API. First, is it direct monetization? That is, is your API itself intended to be a revenue generator? This should be considered very carefully, simply because of the very high resistance many developers have to paying for APIs and related services. There are many reasons for this; it’s not simply being a cheapskate.
First, free options abound for many types of services, either because providers don’t know how else to compete, or a provider is choosing to monetize their API indirectly (if at all). Second, many developers, particularly in mobile, still struggle with monetization, and they simply don’t have the means to pay for APIs.
But another reason looms large: the decision-making process for developers at many companies, particularly anything bigger than small startups. While a developer may be the user of an API, and generally the one who finds and recommends it, they often don’t have buying power themselves, or the purchasing process takes a significant amount of time – in both instances, a free service will be simpler and easier for them to implement.
There are many use cases in which indirect monetization via a free API makes sense over paid API access, and this model is favored by many of the most-used APIs (Twitter, Facebook, Google, Netflix, Salesforce.com and more). These include:
Driving end users to or enhancing a paid service (such as Netflix, Salesforce)
Increasing traffic and audience for an ad-supported service (Twitter, Facebook, Google)
Content spread and syndication (NPR, ESPN)
Commerce (Amazon, eBay)
All of the examples cited above have a solid business model and monetization funnel beneath them; their APIs bring value to the business by filling that funnel, not by acting as a toll collector on it. That's a key point: an API needs to work hand-in-hand with the goals and models of the business of its provider, and the belief in being able to monetize developers directly shouldn’t override that.
API Business Models
Source: ProgrammableWeb
If the decision is made to directly monetize an API, the default thinking is generally to use a per-dip model, in which the developer is charged for each call or transaction (such as a map lookup or SMS sent). Why? Because it’s easy and its pay-for-what-you-use nature seems good and fair. However, as noted above, this model is often misapplied.
It’s important to consider this model from the developer perspective: if I’m being charged on a per-unit basis, can I reasonably monetize each of those units? More often than not, the answer is no, and furthermore, this choice often forces developers to choose between the best user experience and financial safety.
The models typically used for SMS and push notifications provide a good example of this. SMS is typically billed per message, while Urban Airship, a leading provider of push notifications, has service tiers based on an app’s number of active users (see right). This means a few things for developers:
They have predictability over monthly charges, are aren’t held hostage by the growth of their services. With a per-dip model, user growth comes at a very high price.
They can focus on monetizing users and apps as a whole, not trying to monetize individual items or services within an app on a per-use basis.
They can integrate push notifications how they see fit for the best user experience, rather than integrating messages on what they can afford.
For high-volume services, a per-dip model is often a bad one. For services that will be consumed by an end user as part of a subscription or as a part of a larger app, they’re often not a good idea. Keep in mind that on platforms like iOS, subscription billing is difficult, if not impossible, complicating things further.
But with all paid services, regardless of model, the concept of runway is an important one. Whether through a sandbox, free trial or a freemium offering, it is essential that developers have the opportunity to explore and use a service without a significant financial commitment. This is important for developers at large companies, given the buying process constraints noted above, as well as for smaller developers, who face financial and monetization constraints.
Conclusion
The key to a successful API offering is value, both for the developer and for the provider. When building developer value, focus on maximizing one or more of these key benefits:
Reach/audience
Ease of use/functionality
Access to valuable data or content
Access to markets and monetization
Maximizing the value for your business relies heavily on choosing the right business model and pricing strategy, particularly the decision to directly or indirectly monetize your API. Incorrectly matching your business model and/or pricing structure to the use cases of your app will have a negative effect on value to developers, and undermine your efforts.
Tagged: #Amazon, #APIs, #BusinessModel, #developers, #eBay, #eCommerce, #Flickr, #Google, #IDC, #Microsoft, #mobile, #ProgrammableWeb, #programming, #SMS, #Twilio, #Twitter, #Wireless, #YouTube