Why is it that the most common questions people have about providing open APIs are often about monetization? While there are many possible answers, two reasons that stand out are: a) the API is a distribution channel, and when you think new distribution channel there is an expectation around revenue opportunities; and b) if you are the person in your company trying to define the business case for an API to the executive team, there is a big hurdle to overcome, because 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.
As a first example, Daniel Jacobson and his team at NPR offer a great framework to consider. 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 NPR 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 for their API. Kevin Matheny, the e-Business Architect and API guy at Best Buy has outlined 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 (the Best Buy API profile).
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 using API for 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?
Laura Merling is a technology strategist and consultant who helps companies leverage open APIs to build ecosystems. She is currently working with companies in media, retail, and telecom on their API strategy. You can read more on her blog and follow her on Twitter here.