Enterprises are drawing on the tools of the digital trade -- APIs, data, and apps -- in what is amounting to a gold rush in the new digital world. A treasure map of how these tools can be used to transform digital assets into revenue streams is critical to navigating this uncharted world and discovering gold. In our Digital Gold Rush blog series, we're charting the different business models for monetizing digital products. Last time we discussed the revenue share model in detail where the developer or partner using the API gets paid for incremental business or traffic they generate. This blog entry discusses fee-based models where the developer or partner using the API pays the API provider.
API Monetization Model #2: Fee-based models
Fee-based, or ‘Developer Pays’, models enable enterprise providers to generate an immediate revenue stream by assigning price points to their digital assets. A common scenario under this model is to enable developers to search for (and retrieve) information based on the provider’s knowledge database. At the end of the day, the end game remains the same -- to maximize the value of your digital assets.
Amazon Web Services (AWS) delivers a set of web services (storage, database, computing power, servers, application services, deployment, and management) accessible via APIs, each following some type of fee-based model. By projecting and externalizing a suite of services, Amazon has realized impressive business results: 905 billion objects stored in AWS, $750 million in revenue in 2011, and $1 million in savings for NASA after moving the agency’s IT into AWS.
One of the most popular fee-based models is Google Maps, which charges developers for use based on volume. By paying a variable fee, developers can integrate Maps functionality into their mobile apps.
There are a variety of constructs under fee-based models. These can be combined with the revenue sharing models outlined in our last blog:
- Transaction fees: These types of fees can be by API transactions or some other custom attribute that the API provider designates.
- Transaction volume: The API consumer is charged based on the volume of the API transactions. The rate can be fixed or variable (see below). A typical example would be for messaging or identity APIs.
- Custom attribute: The API consumer is charged based on the quantity of custom attributes within a transaction. The rate can be fixed or variable. A typical example of this would be for search APIs (charge based on the number of words returned in the transaction), or cloud storage (charge based on number of megabytes stored).
- One-time fees: The provider can charge the API consumer an upfront, one-off fee, such as a set-up fee or a joining fee.
- Subscription fees: The provider can also charge the API consumer a recurring fee that is charged on an ongoing basis at a preset frequency. A typical example would be a weekly or monthly subscription fee for access to a group of API products. The volume of access can be controlled using hard limits, or combined with a volume-banded plan to charge for excess usage.
These are factors to consider so that you choose the right type of fee-based model for your business:
- Flat rate card: The API consumer is charged a fixed rate per transaction/custom attribute, irrespective of the volume of transactions.
- Flexible volume banded: The API consumer is charged a variable rate per transaction/custom attribute, depending on the total volume. This model can encourage developers/partners to use higher volumes by charging lower rates as usage increases.
- Configurable bundled: The provider charges the API consumer for each bundle of API transactions up front as soon as they use the first transaction in the bundle.
There are other important considerations when exploring fee-based options:
- Product-specific or generic plan: Often there is also the need to differentiate these models as generic (one rate plan to cover all products in the package) or product-specific, where you have a rate plan for each of the products in the package.
- Group or local company plan: Where an API provider has local subsidiaries, you need the flexibility to set up plans at a group level (the same rate plans and tax models are applied irrespective of the subsidiary) or at a local level (where you can have a different rate plans and tax models depending on the subsidiary).
Digital Monetization and Apigee
Apigee delivers Monetization Services as part of its Digital Business Platform. It is a critical part of Developer Services offered to API providers to partner with their developers. Monetization enables definition and management of the commercial relationship between the API provider and API consumers by setting in place the business model for the digital value chain. Monetization Services offers the flexibility to create customized plans or use out-of-the-box plans that cover all of the fee-based models and options described above.
Check back soon. Next time we'll explore freemium models.