Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
Software development is fraught with risk that can run projects aground like a ship against a rocky beach. Whether it is misunderstood requirements, rapidly evolving marketplaces or old-fashioned bugs and schedule slippage, all can derail otherwise well-resourced and managed software development projects.
Even when software development teams eventually ship their product and collect payment from their customers, there is no guarantee that the product will be used. A 2022 study found that among those paying for SaaS software, 29% of their software is either underutilized or wasted. This study also noted that only 33% of IT professionals track SaaS software usage. The takeaway here is stark: As an industry, most of our labor is not going to productive ends.
This is not a new trend in software; 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 an analytics solution in place. By contrast, however, API applications 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 revealed that even among its customers (that is, those who were already paying for a service that included API analytics), only 26% made use of the analytics functionality. This gives credence to the belief that most features go unused.
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 can be quite valuable in helping API application owners make better decisions about application development and maintenance.
API application owners should look to the following three ways to 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 with products that your customers aren’t buying. The same goes for stocking your API product catalog with endpoints that your customer isn’t using.
API analytics allow API product owners to measure the use of features and evaluate their effectiveness. Product owners can use this valuable information to prioritize extending popular features or developing new features, with a clear yardstick for measuring usage. Further, this data enables development teams to “maximize the amount of work not done,” by shipping preliminary feature sets and evaluating usage metrics before a full implementation. Likewise, if the real-world feedback is not encouraging, it allows you to pivot to another opportunity within the product.
Deprecate or Sunset Unused Application Features
Unused code and features are a liability to an API product organization and can carry bugs, create performance problems and introduce security risks. I’ve seen situations as a software developer where these older features were written by developers who have long since left the organization. These unused sections often harbor serious security flaws and vulnerabilities (such as software dependencies that go unpatched for years) and dubious authorization logic that no one at the company fully understands.
Unused, extraneous features also contribute to a bloated product that can distract end users 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. Removing old, unused parts of your application also frees developers to focus on the parts that users love.
Prioritize Performance Improvements
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 versus totally-necessary-and-prudent optimization often comes down to a subjective argument among engineers or worse, a risk-averse software development culture that contributes to slow time-to-market.
Having an objective measure of performance impact, like the number of instances in which clients are impacted by suboptimal performance, can help application owners decide how to allocate their budget to improving performance versus developing new features or fixing bugs. Moreover, having this feedback loop in place can empower development teams to take a nimble “go fast, release often and evaluate” approach to development. Rather than optimizing performance up front out of fear that invisible problems will lead to bad performance and dissatisfied users, performance can be tracked and reviewed over time.
Selecting API Analytics Solutions
API product owners operating a single application have a 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, I recommend an API protection vendor with strong API analytics capabilities that not only protects against threats but also gives you the visibility you need to prioritize efforts.
API analytics should be a tool that powers innovation. Don’t leave it unused in your toolbox.
