Skip to content

Recommendation models

Recommendations that are useful in real-life situations are generated by using scenario strategies that consist of algorithms (models). Models are statistics-based and perform calculations based on information about content, users, and events in which they are involved. Calculations run in the background and the results are updated regularly to provide the most accurate recommendations. Models come predefined with the service, based on the arrangements that you make with Ibexa. You can request a specific model by contacting customer support.

If your user role includes the Personalization/Edit Policy, you can modify the models according to your requirements. To do this, navigate to the Models tab and click the Edit icon next to a name of the model.

You may have permissions to access several websites hosted on an Ibexa DXP, with independent results returned for each of these websites. If this is the case, use the selector field to switch between views for each of these websites.

Model types

There are several types of models available, however, the distinction between types is not visible in the user interface.

Popularity models

Basic popularity recommendations, such as "Top purchased", "Top consumed" or "Top clicked". Models from this category return the most popular content items/products, based on a weighted overall usage history (recent events are more important) and category-based filtering (bestsellers in the selected category and/or subcategories).

Collaborative models

These models are more complex and require combining data from different sources.

Also clicked / purchased

This type of recommendation is often called "Collaborative filtering based on user data" and is a proven, powerful approach to calculating recommendations. It recommends products that are usually clicked or purchased together. It is very simple to configure and needs no maintenance.

Ultimately bought

This model combines CLICK and BUY events. It suggests alternative products, which customers purchased after they clicked the selected product. It therefore provides a "matching factor" of searching and purchasing. In contrast to the "Also purchased" model, it recommends products that are related, but not purchased together. This model is the best choice to suggest alternative products for their search. For example, when a user finds a book and the same book is being recommended on the product page, it means that other users with the same interest purchased this book (and not others), which hints that this book is the best choice.

Frequently bought together / Bundle recommendations

Products that were bought in a combination for a certain number of times can be recommended as a bundle. This model can recommend other products that fit the one that the user is currently looking at.

For example, when a user navigates to a product page with a certain smartphone, apart from the "Also clicked" recommendations, the Personalization service could recommend the Smartphone + Cover + Headphones bundle, because they were purchased together in exactly this combination several times.

It is not guaranteed that there is a bundle available for every product. Therefore, the rendering logic should display the recommendations if they are available, or leave the bundle box out completely. The currently displayed product is always part of the bundle.

Similar rated

The "Similar rated" model provides recommendations based on user preferences. It predicts articles that might suit the user's interests. Recommendations for articles similar to their dislikes are suppressed.

Best rated

This model provides recommendations based on algorithms that include the ranking values and the amount of distinct ratings. It is best suited for landing or category pages.

Editorial and other models


The model returns a semi-random list of products from the last 10 days. It allows injecting new products to the recommendation while the "History-based" models are not yet able to recommend products based on the statistics. It is a simplified and unsophisticated alternative if no other information is available to calculate and provide recommendations.

This model is not based on historical records but relies on the imported product catalog.

Random short

The mechanism of this model is the same as in Random, but the difference is that it returns a semi-random list of products from the last four hours.


This model returns products from a list that you manually create if you have Personalization/Edit Policy. This way you can replace automatically generated recommendations with ones from a predefined list. It is best suited for cases when the store administrator wants to add special offers or sell older stock. It could be referred to as "Static recommendations".


Items from this list are not recommended in any scenario. The model can be configured manually by a user.
You can use this model to exclude test products or products that are used for system monitoring. An element added to this list will never be recommended so it must be treated with care, because the blacklist model applies to all scenarios that exist in the system.


Pseudo recommendation model that shows the user products from their own history. For example, the "You have just watched" box.

Advanced model configuration

Most of the models provide additional configuration parameters, which enable customization.

The parameters supported by different model types are described in the table below. Some models support submodels. Additional differentiation criterion is the supported context. If a model requires context, it can only be linked to scenarios that provide the necessary context.

Model type Available parameters Submodel support Context
Popularity Relevant event history defines the time period for which the statistics must be analyzed. Depending on the type of product, it can be between several months and several hours. Fast event ageing can be used to weight newer events higher than older events. yes
submodels based on category are enabled by default
not needed
Also clicked/purchased / Ultimately bought Both also clicked and ultimately purchased models allow defining the relevant event history. yes, manual required (either context items or user data)
Random This model requires the maximum age for the items that should be recommended by this model. no not supported
History-based The type of the history (CLICK-history or BUY-history) must be specified. no required (user data)
Editor-based The list of recommendations must be created manually by the editor. no not supported
Blacklist The list of items that should be excluded from the recommendations must be created manually by the editor. no not supported

