Recommendations and Pathways APIs - Caching guide

Overview

Recommendations and Pathways widgets can be placed throughout your website to create the desired user experience. Widgets are created and managed directly from the Widget configurator in the Bloomreach Dashboard without making any complex technical API-level changes. Using simple dashboard operations, you can manage widgets end-to-end and use API calls only to override the default configuration if required.

Recommendations are typically dynamic and updated based on user behavior. It isn't possible to cache certain Recommendation widgets, such as Experience-Driven Recommendations, and still deliver a personalized experience to the end user. However, other Recommendations, such as Frequently Viewed/Bought Together and Best Sellers, can be cached because a common item for a group of users generally triggers them.

Pathways widgets can be personalized based on segments, either Relevance by Segment or Real-time Segments. The results will be identical for users within the same segment. These widgets can be cached by widget, query, or segment.

Why should I implement caching?

Caching lets you store commonly requested items (for example, products) in a secondary data store to avoid repetitive calls to the same API for the same data. The impact of caching depends on how Recommendations and Pathways are integrated with a website, but some general benefits of caching API calls include:

• Response time - Retrieving the response from the cache can be faster than making an API call, improving user experience.
• Reduced network traffic - Reducing the amount of data that needs to be sent over the network.
• Reliability - APIs can continue to function even if the source becomes unavailable.
• Cost savings - Reducing the number of API calls made.

Server-side implementation

For Recommendations and Pathways, the page requested may have multiple widgets, and the customer journey may involve a number of pages. This is not optimal for client-side caching because it typically has a size limitation. The benefit of caching is better achieved by storing individual API requests shared among multiple users, which would be accomplished on the server-side.

The server-side caching approach isn't limited to any specific implementation; any of the following may be cached:

• The direct API response
• Any objects created from the deserialization of the API response
• The rendered HTML page fragment(s) created from the object representations of the API response

Caching guidelines

Cache age or duration

The duration is how long something remains in the cache before a new API request is made. Cache duration is subjective; a general rule is to configure the duration to the maximum time you are comfortable with for possibly showing old data. This ensures that ranking rules, campaigns, and facet rules are promptly reflected to the end-user on the website.

If feed updates are processed frequently (typically every 30 minutes), it is important to refresh the cache on the same schedule. So, if you use a schedule such as a cron expression to purge the cache, the time(s) should be based on when the data feed files are sent, plus the time it takes to process and publish the latest indexed data.

For example, if your index publishing job takes five minutes to complete, and you run this command every 30 minutes (such as 13:00, 13:30, and so on), then your cache should be refreshed on a five-minute offset, such as 13:05, 13:35, etc. This will allow you to reduce API call volumes while also benefiting from the most up-to-date information in your search index.

Cache keys

A cache key is the index of the item stored in the cache, which allows the cached information to be retrieved for subsequent requests. After an API request is made, the result is stored in the cache using this key. Depending on your caching strategy, you will likely have a key generator to generate unique keys for each request. Recommendations API calls are made with different query parameters such as the widget ID, category/Item IDs, keywords, and segments to retrieve the product results. The key generator can use these parameters to create a unique key.