API Value Creation, Not Monetization
On a daily basis I get questions about API monetization models. I planned on writing a blog post on the topic and in the process began trying to model monetization to verticals which led me to think about why people have so many questions about API monetization. There are two reasons: The API is a distribution channel, and when you think new distribution channel there is an expectation around revenue opportunities. And, if you are the person in your company trying to define the business case for an API to the executive team, there is a hurdle to overcome. Business executives tend to see an API as a cost center and want to know how to measure the pay-off.
The big mistake is that because the API is a whole new thing, companies expect something different than their current business. In reality companies need to start by looking at similarities to their existing business. The question that companies should be asking is “What is the value created by launching an API?”
What does that mean? It goes beyond tying your business model to your API; it is about tying your business goals to your API.
I had a chance to speak with Daniel Jacobson at NPR and he provided a great framework for the first example – NPR focused on three primary business opportunities when making the decision to launch an API. The first opportunity for NPR was the good will with the community, which would be generated by a public, open API. As a non-profit member-based organization, they could gain tremendous clout by offering open access to content.
The second was simplification of content syndication to member stations that pay dues to get access to the content for their local stations. With 800 member organizations and varying access levels syndication became complex. The API gave a standardized and simplified model for delivering content. This gave the less technically sophisticated member organizations a chance to move closer to a Web 2.0 model and many are re-writing their websites with APIs.
The team at NPR was also working on a website redesign and wanted greater flexibility in content production and deployment cycles. The API would allow them that flexibility for updates to the site.
As an unplanned upside, an unexpected business opportunity came out of the public API. Daniel said that in the past companies had approached NPR to become a service provider for content. With limited customization resources, only a handful of partnerships could be implemented. Their selection of these partners was based on the amount of custom work that needed to be done, as well as the total dollar value of the relationship. The API not only drove increased interest, but also gave them a standard way to make content available to non-member third parties on a contractual basis.
Retailer Best Buy has a similar story. Kevin Matheny, the e-Business Architect and API guy at Best Buy shared the three classes of anticipated benefits their team identified. The first was the opportunity for increased reach through affiliates; the goal was to increase “sourced” traffic by 1 % – a reasonable and achievable goal. The second was innovation on the BestBuy.com site (similar to NPR). There were things they wanted to do on the site, such as A/B testing for various functionality they thought might help drive increased purchasing on their site. The API gave them a quick and easy mechanism to try things without spending tens of thousand of dollars on site redesign efforts.
New partnerships were identified as part of the plan for Best Buy. The partnerships they were targeting included incentive programs, corporate customers, and other large volume partners. It wasn’t about thousands of new partners, but those of higher value.
On the side of the unexpected but interesting outcomes, Kevin said they have seen a flurry of internally developed business applications. In the past many valuable, internal-facing projects were turned down because the programs had to meet strict top line to bottom line ratios. With the availability to data and services, many teams within the company now have access to things they didn’t in the past, and project costs have been minimized. Throughout the company, consumers of the API have been able to launch successful projects that have created additional revenue and have reduced the overall development costs for new projects.
These are just a few examples of what I mean about value creation, as opposed to monetization. Yes, in both cases new opportunities to monetize came about – but they weren’t planned. It wasn’t about deploying content and charging on a per API call basis – all of the models tied back to their core business.
A few months ago, Tom Tague who heads up the Thomson Reuters Calais team shared some insights about their success. Calais launched an open public API for their semantic toolkit to drive interest and adoption of their enterprise products, and ended up with people wanting commercial access. The commercial access came with requests for support and an SLA, which in turn created an unexpected opportunity for monetization. At the same time, they met their original goal to quickly and efficiently increase the pipeline for their enterprise product.
The next time someone asks you what monetization models are available, ask him or her a question back – What is the value that can be created by launching your API?