Recommendation scenarios (see chapter 2. Recommendation Use Cases) represent situations, where recommendations can be used in real world situations. For example a "product_page" scenario provides recommendations to a product detail page.
Every scenario has a configuration where one or more algorithms are specified to provide recommendations. The calculated result of one algorithm is called a model. The models work in the background and are usually updated every night to feed recommendations to the scenarios. There are several types of models available for configuring scenarios:
Models available for both basic and advanced edition
Classic popularity recommendation. The model can be customized using time dependent weights (last events are more important) and category based filtering (bestsellers in selected category and/or subcategories).
This is type of recommendations is often called "Collaborative Filtering based on user data" and is a proven approach to calculate recommendations. It recommends products which are usually clicked or purchased together. It is very simple to configure, needs no maintenance and it is a very powerful model.
Additional models are available for advanced editions
This model combines click and buy events. In human readable form it could be something like "Users who looked for that kind of product finally bought this". It therefore provides a "matching factor" of searching and buying.This model suggests alternative products which customers bought after they clicked on the selected product. In contrast to the "also-bought" model it recommends products that are related but not purchased together. This model is the best choice to suggest alternative products to customers when they are not sure if the selected product suits their needs. In contrast to the also-bought model this model can recommend the same item which is currently being viewed. For example, a user searches for a book which explains how to cut trees. If he finds a book and in the book page this exactly same book is being recommended, it means that several users interested in cutting trees bought this book (and not others), which hints that this book is the very best choice.
Frequently bought together
Products that were bought in this combination for at least n times can be treated as bundles and recommended as a "package". Based on the product which is currently shown, this model can recommend other products that fit exactly the one the user is currently looking at. An example could be:
A user wants to buy a smartphone and browses on the detail page of smartphone X. Additionally to the "Also Clicked" recommendations, the Recommender Engine would recommend the bundle Smartphone X + Protection for Smartphone X + Headphones as they were often bought together in exactly this combination for at least five times.
It is not guaranteed that there's a bundle available for every product. Therefore a rendering logic should display a box of bundle recommendations only if they are available, otherwise the box can be left out.
It works similar to the also-purchased model but additionally builds clusters of similar products based on predefined attributes. For example "author" for books or "color" for clothes. Using attributes additionally to the historical based similarity the recommendations can be applied to the new or non popular products. The model is especially effective in the following situations:
This model works very well with newly introduced products that haven't been clicked or bought often. It solves the "cold start problem", which translates the ability to provide recommendations with almost none or little history information. If your product portfolio is stable over weeks, you can use the classical also-purchased model. As mentioned above, this model requires custom attributes and deep business domain knowledge to work properly. For more information about attributes see the chapter 11a. Item import.
Content Based (by attributes)
The content based algorithm calculates the similarity scores among products based on given attributes. This algorithm depends on expert knowledge because one should be able to define the most important attributes of the product catalog. An example could be the price, the producer or the location of a product. In the news domain, this may be the story location the article is telling us about, the author or the category. The distinct attributes should be limited in their range because it does not make sense to build similarities based on attributes that are different for each product (e.g. a timestamp or EAN-Code). There is also a need to assign weights to these attributes since they are used to compute the the importance weight of each attribute for the similarity.
Content Based (by semantic full text analysis)
This model provides similarities based on free text analysis and indexing. This is a very powerful model publishers can use to get similar articles based on their content without the need of manual maintenance of related articles by e.g. editors. The full text analysis algorithm uses Apache Solr in the background.
The similar rated algorithm provides recommendations based on the user preferences. It predicts similar articles which he will probably like and that will suit his interests. Recommendations for articles similar to his dislikes are suppressed.
The best rated model provides recommendations based on algorithms that include the ranking values and the amount of distinct ratings. It is best suited on landing or category-entry pages.
Semi-random products from the most recent ones. 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 really simplified and non sophisticated alternative if no other information is available to calculate and provide recommendations.
This model is not build based on the history footprints but based on the imported product catalog. See the chapter 11a. Item import for more information.
Pseudo recommendation model to show the user products from his own history. Like "you have just watched" box. See the chapter 4. Scenario Context for the list of available history types.
Products that are manually selected by a human. A customer can replace an automatically generated recommendation with a predefined list. It is best suited when the store administrator wants to add special offers or sell stock remains. It could also be called "static recommendations".
Products on this list will never be recommended in any scenario. Usually test products or products that are used for system monitoring are placed on this list. The list MUST NOT be placed in any scenario config, it works globally!
Advanced Model Configuration
Most of the models provide additional configuration parameters for customization. Here is an example:
The parameters supported by the different types of models are described in the table below. Some models support submodels, see chapter 10. Sub-Models for more information. Additional differentiation criteria is the supported context (see 4. Scenario Context). If a model requires context it can only be linked to scenarios that provide the necessary context.
|Model type||Available parameters||Submodel support||Scenario context|
Relevant event history defines the time period for which the statistics must be analyzed. Dependent on the product type it can be selected between several months and several hours.
Fast event aging can be used, to weight newer events higher than older events.
|yes, manual||not needed|
|Also clicked/bought||Both also clicked and ultimately bought models allow to define the relevant event history.||yes, manual||required (either context items or user profile)|
Maximum item age defines the age of the products that will be recommended by this model. Only products added to the portfolio in the specified time frame will be recommended.
This model specifies several attributes that are use for providing recommendations based on similarity between the item attributes. For example it recommends article from the same region or from the same author.
|yes, automatically||requires user profile context|
|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 (see chapter 4. Scenario Context).||no||required|
|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 mix event history age and item age. The history age is the age of the users footprint (for example "he clicked on the product A two weeks ago"). The item age is the time since when the item is available in the shop - so to say "how new is the item". The history is filled automatically over event tracking (see 8. Event Types). The item catalog must be filled separately over the item import (see 11a. Item import).
The model configuration done over the interface described in this chapter is applied to the model for the whole configuration. It will be applied for all the scenarios the model is linked with. If you need multiple different configuration for the same model (for example long popularity for the last year and the short one for the last week), multiple models must be created. The number of available models depends on the license type. Creation of new models in not possible over the user interface, please call support if needed.