This concept is valid from Intershop 220.127.116.11.
To create customer-specific views of catalogs and products, there is the Catalog View feature. However, the demand for personalization rises to a point where Catalog Views are no longer sufficient. Catalog Views are suited for a handful of views, e.g., for customer segments. They are not suited for thousands of different views, individually for each customer.
The new approach are Customer-Specific Assortments. They work with the search index and allow a more flexible configuration without performance loss.
It is possible to include or exclude products for specific customers. This is done via custom attributes either at the product or at the customer.
With the corresponding configuration many possible applications of this feature are available. Some options are:
If a product is included, there is nothing special. The customer can see and purchase the product.
If a product is excluded for a specific customer, the following behavior applies:
To create assortments, it is necessary to carefully analyze the project requirements. Some examples are given here. However, this can be extended in projects.
Basically, product attributes are compared with customer attributes.
Use case: The shop has a general assortment for all customers. In addition, there are products which are especially made for one (or very few) customers.
Value: "<customer ID>", e.g., 1234567 (so the product will only be visible for the respective customer, i.e., 1234567 in this case)
The configuration is set up once. However, all changes to the product data require an update of the search index to become effective.
Use case: Similar to the previous one. A shop has a general assortment for all customers. However, some products should be hidden for some customers.
Customer-specific assortments are currently in progress. The provided feature set is fully functioning, but it still has some limitations. Over time the feature set will grow.
Page caching works on customer segment level. With customer-specific assortments this mechanism needs to be used carefully. Since especially product lists can be highly individual now, caching per customer segment is no longer useful.
The recommendation here is to disable page caching of such pages.
This section applies until Intershop Commerce Management 18.104.22.168, for later versions this limitation no longer applies.
The mega menu in the storefront is not fully compatible with customer-specific assortments. It evaluates the "online" flag of categories and catalog views to define if a category is visible there or not. If categories are empty, because the search index filters out all contained products for the current customers, this category is still visible - and empty.
This section applies until Intershop Commerce Management 22.214.171.124, for later versions this limitation no longer applies.
The category page is not fully compatible with customer-specific assortments. It evaluates the "online" flag of categories and catalog views to define if a category is visible there or not. If categories are empty, because the search index filters out all contained products for the current customers, this category is still visible - and empty.
The filter navigation in the sidebar is fed from the search index, so empty categories are filtered out there.
The quick order form in a B2B shop allows to order by product ID. Entering a product ID which is excluded for the current customer is still possible.
In such a case the product will not be added to the cart. However, an error message including name, image and price of the product is shown.
This feature is designed to allow a much greater flexibility than Catalog Views. Nevertheless the amount of data is not unlimited.
Example: Using custom attributes at the product as described above is designed for customer-specific products. The assumption is that the amount of customers who can see one product is either "all" or a low number. Approximately 5000 values for one custom attribute have been tested and were working. Nevertheless the actual amount in a real scenario can be different, depending on the length of the values, amount of products in the channel, etc. The bottleneck is the memory of the database while the search index is built.
If you can foresee that the number of values for one attribute will be larger, please consider an alternative setup of the assortment, e.g., instead of comparing a product attribute to a customer ID, you can compare it with the customer segment ID. Alternatively, you can maintain the data at category level instead of product level.
The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.