Do not confuse event history age with item age. History age is the age of the user's footprint (for example, "User clicked on the product A two weeks ago"). Item age is the time over which the item is available in the shop ("How new is the item"). The history is recorded automatically based on event tracking. The item catalog must be filled separately as a result of data import.

Trigger model build

Models on the Personalization server side are configured to build at intervals, for example, every 24-hours. For each model which requires computation (all popularity and collaborative models), you can manually trigger build after any modifications to the model's settings in the Back Office.

To do this, in the Personalization section go to Models. Click the edit icon next to the computation model, add necessary changes, and click the Trigger model build button. The model's status changes to Build in progress. After the successful build, status changes to Active.


Model statuses:

  • Active - model is successfully built
  • Not active - new model which hasn’t been triggered or used yet, or model that is added to the scenario, calculated and then removed from the scenario
  • Build in progress - model during the building process
  • Failed - there is no data to build the model or some error occured, building failed


Statistics-based recommendations often have the disadvantage of providing recommendations limited to the most popular, most suitable to the user, or most similar products. You might want to extend the set of available recommendations by defining a subset of items based on external criteria.

Submodels give you the option to group products based on an attribute. Recommendations can then be requested specifically for the selected group. For example:

  • "Also bought clothing with similar colors"
  • "Most popular toys for the predefined age"
  • "Also bought presents with a predefined price"

Submodels must be manually configured. You do this in the property dialog of the recommendation model. After you configure the submodel, the results are generated overnight and are available on the next day.

Nominal attributes

A nominal attribute-based submodel works when the number of values of an attribute is relatively small and there is a large group of products for every value. A good example would be clothes colors in a clothing store, while authors in a book store would make a bad example (there are too many of them).

When configuring submodels for a clothing store, you might want to get recommendations for a specific color, either predefined or a color of the context item. Similar colors can be grouped together, as shown below:

Attribute example

The following results are possible for the products shown in the diagram:

Attribute from the recommendation request Result
color=lime Value "lime" is found in the first group. There are products in this group. If a model has any of them, they are recommended.
color=sand Value "sand" is found in the fourth group. There are no products in the group, therefore nothing will be recommended by this model. The fallback model could be used if configured.
color=white Value "white" cannot be found in any of groups. The main model is used. Items from all submodel groups can appear in the result (as if the submodels were not configured at all).
no attribute specified The main model is used. The request is handled as if submodels were not configured at all. Products from the whole shop could appear in the recommendation list.

Numeric attributes

In numeric attribute-based submodels you define subgroups by setting from and to limits for every group.

The logic used for resolving a submodel is as follows:

  • The from value indicates the beginning of the range and is included in the subgroup.
  • The to value indicates the end of the range end and is excluded from the subgroup. The only exception is the last of the ranges, where the to value is also included.


You can specify a single or multiple attributes with multiple values for requesting recommendations. Recommendation are fetched from all the submodels and merged based on the weight (relevance). If one of the submodels delivers recommendations with better relevance, the results of other models can disappear from the list.


Once configured, submodels are enabled for the model globally. All the scenarios which use this model also use the submodel. If you do not want to group recommendations based on a certain attribute, remove the attribute parameter from the request. The submodel is then omitted.


Segments allow getting personalized content suitable for particular user groups. They compute models based on segment attribute factor. Information with user segment is provided in each event which comes from the tracking script.

First, make sure you have enabled personalization and configured item type tracking.

If your user Role includes the Segment/All functions, Segment group/All functions Policies, you can configure segment settings in the models according to your requirements. To do this, go to the Models section and click the Edit icon next to a name of the model.

With segment groups you can assign users to different recommendation groups based on data gathered and deliver recommendations to these user groups.

The Segment list displays only active segments and is generated from the events collected for relevant history (the actual data from recommendation engine, not what is added using the Back Office).

The value of each segment is transfered to the event.

Models are displayed only for a selected time period. If a group is inactive for a certain period of time, the segments get Inactive status and cannot be used.

Time period

Back to top