API Product and API Monetization

A free video tutorial from Rajeev Sakhuja
11xAWS Certified, Consultant, Mentor, Innovation evangelist
Rating: 4.4 out of 5Instructor rating
7 courses
83,003 students
API Product and API Monetization

Lecture description

Students will learn about the good practice that states "Treat your API like a product if you would like to sell it like a product". 

Also the student will understand the

  • concept of monetization
  • various monetization models
  • technology considerations from the realization perspective

Learn more from the full course

REST API Design, Development & Management

Learn the REST API Concepts, Design best practices, Security practices, Swagger 2.0/OAI, Hands on API Management

07:35:14 of on-demand video • Updated August 2020

Design and Develop RESTful API by applying the best practices & REST constraints
Create practices for API security, versioning, lifecycle management, documentation and other important aspects
Write specifications in Swagger2.0/OAI specifications in YAML format
Create an API management strategy for your enterprise
Leverage some of the common API management platforms for building API proxies (APIGEE, IBM API Connect, Mulesoft Anypoint)
English [Auto]
If a product and monetization in this lecture, I'll cover a good practice that states that you must treat your API as a product, I'll also cover the API monetization models and the technology considerations around ruling out the monetize APIs. Let's start with the definition of a product. A product is anything that can be offered to a market that might satisfy the need or want of the customer. Appia fits this definition very well. Let me give you an example. Today, application developers are looking for ways to build some cool advanced communication features in their application so they have a need and the need is fulfilled by a company called Kullu. They offer advanced communication apps that the application developer can easily integrate or use in their applications. For example, video conferencing, SMS, texting, chatting. All these APIs are available from Clélia because there is a demand for it. Another example is the Amazon Web Services, Amazon Web Services. Also the infrastructure needs of the application developers. Both these organizations are selling API as a product. Let me give you an example of another organization that has nothing to do with technology but are still treating their apps as product. This is the Capital One exchange for Capital One offers some great apps to the developers for free. Their goal is the generation of indirect revenue and brand recognition. As you can see, their website looks nowhere near a typical death portal, and that is the marketing aspect. They also have a community built around the area and they also offer other support channels. And I believe they have a dedicated team for the app for continuous improvement and enhancements. So the Capital One is not only calling the EPA's app products, they're treating them as products. Bottom line is that the selling API as a product, you need to treat the API like a product. Let's dig a little bit deeper into what I mean by creating an API, like a product. Let's say you're a car manufacturer and you would like to release a new model of your car in the market in order to do that. You'll have to follow the typical product lifecycle, which is you need to create a business case to justify the need for a new model and how your company will make money by releasing this new one. Second thing you need to do is carry out some research. Who is going to be the target customers for this new model and what are their needs? And what's next thing is you will dedicate some resources, create some teams who would build this car model, and then there is marketing. You would make sure that the new car model is promoted to the target segment in the best possible way. And then you will launch the car and be ready for the full launch support. Now, this was about the creation of a new car model. Let's see how the same cycle can be applied to the creation of IPS. So treating the EPA like a product, like a car would mean that we have to follow the same steps for planning and releasing that we followed for the car. From the business case perspective, you need to come up with the reason why the organization should release an API. Is it for new revenue? Is it for brand awareness or is it for new partnership models? Or there may be other reasons why you may want to do it once you have a good business case. The next thing is research. Who is going to be the consumer for the EPA? What is their need and wants and why would they use your EPA? What kind of an incentive would you need to provide in order to make them use your EPA? After the Research Council, the creation of the EPA, the typical delivery and planning and some kind of a pilot to ensure that you're moving in the right direction. Next thing is marketing. So how would the consumers come to know about your apps? It is not possible to just create the apps and expect consumers to start using it. You have to do something about the marketing also. So some examples are you can generate some buzz with events such as Hecate, ones you can promote by video, blogging, maybe even press release and paid advertisement launch and post launch. And thus you have to think about how you're going to launch your apps. So example is you can create some cool application on using your app and release it to open source and then post launch. You need to think about how you're going to support the application developers for Europe's bottom line is that you have to treat the iPad like a product in order to sell it as a product. So typically the data and services are exposed as Epper and this API can be sold as an API product to the developers to generate direct or indirect revenue. But this is the API monetization where you are generating revenue by selling the product. Let me give you an example of direct and indirect revenue. Salesforce.com and Amazon.com charges their customer for the use of their apps, and that's the example of direct revenue. They're getting the money from the customer, whereas Capital One and Best Buy, they're not getting any revenue generated by way of selling the apps directly to the revenue is generated when the developers are using the apps to promote their services or to sell their merchandise. There are multiple monetization models. I'll go to some of the common ones. First one is the free and the free model. The API provider offers their API for free to the developer community. These are the examples Facebook, Twitter, LinkedIn. By way of these free apps, they're expanding their reach. They are expanding their brand recognition. So that's the reason free apps are very commonly available for social platforms. Next is the freemium model. In the freemium model, the app provider creates tiers of product and the first year is the feature that the developer can use for free, obviously. And the premium tiers are paid tiers. And the developer who is using the free tier can any time switch to the premium tiers. Google Maps, IBM, Watson, IPG are the examples that use the freemium model for their apps. Next one is the enterprise based model. In this model, the organization offering the APIs pays the developer to use the EPA. For example, Amazon Associates, Amazon Associates are the developer who are using these APIs in their application to sell Amazon products. And if they're able to make the sale from the apps, then they get paid by Amazon. Same thing is true for eBay and Expedia. Last one is the developer base. No developer pays as the name indicates here. The developer is paying the app provider organization for the use of the API. There are a couple of models under this one. First one is pay as you go Amazon Web Services. You can use the services offered by Amazon and then depending on what you use, you get a monthly statement next month, a subscription model, subscription model as you pay a license fee for a certain number of users or a certain number of licenses. And that's the subscription model. Salesforce is an example of that. And then you have transaction based model in which the developer pays for the transaction. For example, PayPal and other payment services like Skype. They use this model Satullo. I have discussed the business aspect of API monetization. Now let's go through some technology consideration aspects that as an API provider, you'll have to keep in mind, Klosters, how would you create the tiered product definitions? Fortunately, almost all API management products support the concept of products and plans which allow you to create these tiered definitions for the API products usage metering. How would you measure the usage of the apps by specific developer subscription manager and show that there are no overages and ways by which you can handle those overages? Reporting there has to be some kind of reports to be generated for the business as well as for the consumers of the API. In order to support the indirect revenue model, you need to track your partners and also track the revenue generated by your partners. Unfortunately, the kind of features you need for monetization. I'm not available out of the box on most of the app management platforms, but a number of these management platforms sell these add on modules for market monetization. Let's summarize in this lecture, I covered the Apple product and monetization. If you want to sell your app as a product, you must treat it as a product. Monetization is about business and technology. Once you have decided to monetize your IPOs unit or decide on a business model, and then you also need to think about the technical aspects to support the business model that you have decided to go with.