Inclusion API Dashboard: Methodology
How Data is Collected and Analyzed
This page describes how each individual metric in the Inclusion API Dashboard was calculated, what it measures, its benefits and limitations and how we can continue to improve the accuracy of each metric.
The Inclusion API Dashboard relies on developer engagement metrics from a number of private and public sources. Calculating levels of engagement for API providers is a relatively new activity, and there are different opinions about how best to calculate data.
The metrics in the Inclusion API Dashboard have been researched by API experts, focus-tested with API stakeholders and business experts, refined, and tested with target end users. We welcome comments and feedback from all Inclusion API Dashboard users.
Main Dashboard Page metrics
APIs by Region
| What this measures | This map shows the countries where open APIs with the potential to improve financial inclusion are being made available, and the number of APIs available in those countries |
| Data source | API provider’s developer portal/website |
| How it is calculated | Each API provider’s developer portal is reviewed and details of where the API functions is tallied. Where no information is given, it is assumed that the country location of the API provider is the country where the API can be used. In some cases, where it has not been specifically mentioned, there are blog posts that describe users of the API being from a particular country, in which case those countries are tallied up in the totals. Each API is listed with what countries it operates in. This is tallied together from the API pages and presented in the map on the home page. |
| Advantages | This map gives an instant visual of which regions in the world are seeing more companies opening APIs. |
| Limitations | Some of the APIs may be available in more regions that are not described in the API documentation. |
| How this metric can be improved | API providers could clearly state in their documentation where the API is operative. API providers who review their data in the Inclusion API Dashboard can contact us to let us know where our data can be improved. |
Total APIs in Sector
| What this measures | An aggregate total of all open APIs made available by Digital Finance Services in Africa, South Asia, East Asia and Latin America, including APIs from other providers that may be relevant to financial inclusion. |
| Data source | API provider’s website/developer portal |
| How it is calculated | Regular internet searches are conducted to identify APIs that can be catalogued. The Inclusion API team reviews some APIs that are not directly related to financial inclusion and makes an assessment of what should be included. APIs are regularly reviewed from email alerts, expert suggestions, and internet research. APIs are entered in the database and the total number of APIs is summed from all entries in the Inclusion API Dashboard and presented. Advantages |
| Advantages | As a new industry opening APIs, there are few examples of API providers opening APIs so it is useful to see what APIs are being made available amongst related industries and where financial services providers are starting to take strategic moves. |
| Limitations | Because of the small number of DFS providers opening APIs, the majority of APIs currently listed in the Inclusion API Dashboard are being made available by adjacent players such as payment aggregators, ecommerce, VoIP and even industries like delivery services. They do not reflect ONLY the Digital Financial Services providers. |
| How this metric can be improved | A taxonomy can be prepared to identify which categories of APIs product should be listed as “relevant to financial inclusion”. We continue to set up alerts and review potential open APIs being made available for financial inclusion in emerging markets. We can write a blog post describing why some decisions were made to include certain APIs and how the could potentially be used to support financial inclusion. |
Companies Offering
| What this measures | Number of API providers and related industries who are opening APIs |
| Data source | API provider’s website/developer portal |
| How it is calculated | Based on the APIs listed in our catalog, we count the number of unique companies making these APIs available. |
| Advantages | This shows an overall reflection of the level of activity in the market opening APIs, as showing only APIs may suggest a lot of activity but companies may release more than one API, so just looking at the number of APIs can create a distorted picture of the level of activity. |
| Limitations | This score reflects all businesses opening APIs that may be relevant to financial inclusion, however, several of these APIs might not actually be being used to build financially inclusive products. |
Top Communication Channels
| What this measures | Which developer resources should be considered “Minimum Viable Product” for any DFS related provider opening up APIs |
| Data source | API provider’s website/developer portal |
| How it is calculated | For each API provider, a full list of their developer communication channels is tallied on their company page. For the top five ranked API provider’s by mindshare, the communication channels they use are listed, showing which communication channels are the most important for the most popular developer portals. |
| Advantages | This ranking of communication channels suggests to new open API providers what a minimum viable set of developer resources should be when attempting to engage developer communities, and helps API provider’s prioritize budget and resources. |
| Limitations | This metric is based on unique visitors data rather than ranking of API providers with the most production apps, integrations and use cases. |
| How this metric can be improved | This data could better reflect which combinations of communication resources were most common amongst the top ranking API providers. If data on commercial apps being built was more transparent, this data could be based on ranking of API provider’s with the biggest number of commercial developers rather than on unique visitor numbers to the API provider’s developer portal. |
Apps built with DFS APIs
| What this measures | Types of apps being most regularly built with Inclusion-related APIs |
| Data source | API provider’s developer portal/website |
| How it is calculated | For each API company, the list of apps mentioned on their developer portal and in their blogs and social media accounts is listed on a spreadsheet describing the use case of the app. These use cases are then summarized into common categories. This metric is the sum aggregate of each category for all apps built with the APIs. |
| Advantages | Shows in broad categories the types of use cases being created using Inclusion-related APIs. Allows for some analysis of which apps being built may have an impact on improving financial inclusion. |
| Limitations | Some apps may not have adequate use case descriptions to allow for categorizing. Each app can only be tallied in one category when it may have more than one use case. The limitations of the estimated number of apps being built with Inclusion-related APIs are relevant to this metric. |
| How this metric can be improved | More details on the apps being built with Inclusion-related APIs and their impact on financial inclusion will help better categorize apps. Blog posts can be written to describe in greater detail the sort of apps that are being created with each company’s APIs and blog posts can describe in greater detail each set of category topics and what third party developers are building. |
Business Models for Financial Inclusion APIs
| What this measures | The potential revenue and future business models being enabled by open APIs |
| Data source | API provider’s developer portal/website |
| How it is calculated | For each API, it is listed whether the API is available free of charge, whether the developer pays for usage (for example, via a transaction fee for each API call made or via a subscription plan), whether the developer gets paid (for example, via affiliate commissions or a revenue-sharing model) or whether there is an indirect business model (for example, developers build for the API provider’s customer base or share some customer data from their integration). This metric is the sum aggregate of each category of business model for all APIs. |
| Advantages | Shows the level of current thinking amongst Inclusion-related providers regarding the potential revenue and business models from their open APIs. |
| Limitations | Many open APIs do not publicly state the business model for their APIs at present. There are nuances within each category, for example, within “developer gets paid”, developers could be sharing in a revenue-split model for selling apps to a DFS provider’s existing customers. The DFDS provider strengthens their current customer relationships by providing a greater range of services while also sharing in revenue from new products sold to customers. This category setting does not fully show these revenue benefits being realized via the business model. |
| How this metric can be improved | API providers could be more transparent about the current business model being used for each of their open APIs, or could share details via our feedback form. Blog posts can be written to describe in greater detail the sort of business models that are being tested with open APIs. |
APIs by Stage
| What this measures | The level of maturity of the open API market amongst Inclusion-related APIs |
| Data source | API provider’s developer portal/website |
| How it is calculated | For each API, it is tallied whether the API is available only to invited applicants/early adopters, whether any developer can sign up for test access, or whether it is available for production use cases. All APIs are then aggregated by these categories and percentages for each category are calculated. |
| Advantages | Shows the current level of maturity of the open API market, as Inclusion related providers may start with limited access and as developers begin testing their APIs, they may move to more general availability. |
| Limitations | Several API providers do not explain whether their APIs are available at the production level. Others appear to be available for production use cases, but the lack of a pricing page or page outlining terms and conditions of usage make it difficult to clarify. |
| How this metric can be improved | API providers could be more transparent about the current availability of their APIs by clearly stating in their API documentation or by providing details via our feedback form. Blog posts can be written to describe in greater detail the maturity evolution of the Inclusion-related open API market. Additional data points showing the length of time that APIs stay in limited availability before moving to open beta and time between open beta and general availability would better reflect the API maturity model expected timelines. |