Recommendations FAQs

This is done by specifying products or attributes of products that should never be shown in recommendations, for example, if product has color : pink never recommend.

This is done by specifying which types of products should be recommended against which others. For example, for Chanel products, only recommend other Chanel products or against dresses, only recommend accessories.

This limits the recommendations from the specified product attribute to other products without that product attribute, for example, if a product has discounted: true do not show other discounted products.

This limits the recommendations from the specified product attribute to other products with the same product attribute, for example, if product has size: small only recommend products with which also have size:small.

Server-side promotion of products through recommendations is supported in the Recommendations Engine. Here, it’s possible to select a level of promotion and a set of products to promote.

Based on the chosen level of promotion, the promoted products will then permeate more through recommendations, increasing their visibility and sales. The promotional feature is smart and exploits existing links between products to show promoted products on the site. The effect is that promoted products fit well in the recommendations and on the page they’re shown, unlike hard-coded static rules that are used to promote products on all pages.

Additional rules can be developed based on free shipping thresholds, the up-to-the-minute contents of the user’s basket, and any other API-based information that our Data Store can ingest.

If you would like to create any further bespoke rules for Recommendations, contact Coveo Support.

For each of your Recommendations experiences, we report the key metrics that will enable you to understand the value that the experience is driving for your business, not only in narrow terms of revenue and conversions, but also in the wider context of engagement.

Engagement metrics help you understand the effectiveness of recommendations in encouraging your users to create a shopping cart, complete their order, and discover more products in your inventory.

See Reporting On Recommendations Experiences for further details.

As with all of Qubit’s experiences, you can configure goals to define how you’ll evaluate whether your experiment has been successful. For Recommendations, we recommend you include the event action qubit.recommendationItemClick, Conversion Rate, and Revenue Per Converter.

For a discussion around how to determine whether an experiment has been successful and the importance of goals, see How are my experiences performing?

Collaborative filtering uses users’ historical preferences to make predictions and is based on the core assumption that users that have agreed in the past tend to also agree in the future. Basically, the idea is to find the most similar users to your target user (nearest neighbors) and weight their ratings of an item as the prediction of the rating of this item for the target user.

On a very simple level, collaborative filtering attempts to apply a score based on the observed patterns of user behavior and activities—​we can refer to these as product affinities.* Where data is sparse, and by that we mean there are gaps in product affinities, and this is typically the case for most websites, it fills in the "gaps" using patterns observed amongst other customers with similar product affinities:

Finally, it makes predictions about what the score might be and bases the recommendations on that score. In practical terms, this means we can recommend to a visitor that browsed shoes, products that other visitors who also browsed shoes, viewed. This is the basis for product affinity.

Unlike collaborative filtering, which targets customers with recommendations derived from similar users’ product affinities, log likelihood ratio measures how two products are likely to be related by views, purchases, or both. Applied to recommender systems, it answers the question to what extent does the view/purchase of a product indicate the likelihood of viewing/purchasing a different product?

Let’s look at an example. By analyzing product views, we’ve calculated the likelihood of products being viewed together:

A visitor comes to your website, Visitor A, and clicks the link to view Product B. By observing the views in our example above, we see that Product B appears in two rows, Product A and Product C and we can now make our recommendation of Product A, based on a likelihood ratio of 12.31 and Product C, 6.11. In practical terms, the likelihood of Product A and B being viewed together is 12.31, etc.

Taken a step further, Visitor A now views Product G. We now know 2 products that Visitor A has viewed. So, given that the visitor has viewed Product B and G, what should we recommend?

By merging the scores for Product A and G, we arrive at the following results:

And make a recommendation of Product C and Product A. Why is C recommended first over A? Simply because of the observation that C is indicated by multiple items that the visitor has interacted with.

As the visitor interacts (views/purchases) with different products, we build up a history consisting of those interactions and gain knowledge about the intent. We utilize this knowledge to serve recommendations.