LAST UPDATED Aug 01, 2022
Software development is fraught with risk — misunderstood requirements, rapidly evolving marketplaces, and good old-fashioned bugs and schedule slippage can all derail otherwise well-resourced and well-managed software development projects, running them aground on the rocky beaches of reality.
Even when software development teams do eventually ship their product and collect payment from their customers, there is no guarantee that the product will actually be used. A 2015 study shows that a full 37% of software purchased is never used (source: https://www.1e.com/news-insights/press-releases/over-a-third-of-all-software-purchased-goes-unused-reveals-new-research-from-1e/). Further, according to another study released in 2019, only 20% of features drive the vast majority of product interaction (source: https://www.pendo.io/resources/the-2019-feature-adoption-report/). The takeaway here is stark: as an industry, most of our labor is not going to productive ends.
Of course, this is not a new trend in software, and an entire ecosystem of tooling exists to help software development companies collect user engagement metrics to drive development decisions. In fact, out of the top 10 million websites in the world, nearly two-thirds have some sort of analytics solution in place (source: https://w3techs.com/technologies/overview/traffic_analysis). By contrast, however, API applications as an industry segment lag far behind in adoption of this practice. It is difficult to get market penetration data for API analytics, but a report from API management vendor Apigee reveals that even among Apigee’s customers (that is, those who are already paying for a service that includes API analytics in its feature set), only 26% make use of the analytics functionality (ironically bolstering the point above, that most features go unused; source: https://cloud.google.com/blog/products/api-management/api-monitoring-and-analytics-for-2021).
The takeaway here is stark: as an industry, most of our labor is not going to productive ends.
Bottom line: API application owners who are not integrating real-world analytics usage data into their decision-making process are leaving time and money on the table. Despite not having immediate access to user behavior, API analytics data can be quite valuable in helping API application owners make better business and technical decisions about application development and maintenance. Let’s take a look at three distinct ways API analytics can help API application owners make better product development decisions.
Prioritize feature development in the most actively used areas of the application
One of the best lessons I learned from working at a bike shop is “stock what sells.” In other words, there’s no point in filling your shelves (or API product catalog) with products (or endpoints) that your customers aren’t buying/using. By contrast, a savvy businessperson will pay close attention to what sells best and invest in stocking products that align to demonstrated demand.
API analytics allow API product owners to measure usage of developed features to evaluate the effectiveness of those features at driving usage or other key performance indicators such as number of unique clients. Product owners can then use this valuable business information to prioritize extending popular features or developing new, related features, with a clear yardstick for evaluating how effective that development effort is in driving usage. Collecting these metrics consistently and measuring product development goals using these metrics allows software development teams to “maximize the amount of work not done,” by shipping preliminary feature sets and evaluating usage metrics before committing to a “full” implementation (or, if the real-world feedback is not encouraging, by pivoting to another business opportunity within the product).
Deprecate/sunset unused application features
Unused code and features are a liability to an API product organization.
These unused sections of the application are often older and can carry technical debt, bugs, performance problems, and even security risks. Speaking as a software developer, I’ve seen situations where these older features are written by developers and product managers who have long since left the organization, leaving behind ancient artifact functionality that not even the product development organization understands. In a great twist of irony, these under-used sections of the product often harbor the most serious security flaws and vulnerabilities, such as software dependencies that go un-patched for years and dubious authorization logic that no one at the company fully understands.
Unused, extraneous features also contribute to a bloated product, which ultimately confuses and distracts your userbase from the core value of your API. It can be difficult to advocate for the removal of “working product features,” but API analytics data can help make a strong case that certain features are nothing but an expensive distraction for the development team and your user base. Remove these old, unused parts of your application to better focus on the parts of your application that users love.
In a great twist of irony, these under-used sections of the product often harbor the most serious security flaws and vulnerabilities, such as software dependencies that go un-patched for years and dubious authorization logic that no one at the company fully understands.
Prioritize performance improvements where needed
Performance is often a fine balance between implementation time/costs and product requirements.
It’s a well-understood maxim in software development that “premature optimization is the root of all evil.” Yet in the absence of real-world performance data, determining what represents “premature” optimization vs. “totally-necessary-and-prudent” optimization often comes down to subjective argument among engineers, or worse, a generally fearful and risk-adverse software development culture across the organization that directly contributes to long development times and slow time to market.
Having an objective measure of performance impact, i.e., the number of instances in which clients are impacted by suboptimal performance, and the severity of those instances, can help application owners decide how best to allocate their development budget to improving performance vs. developing new features, fixing bugs, etc. Moreover, having this feedback loop in place can help development teams default toward a nimble “go fast, release often, and evaluate” approach to development. Rather than optimizing performance up front out of fear that problems will be invisible and lead to bad performance and dissatisfied users, performance can be tracked for API endpoints and reviewed over time in the context of which endpoints are seeing most active use, and how badly they are impacted by performance issues.
Selecting API analytics solutions
API product owners operating a single application have a wide variety of choices when it comes to deciding which analytics tool to use for their product. Many specialized solutions exist for individual API development languages and frameworks. However, security teams have a unique problem: they need all the data, across all applications, and across all the tech platforms within the organization. In that case, an API protection vendor with strong API analytics capabilities not only protects against threats, but also gives you the visibility you need to prioritize efforts.
For more best practices on API development, see my recent blog post, How to Simplify Your API to Narrow Attack Vectors.
