Jump to Content
API Management

KPIs for APIs: 12 Key Metrics for API Programs

January 9, 2018
Michael Leppitsch

This is part three in a series about the importance of setting appropriate key performance indicators (KPIs) for digital programs and the APIs that underpin them. Here, we’ll drill down into specific goals for API programs.

Via our interactions with hundreds of customers, we’ve gathered many effective API program KPIs, along with common pitfalls to look out for. It’s important to remember that the value of a given KPI is highly contextual. All of the following KPIs can be valuable, or they can be deceiving.

Successful programs typically define KPIs that align closely with the business, including goals upstream and downstream on the digital value chain. They also may include culture elements that help drive success.

Number of APIs

Often used to drive short-term productivity, this target may often ignore the fact that APIs must also have easy-to-use utility. Simply pumping out a plethora of unusable APIs without relevance to apps will likely cause confusion and encourage rejection of the program. Use this metric in a very tactical manner, once good governance for quality and value is in place.

Number of developers

This target is commonly intended to improve adoption—but APIs must have utility. A singular focus on marketing and onboarding without valuable APIs threatens the program’s momentum and undermines its value for developers. Use this target in combination with other confirmation that the APIs have real business utility, and distinguish between overall developer adoption and adoption among specific developers who use APIs in a known business context, like integrating the applications of existing ecosystem partners.

Number of customers

Customers don’t experience APIs directly—they only experience the apps that use the APIs. This target is important, but use it together with good API instrumentation and app analytics, a set of core APIs related to identity, and careful systemic alignment with the app teams as well as partners and channels that use the APIs.

Number of partners

Use this target to reach out to partners, drive adoption, and demonstrate success to existing business units. In addition to confirming business value, offer hackathons and similar events to kickstart interest in your API program and drive adoption among partner developers and system architects.

Number of apps

While this target may be useful to drive reach, if used in isolation, it can ignore the notion that APIs must be relevant to the business. Use this target by segmenting the apps (websites, etc.) of partners and/or internal teams. If the program creates lots of apps that are only used internally and not by customers, it can sometimes feed internal criticism and abandonment of the program. However, don’t substitute this target with “number of app downloads,” which is a particularly poor indicator of adoption or usage.

Speed to API

In order to enable app teams to rapidly create new customer experiences, API teams should become adept at quickly turning around needed APIs. When this target also segments for APIs that are requested by the business, it becomes a useful measure of time-to-market for needed functionality, regardless of complexity.

Speed to onboard

The portal by which front-end developers obtain access to your APIs should feature an automated approval process, including self-service onboarding capabilities that let developers register their apps, obtain keys, access dashboards, and discover APIs.

This initial automated signup should give access to low-risk APIs and sandbox environments that enable developers to be productive right away. Once developers are onboard, the portal can provide upgrade options in which the developer requests access to more sensitive data and business functions.

These upgrades often require increased diligence and background checks, some of which may take some to time to clear. To distinguish between these processes, be sure to measure the “speed to onboard” for the initial sign-up duration separately from the “speed to upgrade.”

Traffic growth 

This target helps API programs develop a strong DevOps and RunOps culture by continuously monitoring, improving, and driving value through APIs. Be sure to couple this target with related metrics up and down the value chain, including backend reliability and scalability.

Business breadth

This target enables the API program to build relevance across the business, and to drive reuse of the APIs and thus the back-end assets they connect to. Sometimes, API teams encounter resistance from redundant systems, legacy integration, and other elements that are already in use in other business units.

This target helps the team escalate these encounters to the proper executive level for resolution. Particularly valuable APIs, such as those that provide access to unique data or proprietary functionality, may become a source of revenue, packaged as products for developers.

Cost reduction

It can be hard to initially measure cost reduction from APIs. Sometimes this foments dissent among managers. But significant cost reductions are usually realized from the rise in API reuse. When APIs are part of a broader internal refactoring of value chains, use this target together with related metrics such as increased use of backends and increased visibility of usage.

The effect is even more pronounced when IT capital investment shifts to a small set of highly capable, commercial-off-the-shelf (COTS) platforms. Instead of taking time and money to build open-source platforms, the enterprise teams can focus on creating new business value on top of these platforms at much lower cost and faster time to market.

Direct revenue

Just like any other “channel,” use this target by capturing the revenue for the sales of core products that are enabled by APIs. With some exceptions (APIs that involve high bandwidth overhead or APIs that give developers access to a particularly valuable resource), be cautious about collecting an up-charge specifically for the use of the API, as it discourages the use of APIs as highly effective channels for your products that open new markets and reach new customers. (As an exception, there are a few businesses that are purely API businesses, with a subset of APIs that can be directly monetized: information feeds, brokerage services, and purchase or payment transactions, for example.)

Net Promoter Score (NPS)

Use this or a similar target to gauge the app developers who are adopting and calling APIs from within their apps. In addition, though APIs are critical to the creation of apps that improve front-end customer NPS, APIs can’t move this metric by themselves.

The entire digital value chain should be coordinated (backend, APIs, apps) and credit shared for all improvements to front-end customer NPS. For its part, the API program impacts this target with rapid construction and upgrades of high-quality APIs. (As an exception, there are partner scenarios where the “customers” of an enterprise are almost exclusively developers, in which case APIs can directly result in NPS improvements).

Coming up next, we’ll discuss how digital KPIs change over the lifetime of API programs, and provide a tool to assess the quality of your digital KPIs.

Michael Leppitsch works on transformation strategies for global enterprises at Google Cloud.

Posted in