Use multiple PR strategies
Use multiple PR strategies
This is for:Developer
Associating Coveo Machine Learning (Coveo ML) Product Recommendations (PR) with a query pipeline differs from other model types. The main distinction is that PR models need to be associated with a separate query pipeline dedicated specifically to the PR model.
This configuration is necessary because Coveo-powered product recommendations are displayed in their own component, which is treated as a distinct search interface. Each search interface requires its own query pipeline to handle the queries originating from that interface. This is why Coveo ML PR models require their own query pipeline. Refer to the query routing article for information on connecting a search interface to a query pipeline.
Associating multiple PR strategies with a query pipeline
Coveo ML PR models provide various strategies to accommodate different recommendation use cases. For instance, you may want different products to be recommended on a Product detail page (PDP) compared to the home page.
Hence, it’s likely that you’ll require several Coveo ML PR configurations to offer personalized recommendations depending on the particular display location on your website. Choosing a product recommendation strategy is done when you associate your model with the query pipeline.
To achieve this, you can associate the same PR model with a single query pipeline multiple times, with each association representing a specific strategy. For example, if you want to use the following strategies:
The Cart recommender strategy on the cart page.
The Frequently bought together strategy on PDPs.
The Popular items strategy on the home page.
Create a single Coveo ML PR model.
Create a single query pipeline dedicated to recommendations.
Make three associations within that query pipeline, each representing one of the strategies you want to use.
Based on this example, the query pipeline dedicated to recommendations would look like the following:
Query pipeline conditions
Queries originating from a recommendation component also have to use condition-based routing to be directed from an interface to a query pipeline.
You can make use of the information sent in the
recommendation query parameter to route queries from your recommendation components to the dedicated recommendation query pipeline and trigger the appropriate configuration.
Since all recommendation configurations reside within the same query pipeline, you can use the
is populated operator to build the condition at the query pipeline level.
This condition would be
Recommendation is populated.
As a result, any query containing information in the
recommendation query parameter will be routed to the query pipeline specifically designed for handling recommendations.
Model association conditions
Now that recommendation queries are properly routed to the dedicated query pipeline for product recommendations, you must ensure that the correct model association is triggered based on the recommendation use case. In the previous example with three associations representing different strategies, you want the appropriate strategy to be applied depending on whether the query originates from the cart page, a product detail page (PDP), or the home page. Consequently, you need to define conditions at the rule level to handle these scenarios.
Using the example of the pages given above, we have three distinct strategies for three pages (Home page, product display page, and the cart page), each with a corresponding model association.
Next, we’ll establish conditions for each model association to make sure the relevant model is targeted based on the specific page in use.
To do this, we will make use of the information sent in the
recommendation query parameter for the queries originating from the different recommendation component:
Recommendation is cart
Recommendation is frequentBought
Recommendation is popularViewed
When using the pre-built
ProductRecommendation controllers, queries generated by these components are automatically sent with a value assigned to the
recommendation query parameter.
This value corresponds to the name of the
ProductRecommendation controller you chose to build your component.
A drawback of using this method is that the value given to the recommendation query parameter is fixed and can’t be altered, making it challenging to adjust the strategy behind the recommendations for that component.
On the other hand, the generic
RecommendationList controller allows you to specify the value you want to send in the
recommendation query parameter, by specifying an
id in the component’s options.
This provides greater flexibility as you can choose a name that reflects the purpose of the component. For example, if you build a recommendation component for the home page, you could name it home-page-recommendations, and this name would still be relevant if you ever decide to change the strategy that powers the recommendations on that component (for example, changing from the Popular items (viewed) to the Popular items (bought) strategy).