Caching guide

There is no one-size-fits-all solution when it comes to integrating a website with the Bloomreach Discovery platform. Each website employs a unique caching infrastructure, which may utilize different strategies and providers. This document provides general information to help you make decisions on how to best update any caching infrastructure when integrating a website with the Bloomreach Discovery platform.

Autosuggest

Autosuggest searches (oftentimes called type-ahead searches), as recommended by Bloomreach, are made directly from the end user’s browser directly to the Bloomreach API servers to ensure optimal performance (aka “client-side”). When this approach is used, there are no immediate caching concerns with the Autosuggest API, since each request includes a random request_id parameter value which will prevent responses from being retrieved from either a browser or proxy cache. Bloomreach provides SDKs to ease integrating a website and takes care of the API request to the Bloomreach servers.

Product Search

The impact of caching depends on how the Product Search API is integrated with a website.

Server-side Implementation with Personalization

Bloomreach search results are dynamic and update based on user behavior–it is currently not possible to cache the Product Search API and still deliver a personalized experience to the end user. Certain portions of the response may be cached depending on the site requirements; for example, facets may be periodically cached to prevent repeatedly executing rendering logic.

Server-side Implementation without Personalization

Some caching strategies may be compatible depending on which Merchandising features are used. The following table outlines which Merchandising features may impact a caching strategy.

🚧

• Changes may not be immediately available on the website. If you are planning to use rules that have a specific Audience or Duration, then caching is not possible.

A server-side caching approach is not held to any specific caching implementation; any of the following may be cached:

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

Caching duration is subjective; a general rule is to configure the duration to the maximum amount of time that the business is comfortable possibly showing old data. This ensures that ranking rules, campaigns, and facet rules are promptly reflected on the website to the end user. Bloomreach recommends a maximum cache duration of 24 hours.

If feed updates are processed on a frequent basis (intraday “delta” feed), it is important to reduce the cache duration or remove caching altogether to ensure the accuracy of search results.

Content Search

The impact of caching depends on how the Content Search API is integrated with a website.

Server-side Implementation

As the Content Search API does not provide a personalized experience to the end user today, it is an accepted practice to cache the results of Category API requests. The cache entry expiration duration or time varies depending on whether or not an intraday “delta” feed is being sent. In either case, if using a cache duration, the time should be short enough to ensure that changes reflected in the latest feed file are promptly reflected on the website to the end user.

If using a cache duration, a general rule is to configure the duration to the maximum amount of time that the business is comfortable possibly showing old data.

If using a schedule to purge the cache, such as a “cron” expression, the time(s) should be based on when the data feed files are sent plus the amount of time it takes to process and publish the latest indexed data.

A server-side caching approach is not held to any specific caching implementation; any of the following may be cached:

• the direct API response
• any objects created from deserialization of the API response
• the rendered HTML page fragment created from the object representation of the API response

Categories

Depending on how the Category API is integrated with a website and which Merchandising features are planning to be used, determines if there are any caching impacts.

Server-side Implementation

As the Category API does not provide a personalized experience to the end user today, caching may be possible depending on which Merchandising features are used. The following table outlines which Merchandising features may impact a caching strategy.

🚧

• Changes may not be immediately available on the website. If you are planning to use rules that have a specific Audience or Duration, then caching is not possible.

A server-side caching approach is not held to any specific caching implementation; any of the following may be cached:

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

In addition to the above approaches, in order to reduce overall cache size, it may be sufficient to only cache category pages when no facets have been applied.

Caching duration is subjective; a general rule is to configure the duration to the maximum amount of time that the business is comfortable possibly showing old data. This ensures that ranking rules, campaigns, and facet rules are promptly reflected on the website to the end user. Bloomreach recommends a maximum cache duration of 24 hours.

If feed updates are processed on a frequent basis (intraday “delta” feed), it is important to reduce the cache duration or remove caching altogether to ensure the accuracy of category results.

General Considerations

Tracking Pixel

There are no immediate caching concerns with the tracking pixel as the pixel is implemented using JavaScript on the website. Additionally, each request includes a random rand query parameter value which prevents browser and proxy caching.

1-to-1 Personalization

It is not currently possible to cache any API responses (for example, the Product Search API) while 1-to-1 Personalization is active and still deliver a personalized experience to the end user. When 1-to-1 Personalization is active, search results are dynamic and constantly changing as the user navigates the website, which prevents showing the end user cached data. Certain portions of the responses may be cached depending on the site requirements, for example facets may be periodically cached to prevent repeatedly executing rendering logic.

A/B Testing Feature (Variants)

As noted in the features that support A/B testing (variants) above, variants inherently by design do not support caching. If a variant is entered for Rules (Category ranking rules, Search ranking rules) or Search Redirects on a page where the API response is being cached, then only one of the variants will be cached and displayed to the end user. If only one variant becomes cached, then the other variants that are part of the A/B test are not displayed, and the test becomes ineffective.

For A/B testing to work properly, an API call must be made for each page view - this ensures that each variant is shown proportionately with its configured percentage value.

Single Page Applications

A single-page application (SPA), a website that interacts with the end user by dynamically rewriting the current page using JavaScript rather than loading each new page from the server, in most cases, should eliminate the need for caching Bloomreach API responses. If Bloomreach API requests are being made directly from the end user’s browser instead of website servers, then there are no immediate caching concerns, since each API request includes a random parameter value which will prevent responses from being retrieved from either a browser or proxy cache.

Appendix A: Quick Reference

🚧

• Changes may not be immediately available on the website. If you are planning to use rules that have a specific Audience or Duration, then caching is not possible.