This guide will walk you through the setup of the recommendations templates which will be also used in the Recommendations Use Cases.

For reference on the individual models see Product Recommendation Templates

📘

Choose Your Template

To find the template you need, use the table of contents on your right ➡️.

🚧

Product Catalogs

All templates use product catalogs. To find them or import new catalogs, go to Data & Assets > Catalogs.

New Items

1. Choose a Catalog

Choose a product catalog that contains all your products and set a catalog filter to filter our only relevant products. Typically, it's used to filter only available products.

2. Choose the Date Column

Choose the column with the date when an item has been added or updated in the catalog. This field must be part of the imported product catalog and it isn't automatically created by Bloomreach Engagement. This column could be any numerical/date-time column and results will be sorted in descending order.

3. Leave Optional Sections Empty and Save the Model

📘

Additional Options

Additional options are described in the Product Recommendations Manual

📘

Integration Process

Integration process on Homepage or to Campaigns is described in the Integration of Recommendations

Textual Similarity

This feature is currently available in Beta version

This model shows similar items to a given product based on textual attributes (e.g., product title, product descriptions).

The main requirement for the catalog is to have an up-to-date title and description of all products that you want to consider for recommendations. The higher the quality of textual attributes the better recommendations you can expect.

Take an example of a fashion store that wants to recommend most similar products to the currently viewed item so that:

• The brand will be consistent
• The category_level_1 will be consistent
• If possible, the category_level_2 will be consistent
• If possible, the category_level_3 will be consistent
• Recommended products were not already bought by a given customer last 90 days

🚧

If Failure Occurs...

If the engine fails to recommend items under desired conditions, it will fall back into recommending items from the catalog that are still compliant with the provided exact and optional match filters, but they don't need to be necessarily based on the selected textual attributes.

If the model even fails to recommend items using this first-layer fallback, it will fall back into recommending random items. If you spot such behavior while testing it, please consider using the “Advanced template” with a simple combination strategy with other models such as previously seen items.

1. Choose a Catalog

Set a product catalog that contains all your products and set a catalog filter to recommend only products in stock:

2. Specify Exact Match and Optional Attributes

Choose the attributes to be considered while matching alternative products. Only searchable catalog properties can be used. In our case, the exact match ones are category_level_1, brand and the optional ones are category_level_2, category_level_3.

The exact match attributes will be used as a necessary condition for matching products. The optional ones are preferred but not necessary.

You can also specify the overlap size determining the minimum number of matches of the optional attributes. In this case, we require the optional match to be 1 = either the category_level_2 will be consistent or the category_level_3 will be consistent. Items with no match on category_level_2 or category_level_3 will be considered as irrelevant.

🚧

You can often set these settings too restrictive - thus resulting in bad performance. Always try to consider weaker conditions if the model performance isn't sufficient.

3. Specify Textual Attributes

Choose the textual attributes based on which the textual similarity of products will be calculated. In our case, the textual attributes are title and description.

Note, items will be ordered based on textual similarity that is computed through TF-IDF algorithm.

🚧

Items with similarity lower than similarity threshold are filtered out. If items are too different, it's possible that the engine will recommend less results than expected.

4. Blacklist Already Bought Items

Enable blacklist to not show products that were already bought by a given customer in the past 3 months.

More Like This

This model shows similar items to the reference item (one currently viewed by the customer) based on shared catalog properties.

The main requirement is to have all properties for products in your catalog that you want to consider for recommendations and to have them as searchables.

Take an example of a fashion store that wants to recommend most similar products to the currently viewed item so that:

• The brand will be consistent
• The category_level_1 will be consistent
• If possible, the category_level_2 will be consistent
• If possible, the category_level_3 will be consistent
• Recommended products were not already bought by a given customer last 90 days

1. Choose a Catalog

Set a product catalog that contains all your products and set a catalog filter to recommend only products in stock:

2. Specify Exact Match and Optional Attributes

Choose the attributes to be considered while matching alternative products. Only searchable catalog properties can be used. In our case, the exact match ones are category_level_1, brand and the optional ones are category_level_2, category_level_3.

The exact match attributes will be used as a necessary condition for matching products. The optional ones are preferred but not necessary.

You can also specify the overlap size determining the minimum number of matches of the optional attributes. In this case, we require the optional match to be 1 = either the category_level_2 will be consistent or the category_level_3 will be consistent. Items with no match on category_level_2 or category_level_3 will be considered as irrelevant.

🚧

You can often set these settings too restrictive - thus, resulting in bad performance. Always try to consider weaker conditions if the model performance isn't sufficient.

3. Blocklist already bought Items

Exclude products that were, for example, already bought by a customer in the past 3 months.

4. Set Customer Preferences

