John Musser is familiar with the API, and as the founder of the programmable web, he has witnessed thousands of APIs and many business models. Recently, John shared his experience at the keynote address at the 2013 API strategy Conference.
John's most frequently encountered question is "How do you make money with it?" "In fact, the answer to this question depends on why," asked the interviewer, "Why do you want to have an API?" "People have a lot of reasons for wanting to have APIs, which leads to the first API tip that John disclosed in his speech," API strategy is not an API business model. The API strategy is "why" we want a set of APIs, and the business model is how we use APIs to make money.
Looking back on 2005, the API is in the ascendant, when Google Maps came out, the API business model has four core types: "Free", "Developer Pays", "Developer's compensation" and "indirect income". Today, with 2013 years to go, there are still four core types in the API business model, but in each case, there are many ways to provide APIs and get the cash out. So, John's second tip is: "Most APIs have more than one type of ROI." ”
Then, in the keynote speech, John delves into each of the core business models, starting with "free". Contrary to popular belief, "free" is not the main API business model. In the analysis, John takes Facebook as an example and complements all government and public domain APIs-but these free APIs only occupy a "small part" of the entire API business model world.
The second category that John Paints is "developer pays". Under this model, the developer uses the service provided by the API and pays the fee. This classification includes many subcategories, such as "pay on demand"--developers only need to pay for the services or resources they actually use. Here, for example, with Amazon Web Services (AWS), John wrote in the AWS price list: "Users only need to pay for the part they use." There is no minimum consumption limit. The second subcategory is the "ladder" model, and many companies such as MailChimp provide such a model. When the total amount of service used by the user is higher, the lower unit price will be enjoyed. Free Value Added (Freemium) is a well-known model that uses the API of this model to provide its basic features free of charge, but if users want to stack some services (such as additional APIs, higher SLAs, service commissioners, etc.), they will need to pay the corresponding fees. John points out that compete and Google Maps are typical examples of free value-added models. Pricing by unit is another subcategory, and the sprint provides this business model. Here, the APIs charge different fees for different characteristics. The last example of "developer Pay" is "transaction costs", which are similar to those paid by the API, who pay for the percentage of transactions processed. John lists PayPal, stripe, and chargify as examples of this model.
The model relative to "developer Pay" is "developer compensation". This is the third largest category John introduced, and it also contains many subcategories, such as the "Contract revenue sharing" model offered by Amazon's Cooperative Marketing Program (affiliate), under which Developers will be rewarded for customer referrals (referring to customers who recommend other developers to sign up for Amazon's API). Another subcategory is "consumption split", where the developer will receive a commission from the recommended purchase. Here John gives examples of mysimon.com and howstuffworks.com, who use the API of the parity site Shopping.com to support product comparisons and derive benefits from guided clicks. John points out that the income-sharing contract is not a "trivial business". Expedia derives 90% of its total revenue from the Affiliate network that uses its API-worth as much as $2 billion trillion/year. Finally, the "recurrent income sharing" model, rdio.com and other companies to adopt this model, has contracted customers to introduce new customers to subscribe to purchase, will be able to the new customer's subscription period has been a revenue sharing.