Taking API Monetization To The Next Level By Monetizing The Exhaust Around API Consumption

I have spent a lot of time thinking about API analytics. Understanding who is signing up to access API resources, and how they are putting those API resources to use, is one of the most valuable aspects of modern API management solutions in my opinion. The awareness derived from API operations that use analytics, can have the biggest impact on not just how you run your API, but how you craft your API products, tailor your monetization strategy, evolve your overall roadmap and company.

API analytics was the topic of a webinar I conducted with WSO2, one of my partners, this morning. I've been invested in WSO2 since they first contacted me for feedback on their then upcoming release of their open source API management solution. During this mornings webinar, I gave the basics on "why" API analytics during this mornings webinar, then sat back and listened to Nuwan Dias demonstrate the "how" of it.

First thing that caught my attention was the WSO2 predictive analytics, which is a concept I have to say I have never thought about, but will be pondering more around what this might mean (or not) to the business and politics of API operations. Another thing that caught my attention was an idea Nuwan shared during the QA, about API monetization at the API analytics layer--very interesting thought.

While the conversation is not as far as long as I'd hoped by 2015, the concept of using API analytics to help you craft your API monetization strategy is pretty well established. API providers like 3Scale and WSO2 have been helping API providers understand the value delivered via APIs, while also providing a framework for crafting service tiers, pricing, and manage usage and billing for API consumers--what Nuwan is thinking about, takes this up another level.

A generation 1.0 API monetization scenario might be an art gallery, who could have an API that feeds the gallery web or mobile app, and during the planning of their API they identified that they shouldn't charge for API access, because it just adds value to their overall business objective--get foot traffic in the door. So the more developers building their art gallery content, products, and services into other 3rd party apps and sites, the better. Maybe along the way the gallery might also choose to serve up high resolution, or interactive version of exhibits for a fee, adding another layer to their monetization strategy--this is a classic example of API monetization discussions I've seen in the last 10 years.

A generation 2.0 of this API monetization scenario, reflecting Nuwan's vision, could involve the Art gallery actually selling leads in real-time, to partner galleries, restaurants, and other businesses that their customers might also be interested in. To reference the WSO2 real-time API analytics example, you could craft a definition of what ideal scenario would look like, and when a user logs into the web or mobile app, matches the profile, the exhaust from the API usage could also be accessed via a higher level API crafted off of your API analytics API (head scratcher). Of course you'd want to design some sort of layer that would require users to opt-in so that they are aware that their data was being captured, and shared, but in theory that exhaust from a single users API transactions could provide a whole new API monetization opportunity.

I'm still thinking this through, but gen 1.0 is about identifying the value of the digital resources of the gallery including the physical locations, art inventory, artist details, etc. You try to establish ways of extracting direct, and indirect value from these digital assets, by making them available via an API. Indirect monetization would be about driving web and mobile usage, as well as in-person foot traffic, where direct monetization would be about selling high resolution images, or possibly virtual gallery experiences. A gen 2.0 API monetization conversation in this art gallery scenario would be about identifying specific personae of users and experiences via the web, mobile, or even device and sensor based APIs that could be targeted in real-time, triggering other secondary, API driven event and experiences.

This type of APIs for the meta layer of API operations seems like more of a partner level API composition layer. Meaning as an API provider you'd have access to these APIs, but as far as your community, you'd probably only extend these APIs to trusted partners, who you have an established relationship with. As I try to think through API monetization at this layer, I'm guessing partners would pay a flat fee, or maybe a per transaction fee depending on the amount of data shared, or perhaps based upon successful transaction or sale? IDK, just spitball'n.

This is just me thinking through a single hypothetical scenario to help grasp the potential here. It adds a new dimension to both the API analytics discussion, as well as the API monetization one. Lots to chew on, from the business and politics side of API operations. Would love to hear your thoughts...

Disclosure: Both 3Scale and WSO2 are API Evangelist partners.