You can also narrow down recommendations to individual preferences of your customers. This will result in matching recommendations being shown on top of the results for the specific customer.

Filter Based

This model displays products, randomly selected based on the criteria defined in your preferred catalog filter, to present to your customers. You can use catalog filters like category, brand, price, or a combination of these.

The key requirement is an imported product catalog with comprehensive features such as descriptions, tags, brands, categories, colors, etc.

Take an example of a fashion store that wants to evenly promote products from Brand A that cost over 50 USD and exclude products bought by that customer in the last 90 days.

📘

If called via Jinja, the dynamic catalog filter from the get-recommendation request is ignored in the Filter Based template.

1. Choose a Catalog

Set a product catalog that contains all your products and set a catalog filter to recommend only products that are:

• on stock,
• from Brand A,
• cost over 50 USD.

2. Blocklist already bought Items

Exclude products that were, for example, already bought by a customer in the past 3 months.

Product Detail

This model analyzes customers' past browsing sessions of different products. We assume that customers typically browse similar items while seeking alternatives. Therefore, product representation is based on these historical interactions.

This method's benefit is the recommendation of alternative products, even for customers without any historical data.

1. Choose a Catalog

Set a product catalog that contains all your products and set a catalog filter to recommend only products in stock.

2. Specify the Target Event

Specify the target event and some attributes based on which the model can create the product representation. Natural attributes like the total price from the purchase events are recommended.

3. Blocklist already bought Items

Exclude products that were, for example, already bought by a customer in the past 3 months.

Optionally, you can also set the customer preferences reordering. Check the Alternative Products (based on items) as an example.

Popular Right Now

This model recommends products that are sorted according to a given metric. This metric is chosen as a count of events (most of the time purchases or views) and represents the popularity of products.

Take an example of a fashion store that wants to recommend most popular products on the homepage so that:

• Popularity = view count in the last 90 days
• Products already bought by a customer viewing these products won't be recommended
• Prefer products of the brand that matches the preference of a customer if possible

1. Choose a Catalog

Set a product catalog that contains all your products and set a catalog filter to recommend only products in stock.

2. Specify the Metric Event

Specify the metric event so that the historical count reflects your representation of popularity. It’s usually calculated as a count of purchases (hot items) or a count of views (most trending items). This example uses view_item.

While mapping the popularity metric, don’t forget to add the product ID identifier to the chosen event.

3. Set the Learning Window

Set the historical timeframe relevant to the calculation of the metric event. In this case, we have defined the popularity for each item as “Count of views in the last 90 days”.

4. Blocklist already bought Items

Exclude products that were, for example, already bought by a customer in the past 3 months.

To further personalize, rearrange recommendations based on customer preference, like showcasing products from their preferred brand derived from previous purchases.

If multiple preferences are used, products meeting the primary condition are listed first, followed by those meeting the second condition, etc. Products not meeting any criteria are listed last.

Metric-Based Category

These engines are best suited for placement on a category page. There are two prerequisites to leveraging this engine - correct data mapping and tracking of categories in events (see Requirements in the Template documentation).

The following case is an example for a fashion store that wants to show the top-viewed items within the category that the customer is currently looking at.

1. Choose a Catalog

Set the desired catalog which contains items to be displayed in recommendations.

Sometimes you don't want to recommend all items from your catalog. In such cases, you can choose to filter items based on their attributes located in the catalog.

Since this engine will be used in the category page, show as many popular items as possible as long as these items are active.

2. Choose the Metric Event and Attributes

Chose the catalog identifiers, time frame, and interaction event metric.

Specify the event that corresponds to the desired historical interaction between customers and products. For top-selling items pick purchase_item event, for top-viewed items pick view_item event, for the most often wished items pick add_to_wishlist event, etc.

This example usesview_item.

Specify two parameters for the selected event:

• parameter corresponds to product ID (in our case product_id),
• parameter corresponds to tracked categories (in our case category_level_1). It can be a string or list of strings (see Product discovery Use Cases).

Specify the time frame and interaction event metric.

If you want only top-selling products from the last month - select Lats 30 days.

The metric uses the same logic as reports: for top-viewed items pick: count > event > "view_item" etc.

The catalog item identifier must be equal to the item_id column in your catalog. If this step isn't done properly, the engine won’t work as intended.

3. Blocklist already bought Items

Exclude products that were, for example, already bought by a customer in the past 3 months.

4. Set Customer Preferences

In some special cases you can reorder the recommendations by the preference of the customer. In the case of "Metric based category" template, we don't suggest to use this setting without consultation with our team (it can cause unexpected behavior of your engine).

5. Correct Recommendation Integration

