During the recent Mashery Business of APIs conference, I heard from a lot of different companies on how, why, and to what end they were exposing APIs. I was particularly interested in the business model piece of it.
Here is a brief summary of some of the business models that can be associated with an API.
As a BizDev Lead Generation Tool / Funnel
The BizDev Funnel approach towards APIs was something that I heard over and over again. This model goes something like this – you use your API to give away a taste of your content / service, but not so much that somebody can actually build a business with it. Typically, API calls under this approach are capped per day. If the API partner exceeds that amount, they are invited to contact the company’s business development team to explore a partnership.
CNET is one company pursuing this model. The public CNET API is limited to 1500 queries per day, and also offers only limited content (for example, you can pull a review synopsis for a given product, but not the review itself).
Hoovers is another company that is taking this approach. Unlike the CNET model, third parties need to be approved to interact with the Hoovers API (HAPI!) at all. Each applicant is screened by the Hoovers bizdev team, and custom pricing is worked out for each one. Because Hoovers is a data subscription business, they are being very careful about who gets access to their data – if they give away too much, they risk destroying their business. From what I understand, Hoover pricing can range from per listing to, in some cases, revenue sharing with third party API partners.
User Acquisition / Affiliate
Another popular business model related to APIs is the user acquisition / affiliate model. Two great examples of this are Netflix (api review) and Amazon. Both these companies expose massive amounts of commercially valuable data with the hopes of extending their business model (ecommerce and subscription respectively) to the edge.
What’s notable about these two companies is that neither one of them is advertising supported. Each company monetizes its data in a way that presumably, virtually no other third party provider could do (though Netflix apparently through very hard about the implications of Blockbuster grabbing their data via the API). Because they are not advertising supported businesses, they don’t care about eyeballs going to their API partners’ websites – all they care about is that the transaction – for Amazon a sale, and for Netflix a subscription – is initiated on the partner site, and then fed back to Netflix / Amazon for execution.
It sounds like another non-advertising supported business, Best Buy, is pursuing a similar API strategy (called Remix) as well – exposing its product data with the belief that they shouldn’t care where the transaction is initiated as long as they get to execute it.
Pay Per Drink
The Pay per Drink model is the online version of the classic data subscription model. Companies that have traditionally sold big data dumps to subscribers – like Hoovers, InfoUSA, etc – might explore the API as another way to deliver this data, and charge for each call or each record.
A company that is pursuing this model is Alexa. They charge $0.30 per thousand requests.
Advertising
If you suspect that your API has the potential to achieve massive reach, you may want to consider an advertising driven model in which you reserve the right to feed ads out to your API footprint as a condition for allowing others to use the data.
The best example of this model is Google Maps, which recently began serving ads on its API partner sites.
Content Acquisition
The API as content acquisition tool is a variation of the Hub & Spoke model that I’ve covered so often on this blog. You expose your UGC functionality and content via an API with the hopes that third party developers will build additional tools to collect even more content for your database.
Presumably, this is the Twitter approach. By distributing their API for free, they have achieved huge reach, and this reach is generating massive amounts of additional content for Twitter’s database.
While it is certainly possible that Twitter might start charging for its API (pay per drink), or some subset of its API (the firehose), I would expect them to try and monetize primarily at Twitter.com. Twitter’s aspirations seem big enough that I doubt that they will sacrifice reach for revenue at the edge.
Branding / Non-Commercial
This is the approach used by companies like the New York Times, NPR, and many of the Yahoo! APIs, and can be seen as a subset of the BizDev funnel approach.
The idea is this: expose your content and functionality to hobbyist developers and see what kind of stuff they come up with, in the process extending your brand. The non-commercial clause is designed to protect you from other folks monetizing your content.
This is my least favorite kind of API. I feel that if you’re not able to tap into a developer / publisher’s selfish interest, your API is not likely to gain distribution. It seems to me that there is also more policing required to go this route.
Summary
So there you have it – six different strategies you can take for using an API to forward your business goals.
Did I miss any?
For a great summary of API trends, check out Dion Hinchcliff's post.
