Server-Side Implementation

Server-side implementation of Discover requires the integration on Category/Browse listing pages and Search listing pages to provide the desired response.

Category Listing Pages

Discover uses the recsForPlacements API to provide a personalized sorted list of products for category listing pages. See the recsForPlacement API page for all the parameters and examples of the request and response.

There are two different ways to integrate the API into a retailer's category listing page.

Option 1: Direct insertion

This option is only suitable for Retailer's that don't have faceted navigation or have home grown search & browse systems that don't have boosting capabilities.

Similar to option #1, when the customer makes a request to browse a specific category (for example, "Shoes") the Retailer's e-commerce platform will receive the request. If the sort order chosen by the customer is "personalized" or "recommended" (many retailers set this as the default) then the e-commerce platform will make a server-side API request to the Omnichannel Personalization recsForPlacements API. 

The recsForPlacements API will respond with the products to display in JSON format. The e-commerce platform will process these results and generate the HTML to  display the products (name, image, price, ratings, etc.) on the customer's device.

Diagram Description automatically generated

Note: The recsForPlacements API can remove products based on the filters chosen by the customer (See Filter section below for more details).

Option 2: Boosting

Three reasons or conditions where this approach is needed:

  1. Retailers that have faceted navigation on attributes that they can't send to Algonomy via catalog feeds.

  2. If Retailers' inventory is changing rapidly AND their search engine has real time inventory filtering to remove products out of stock.

  3. Retailers that have merchandising rules embedded inside their search engine (Endeca, for example) that they can't move over to Omnichannel Personalization merchandising system.

When the customer makes a request to browse a specific category (for example "Shoes"), the Retailer's e-commerce platform will receive the request. If the sort order chosen by the customer is "personalized" or "recommended" (many retailers set this as the default) then the e-commerce platform will make a server-side API request to the Omnichannel Personalization recsForPlacements API. 

The recsForPlacements API will respond with the products to display in JSON format (see below for an example of a sample response). The e-commerce platform will request the search & browse system to:

  1. Boost those products to the top.

  2. Apply all filters the customer selected.

  3. Generate the facets from that result set.

  4. Generate the HTML to display the products (name, image, price, ratings, etc.) on the customer's device.

Diagram Description automatically generated

Search listing pages

This page describes in detail how to integrate search listing pages

Latency

Since the Retailer’s servers must make a call to the Algonomy cloud to retrieve the personalized products, categories and brands there will be a small increase in latency in generating the search results page back to the customer. The Algonomy average response rate will be approximately 100ms. To protect the customer experience we highly recommend that the retailer enforce a 250ms timeout for the call to the Algonomy cloud.  If Algonomy doesn’t respond within that time period, retailer will kill the open request and execute the search result without any personalization.

Logging

For Algonomy to track performance of the personalized search results it is important the retailer informs Algonomy that customers clicked on products recommended by us. The clickURL in the API response needs to be invoker when the customer clicks on the products. For more details on how to do that please contact your Algonomy Client solutions team.

Reporting

For those familiar with the Recommend product sold by Algonomy, the search API will be built as a Omnichannel Personalization “Strategy”. It will be named “ComplementarySearchSort”. Thus all the reporting currently available in the self-service dashboard for strategies will be used to measure the performance of the personalized search integration.

Caching

Some retailers do not want the ordering of category pages to change for a customer in a session. Some retailers don't want to call the Algonomy API on every single category page request because they themselves have cached their category pages for speed and performance. This is a valid concern. However personalization implies that there needs to be a unique response for each customer. Therefore, a good compromise is to build a session specific cache that caches the category pages for that customer in that session.