Introduction
Customer-specific assortments allow to create personalized catalog browsing and searching. The assortments can be constructed in different ways, depending on the requirements.
This guide shows some of the options and helps you choose the most efficient way. It is intended for business users who will maintain the assortments in Intershop Commerce Management (ICM) or for requirements engineers or developers who plan to integrate externally managed assortments into ICM.
Reading Concept - Customer-Specific Assortments first is recommended.
Glossary
Customer | A natural or legal person who is browsing an online shop. |
Assortment | A manually or automatically curated group of products which are made available to a customer or customer segment. A sub-amount of all products within a shop. |
References
How to Construct Customer-Specific Assortments Efficiently
The data needed for the assortments is always stored in custom attributes (either at the product, the customer, etc.). The multiple string attribute type allows to store many, but not unlimited, values. Therefore, careful planning is needed to find a way to store the least amount of data. This will also make it easier to maintain the assortments in the long run.
Points to consider:
Target group and contents
Are the assortments specific for users, customers or customer segments?
Are the assortments made up from individual products, selected categories or entire catalogs?
Where is the data stored?
Extend or reduce?
Does a registered customer have access to an extended or reduced assortment?
Combinations
Target Group and Contents
Target Group
Different shops have different approaches regarding the target group of an assortment.
The target group could be defined at customer level - in this case, follow the instructions in the Concept - Customer-Specific Assortments | Configuration.
It could also be defined at user or customer segment level. In this case you need to create a new placeholder to use in the product filter. This can be done with very little effort. Instructions can be found in the Cookbook (the recipe is written for another placeholder, but the instructions are similar).
Contents
The assortment can be defined at product level - check the instructions in the Concept.
It can also be defined at catalog or category level, even on brand level. In this case you need to create a new placeholder to use in the product filter. This can be done with very little effort. Instructions can be found in the Cookbook.
Where is the Data Stored?
There are always two objects that need to match for a product to be visible (or hidden) in the storefront. The following examples use product and customer. Of course, the whole concept is also valid when using categories and customer segments, or any other combination of objects. Consider the following cases for different options for storing the data to keep the amount of data small to not run into storage limitations or loose too much performance.
Case: Few Products, Many Customers
In a shop with few products it is recommended to store the data at the customer.
There are two ways to determine if a product ID is available for a given customer:
Example:
Data stored at the product | Data stored at the customer | ||
|---|---|---|---|
Product ID | Product Custom Attribute "Customer ID" | Customer ID | Customer Custom Attribute "Product ID" |
product A | 123, 234, 456 | 123 | product A, product B, product C |
product B | 123, 456 | 234 | product A, product C |
product C | 123, 234, 567, 678 | 456 | product A, product B |
567 | product C | ||
678 | product C | ||
As you can see, the number of attribute values per line is lower in the 2nd case. In the 1st case the list per product will get longer with each new customer who is assigned.
Case: Many Products, Few Customers
If your shop has a very broad assortment and registered customers usually have only a small specific assortment, it is recommended to store the data at the product. This is also suitable for custom-made products, which, per definition, are only available for one customer.
There are two ways to determine if a product ID is available for a given customer:
Example:
Data stored at the product | Data stored at the customer | ||
|---|---|---|---|
Product ID | Product Custom Attribute "Customer ID" | Customer ID | Customer Custom Attribute "Product ID" |
product A | 123, 234 | 123 | product A, product D |
product B | 234 | 234 | product A, product B, product C |
product C | 234, 345 | 345 | product C, product E |
product D | 123 | ||
product E | 345 | ||
As you can see, the number of attribute values per line is lower in the 1st case.
Case: Many Products, Many Customers
For large shops, where the cases above do not apply, because both sold products and customer are numerous, there is another option to keep the amount of stored data low.
Here virtual "assortments" are defined and stored both at the product and the customer.
Example:
Assortments are defined as follows (not in ICM, but maybe in a spread sheet):
* special_editions: product A, product B, product C, product D
* spring_summer: product E, product F, product H
In ICM the following data is stored:
Product ID | Product Custom Attribute "Assortment" |
|---|---|
product A | special_editions |
product B | special_editions |
product C | special_editions |
product D | special_editions |
product E | special_editions, spring_summer |
product F | spring_summer |
product H | spring_summer |
Customer ID | Customer Custom Attribute "Assortment" |
|---|---|
123 | special_editions |
234 | special_editions, spring_summer |
As you can see, even with one "assortment" containing many products, the amount of attribute values per product and per customer is actually very low.
When using this approach, each time a customer browses the shop, the "assortments" stored at the products are compared with the "assortments" stored at the currently logged-in customer. If there is a match, the product is shown.
The examples above are created for good readability. Please do not follow them to the letter.
The names of the custom attributes can be defined freely (and should ideally not contain spaces). Multiple values should be separated by the pipe symbol | , not by colon.
Extend or Reduce?
Does a registered customer get access to an extended assortment, in order to encourage registrations, or to show custom-made products only to the one customer who requested them? Or should the assortment be reduced, because any given customer is only interested in a very specific part of the shop and should not be overwhelmed with millions of products?
In the example from the Concept, there is a base assortment for all customers and a handful of products are added for specific customers.
This is achieved by using the "IS" comparator. Use "IS NOT" to reverse the effect.
Here again, the recommendation is to store the least amount of data.
Combinations
After reading the possible options you understand the variety and flexibility of customer-specific assortments. Within and between each "category" there is the possibility to combine options.
Create a handful of assortments for customer segments based on catalogs, AND have additional specific products for selected customers.
Usually extend the assortments for registered customers, but blacklist some products nevertheless.
Think carefully about the specific requirements and draft a concept from this.
With great flexibility comes great risk of making a mistake. It is strongly recommended to manually set up the assortments for a small number of test products and check that the behaviour is as intended. This allows to adjust the concept, if necessary.