.png){kind=small}
.png){kind=small}
One of the actions that we see of great importance, in addition to the use of APIs available for consumption, is to be able to identify the experience and use in their consumption. With that, it is necessary to use several extractions and metrics analysis that can be extracted from this use of APIs.
Below, we will list some metrics and how they will support you in identifying the lag, both in development and in your own API/Backend.
Do you know how to identify which developers/partners are actually using your APIs? Do you know if all your process requests are?
With this information, you can identify, for example, if a key partner has stopped using it and contact them to identify what is happening. In some cases, they just stopped using due to questions related to some action and ended up not trying to resolve this issue.
Having a view of how the APIs are doing is extremely important to avoid overload and unavailability, and to identify how healthy the backend and the use of the APIs are.
Aiming at a healthy environment will establish stable use and without major difficulties for partners.
How much of the APIs is used and how healthy is it? By identifying how your success vs. failure rate is going, you can identify whether your API has provided a good user experience.
In addition, it is worth mentioning that in order to consider a totally healthy API, you must also verify if the successful requests that are being made are not repeated unnecessarily (in this case, the percentage can mask the problem of errors).
Extracting this data and identifying the greatest difficulty of use, such as the operation, the error HTTPStatus and quantity, it is possible to identify whether the developers have any usage knowledge gap and take the necessary measures, such as providing training, optimizing the documentation available on the Developer Portal, promoting a kickoff.
With this input you will be able to accurately identify the partners who have the most difficulty in using, thus contacting them, being able to identify the cause of the problem and implement easier measures with a direct and clear trigger.
Even when we think beyond the APIs view, we can have more information and metrics, such as analysing the registration and usage on the Developer Portal, thus being able to identify the people who are interested in using the APIs, identifying how they are doing, what they are looking for and whether people are actually accessing and browsing the Portal.
In this post, we presented some tools and behavioural analysis that are applicable to the Developer Portal and can help in the identification and usage behaviour of both the documentation as well as user experience and navigability.
These were some tips for extracting metrics in the consumption of APIs that can be very insightful for your IT and business teams. Through them, we can collect useful information for decision making, or even explore opportunities that were not previously mapped.
Do you have any metrics that you think are essential? Comment below in this post!
