Bruno Pedro
Growing your business with an API
This article summarizes a talk I recently gave at the Nordic APIs Platform Summit in Stockholm, Sweden. The full title of the presentation is “Growing your business with an API: how to measure your success” and it explores the idea that you should be able to measure how your API is contributing to your business revenue.
Introduction #
How can you grow your business revenue by using APIs? In this article, you will understand the concept of “Integrated Product” and how it can help you reach product-market fit and generate revenue. You will also learn how to effectively measure the success of your API and its integrations with multiple third parties. By the end, you’ll be able to identify which parts of your API need improvement, which are the ones driving revenue, and the ones that should be deprecated.
Let’s start by taking a fresh look at your product. How exactly are your customers using your product? An answer to that is the concept of Whole Product.
Whole Product #
Regis McKenna is a marketer famous for having helped launch products such as the first Intel microprocessor, and Apple’s first personal computer. He also coined the term Whole Product and defined the concept as a way to help marketers better understand their audiences. Geoffrey Moore later popularized the idea by further exploring it in his book “Crossing the Chasm.”
Customers aren’t using your product alone. They’re most certainly using it in combination with other products and applications. Sometimes your product can be a large part of some whole product and can be seen by customers as the central part of a more significant experience.
Other times, your product is just a small part of some other whole product and will act as an add-on. Your product might then help another product reach a particular audience or keep a specific target market engaged.
A possible way to have your whole product is to make sure you surround it with add-ons that make customers want to use it. The result is something called the Augmented Product.
Augmented Product #
Augmenting a product consists in enhancing it with anything that might make customers use it in a sustained way over time. Philip Kotler is another marketer known for having created the “Total Product Concept” where he defines the augmented product as all the “additional non-tangible benefits that a product can offer.”
You have different alternatives to add those benefits to your product. On the one hand, you can build the add-ons yourself, investing time and resources. On the other hand, you can also spend money directly on acquiring those extra features or buying companies. Examples of this strategy include the acquisition of Apiary by Oracle, and the recent acquisition of Runscope by CA.
Another way to augment a product without investing so much up front is by partnering with other companies that might also be looking to enhance their products with some of the features yours has.
While partnerships are not as expensive as acquisitions and not as resource-intensive as in-house development, they are often heavy on legal activities and require a full alignment of both parties. A possible alternative to that is to enable soft partnerships by integrating your API with other products.
Integrated Product #
Integrating your API with third-parties is what I believe is the best way to augment your product without getting into high spending required by the activities mentioned before.
The integrated product is your product augmented by connecting your API with third-party products. — Bruno Pedro
By offering an API layer and letting third parties integrate with it, you’re able to provide all the extra features that your audience wants. On top of that, different companies will be able to build their custom integrations, offering precisely what various segments of the market are searching.
But make no mistake. Each of the integrations built on top of your API might also be a source of spending. You’ll have to support your API and make sure that it keeps running smoothly over time. How do you measure each integration so you can understand which third-party application is helping your revenue grow or, on the other hand, dragging your company down?
What to measure #
At first glance you can instrument your API so you’ll be able to measure generic usage-related metrics:
- The number of API calls grouped by path, method, and response code.
- Total percentage of errors over time.
- Error breakdown grouped by path, method, and type of error.
But, from a business growth perspective, there are more exciting metrics to explore. Understanding which API consumers are using your API the most, for instance, can give you clues on how you can potentially create a revenue stream.
- The number of API calls grouped by API consumer ID.
- For each API consumer, number of API calls grouped by path, method, and response code.
- Total percentage of errors over time, grouped by API consumer ID.
- For each API consumer, error breakdown grouped by path, method, and response code.
By adding the “API Consumer” dimension to your instrumentation efforts, you’ll be able to identify usage patterns and associate them with specific groups of consumers. With that information in hand, you could, among other things, define an API pricing strategy aligned with how existing consumers are using your API.
While this strategy might work well for APIs with a relatively small number of consumers, it will be hard to produce good results for APIs where there are thousands or even millions of consumers. This is the case of APIs that are used, for instance, by mobile apps, where each app can have thousands of individual users.
The alternative here is to group the results by a different dimension: API Application. You can quickly obtain this value from the OAuth configuration. In practice, each API consumer belongs to an application that can be identified. So, ideally, things would be grouped by the following dimensions:
- API Application ID
- API Consumer ID
- path
- method
- response code
This hierarchy would let you answer questions such as:
- Which application is making the highest number of API calls?
- Which application is producing the highest error rate?
- How many applications are using the new feature added to the API last week?
- What is the least used path and method? Which applications are still using it?
- Are there specific applications producing a high error rate? If so, those might be good candidates for a proactive support.
- How many different operations (paths and methods) are being used on average, per application? Is the API usage spread across all operations or are there specific operations being used the most? Which ones?
- How should you price the API?
- Is usage spread across all methods and paths or is there a group of operations being used the most?
- Is usage spread across all applications and/or consumers, or are there certain applications that use the API the most?
- How many consumers each application has? Are there applications with a substantially large number of API consumers?
API Analytics options #
The two major categories of API Analytics solutions can be described as API Gateways and Generic Analytics Solutions. On the API Gateways category, several tools offer analytics as an option.
On the second category, you can use products that offer generic instrumentation and analytics features.
- New Relic Insights
- Google Data Studio
Your goal is to understand which API consumers are using your API and how. Moreover, you should also be able to identify if particular consumers are producing a high error rate so you can proactively support them. After you pick your top 5 API consumers you should be able to know if you can generate revenue from their integrations. A secondary goal would be to understand which paths and methods are being used the least and by whom. Those will probably be good candidates for deprecation and knowing who is using them is valuable because you might want to get in touch.
You can also search for specific patterns like when a consumer makes calls to several paths sequentially. That might reveal that you can offer a facade path that groups together several operations in one single call. This would reduce the total number of calls and make consumers’ lives easier.
Summary #
You should now be able to understand the concepts of “Whole Product,” “Augmented Product,” and “Integrated Product.” You should also be able to identify the metrics that make the most sense to your business and how you can measure them. Hopefully, you’ll come up with different metrics and insights so you can, over time, understand how your revenue is related to your API usage.