Metering can be a scary topic. Nobody likes to think they have to pay for usage – we want an unending supply. Take TWC for example; plans to launch consumption based billing were thwarted to the delight of many of its subscribers (including me).
The whole process seemed to be a little reactionary as TWC fights to maintain (arbitrary) video and data product distinction. They don’t want videos of shows to be streamed over the Internet. Even if that wasn’t accurate, that was the perception. Metering, in and of itself was not the culprit. As Will Richmond points out in his blog, it was with lack of trust that the public reacted. What lessons can we apply to the API world?
- Bake your business model into your API. There should be no free rides from the outset. This is the position that Dave McClure has educated many API’s channel managers on. If you give something away, it is very difficult to levy a fee to it later.
- Think about API tiers as you do product tiers. Perhaps for one market, it makes sense to give some functionality for free and charge for additional depth of information. Take a look at Hoovers API (HAPI) description, they offer the full breadth of records, but “throttle” the depth.
- Think about your partners clients needs. In a recent meeting with a CEO of a social media company, I learned the entire product was run on Amazon’s EC2. I asked, “what if you have a spike – how does that affect your OPEX?” He said that they plan on spikes from time to time but the overall cost is so low, it is okay. Your API should be flexible enough for cloud computing – adding more capacity on demand can be a feature that you market.
Be clear and transparent in your API. Metering can be acceptable if you provide a clear framework that aligns to your business model. Reporting of the usage (to the client) is the next step.
Image courtesy of B Tal used under Creative Commons
Recent Comments