Document Properties
Kbid
3079U5
Last Modified
10-Jul-2023
Added to KB
20-Mar-2023
Public Access
Everyone
Status
Online
Doc Type
Guidelines
Product
  • ICM 7.10
  • ICM 11
  • ICM 12
Guide - Customer-Specific Assortments

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.

Disclaimer
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.
The Intershop Knowledge Portal uses only technically necessary cookies. We do not track visitors or have visitors tracked by 3rd parties. Please find further information on privacy in the Intershop Privacy Policy and Legal Notice.
Home
Knowledge Base
Product Releases
Log on to continue
This Knowledge Base document is reserved for registered customers.
Log on with your Intershop Entra ID to continue.
Write an email to supportadmin@intershop.de if you experience login issues,
or if you want to register as customer.