Anatomy of a Retail API Program

Published Originally on

API programs have become commonplace at nearly all big retailers who offer multi-channel experiences to their customers through mobile apps, in-store kiosks, the Web, and personalized in-store services. Analyzing the anatomy of a typical retail API program uncovers some interesting patterns. The data here was gathered by analyzing several retail API programs that use the Apigee platform.

The No. 1 motivation for a retail API program

Providing a differentiated value proposition in the physical retail channel is almost always the largest motivation for retailers. The most popular functionalities in retailer apps are those that complement the end user’s experience in the physical retail channel.

The top functionalities were  “enabling mobile consumption” and “driving foot traffic,” followed by “personalization,” “product information,” and “driving customer engagement.”

Trends in retail API programs

Retailers are using their API programs to personalize user experiences and enhance customer service. A majority, for example, use their API programs to employ recommendation features. We also found that:

  • 40% of retail API programs had personalized alerts and notifications
  • 55% included recommendation features
  • 30% offered shopping cart management features

Retail API programs also tend to exhibit high agility, an expansive breadth of API services, and heavy policy use.

Primary retail services exposed as APIs

Certain services exposed as retail APIs rise head-and-shoulders above the rest in popularity.  The most common retail services exposed in retail API programs are:

  • Store locator services, which enable users to discover physical store locations using their current address

  • Product catalogs, which enable users to search, discover, and learn about products and services

  • Order services, which enable users to place and check the status of orders

“Identity”—the set of APIs that enable users to sign up, log in, or access account details—also ranked high, but we do not view it as a primary retail service that is core to this vertical.

Retail API programs: developers, apps, APIs, and policies

Our research also unearthed some interesting statistics about retail API programs: they tend to have large developer teams, a broad app portfolio with a diverse set of apps, and heavy usage of policies across a fairly significant array of APIs. Here are some average values for retail API programs, across a variety of categories (The most successful API programs posted much higher values in these areas):

  • Average number of developers: 154

  • Average number of apps: 87

  • Average number of policies: 378

  • Average number of APIs: 19

  • Average number of policies per API: 16.8

App and API development

Another characteristic of successful retail API programs is the rapid development and improvement of retail APIs. Agility is defined as the number of API revisions divided by the API age in months, and it’s a key indicator of success in retail API programs. We found the average agility among the customers in our sample set to be 13.6, with a maximum of 36 and minimum of 2.

Focus on end user experience

Top retail API programs offer a much faster experience to app users. These retailers spend considerable effort on optimizing their backends and proxies using caches and other features. We found fastest average backend response time to be 20 milliseconds, with 563 milliseconds being the slowest. The average backend responsiveness in our sample was 224 milliseconds; this average is 209 million seconds at the top retail API programs.

What’s your API’s Cachiness Factor?

Published Originally on Apigee

“Cachiness factor” is the degree to which your API design supports the caching of responses. Low cachiness means that a relatively higher than optimal number of requests is forwarded to the back end for retrieving data; a high cachiness factor means that the number of requests serviced through the cache layer is reduced and optimized.

Every time a request is sent to the API provider endpoint, the provider incurs the cost of servicing the request. Investing in a good caching mechanism reduces the number of requests that hit the endpoint, leading to a faster response time, lower servicing costs and saved bandwidth. Resources can then be spent on servicing requests that otherwise would have had to compete with cacheable requests.

Cachiness in an API design refers to understanding how a piece of retrieved data can be reused to serve other API requests. Such an understanding can be transformed into a set of actions that store the retrieved copy of the data in an optimal form for reuse.This coupled with insights from API usage analytics can provide direct benefits in terms of app performance and operational costs.

An API proxy can be designed to do a number of things when a request arrives:

Determine the quality or fidelity of the data requested by the app or end user

This information can then be used to
– Transform the API request to retrieve the data from the endpoint data store at the highest possible fidelity and breadth
– Save the retrieved data in the proxy cache
– Extract the appropriate fidelity and breadth (determined by the original request) and send as the response to the app/end user

For example, if the request is for weather patterns for a city, the system can potentially map the response to a response for all zipcodes in that city and store it accordingly in the cache.

Pre-fetch based on temporal and spatial locality
Predict based on usage patterns what the next request is likely to be and pre-fetch this data from the endpoint for storing in the cache.

For example, given a request for browsing a list of plasma TVs on sale at a retailer, it might make sense to cache the entire response set and serve subsequent requests for more data (e.g. the next set of TVs) from the cache.

Pre-fetch based on similarity
Use the idea of similarity in data sets to predict the next request and retrieve the data for storing at the proxy cache.

For example, for the scenario in which our user requests a list of TVs from one manufacturer, it might make sense to pre-fetch a list of TVs from another manufacturer with a similar product line and store this information in the cache.

Parameters-based selection
If your API supports “select” on your data through parameters, another option to optimize the cachiness of your API is to retrieve the entire data set (within certain bounds) from the backend, store it in your cache, and return only the appropriate data set for the request. Similarly, filtering of data can be performed at the proxy as opposed to the end point, increasing the cachiness factor for the API.

Using Data Analysis to improve cachiness

You can also use data analysis techniques to understand request patterns for your data and use this information to pre-fetch or over-fetch data from the endpoint to increase the cachiness factor of your API.

Caching Diffs
Another possible technique is building a mechanism where updated data is automatically sent from the end point data store to the cache as new updates are generated in the backend. At the cache level, instead of expiring the entire data set, the part of the data set that is least likely to be relevant is automatically expired and the new updated “diff” is appended to the cache data set.

The technique that will work for an API will vary from API to API. You might need to experiment with various techniques to identify the one that makes sense for your scenario and API.