This is the last step of the engine setup. Afterward, you can save your engine. However, this template requires one special attribute in recommendation integration - categoryNames (see technical manual). Attribute categoryNames determine categories for which the engine generates recommendation (e.g. currently viewed category).

The logic for selection of items from category/categories:
There are four ways to select the items. Each way uses different operator to select recommended items (operator from reports):

• We track category as string & request single category in categoryNames attribute (e.g., in event view_item we track category: "t-shirt" & we call getRecommendation with categoryNames = ["t-shirt"]). Used operator: equals. The engine recommends all items where category equals to "t-shirt" (sorted based on event metric).
• We track category as string & request list of categories in categoryNames attribute (e.g., in event view_item we track category: "t-shirt" & we call getRecommendation with categoryNames = ["t-shirt", "shirt"]). Used operator: in. The engine recommends all items where category in ["t-shirt", "shirt"].
• We track category as list of strings & request single category in categoryNames attribute (e.g., in event view_item we track category: ["t-shirt", "woman", "short-sleeve"] & we call getRecommendation with categoryNames = ["t-shirt"]). Used operator: any item equals. The engine recommends all items where any item from category equals to "t-shirt".
• We track category as list of strings & request list of categories in categoryNames attribute (e.g., in event view_item we track category: ["t-shirt", "woman", "short-sleeve"] & we call getRecommendation with categoryNames = ["t-shirt", "shirt"]). Used operator: any item in. The engine recommends all items where any item from category in ["t-shirt", "shirt"].

📘

Additional Options

Additional options are described in the recommendations documentation.

Customer Recent Interactions

This model is best suited for reactivation campaigns with a goal of repeated purchases. This requires just recent user interactions.

Take an example of a fashion store that wants to recommend last viewed items using a targeted campaign in order to reactivate lost customers in the last 7 days.

1. Choose a Catalog

Set a product catalog that contains all your products and set a catalog filter to recommend only products in stock.

2. Specify the Interaction Event

Specify the event that corresponds to the desired historical interaction between customers and products. This case uses view_item mapped on product ID.

3. Set the Learning Window

Set the historical timeframe relevant to the last viewed items. In this case, last 7 days are used because we are interested only in customers who interacted with the products recently.

📘

Additional Options

Additional options are described in the recommendations documentation.

📘

Campaings Integration

The integration process to Campaigns or other parts of the webpage is described in the technical manual.

Personalized Recommendations for You

Recommend items that similar customers like using collaborative filtering-based recommendations.

1. Choose a Catalog

Set a product catalog that contains all your products and set a catalog filter to recommend only products in stock.

2. Specify the Required Events

Set three required events based on which the similarity between customers will be computed.

These three events are the Detail view event which refers to an event when a customer visits the detail page of a product, Add to cart event refers to an event when a customer adds anything to a cart and Purchase event refers to an event when customer purchases a product.

3. Specify the Optional Events

You can set additional events that might indicate customer preference to a given product like a Wishlist event or Rating event. This example leaves it disabled.

4. Set the Learning Window

Learning window is the data timeframe for training the machine learning model. It's recommended to use at least 3 months of past interactions for more useful pattern recognition.

However, if customer preferences quickly change, a shorter duration is advisable. If a customer has no interactions (defined in step 2) in this period, personalized recommendations can't be made, and products with the most interactions will be used as a fallback.

5. Blocklist already bought Items

Exclude products that were, for example, already bought by a customer in the past 3 months.

📘

Upgrade to Reccomendations+

Boost conversions with our premium Reccomendations+feature offering personalized product recommendations based on individual customer behavior.

Customers Who Bought this Item also Bought

This model considers items bought by similar customers for recommendation.

1. Choose a Catalog

Set a product catalog that contains all your products and set a catalog filter to recommend only products in stock.

2. Map the Purchase Event

In this step, you need to map the purchases on product IDs.

3. Set the Learning Window

The performance of the algorithm is heavily dependent on the number of historical co-purchases (more items bought together). Therefore Lifetime learning window is suggested.

4. Blacklist Already Bought Items

Enable blacklist to not show products that were already bought by a given customer in the past 3 months.

Customers Who Viewed This Item also Viewed

This model considers items viewed by similar customers for recommendation.

1. Choose a Catalog

Set a product catalog that contains all your products and set a catalog filter to recommend only products in stock.

2. Map the View Event

In this step, you need to map the view on product IDs.

3. Set the Learning Window

The performance of the algorithm is heavily dependent on the number of historical co-purchases (more items bought together). Therefore Lifetime learning window is suggested.

The performance of the algorithm is heavily dependent on the number of historical co-viewed item inside one session (more items viewed together). Therefore sufficiently long learning window is recommended

4. Blocklist already bought Items

Exclude products that were, for example, already bought by a customer in the past 3 months.