Variants are a common concept in eCommerce systems. Variants are products that differ in some aspect from one another but are based on the same model. An example of a variant is vehicle color or vehicle configuration. Using variants may add a level of complexity. You should consider using variants if you need it to reduce the complexity of managing lots of products that are similar. As an example, importing your product catalog updates from ERP is more complex if you use variants. The same variants may have a different set of possible values from different product categories. For example, the  variant attribute color may have different color sets for lipsticks and hair dyes. I’ve listed five different patterns that are commonly used for the product variant modeling. Hybris OOTB supports three of them, Multi-variant products (see #5) and variant types (see #1, #2).

• Default hybris product variant model
• Modified hybris product variant model
• Product families
• Using categories in role of base products
• Multi-dimensional products

I. Default hybris product variant model

Overview

According to this model, the variant products are instances of special “concrete” variant types, organized into a two-level hierarchy. Each variant product has a reference to the base product.

Data model

Product pages

• every variant has its own product page
• base products don’t have separate pages

Search results and category pages

• only variant products are displayed in the search results
• base products aren’t displayed in the search results

Cart/Order items

• cart/order item can refer to either Product or VariantProduct.
• cart/order items can’t refer to  Product without variants

Known limitations and challenges

(a) if you need to convert an existing product of Product type into VariantProduct or vice versa, you will need to do a lot of cut-and-paste work in hybris backoffice or product cockpit. The hybris platform does not support item type promotion. The only way is to deactivate the product and create a new one of the desired type. (b) There are only up to two levels of variant products out-of-the-box (like Color and Size, or Style and Size) (c) if your variants have similar images, your search results may be confusing. The user would see identical items with only slight differences in names.

Recommendations

• data:
  • refer to the variation type in the variant product name. Like “A blue vase” / “A red vase”
  • use different images for different product variants. It will help you to make product lists more readable and concise
• customization:
  • think about additional product cockpit operations (“convert to variant” / “convert to base product”)

II. Modified hybris product variant model

Overview

The key difference of this approach is in the way of indexing variant products. Unlike the traditional model this approach doesn’t index and present variant products in the category and search results pages as an item. The product search result list is based on base products not variant ones (variant rollup).

Data model

• the same as in the previous section (I)

Product pages

• the same as in the previous section (I)

Search results and category pages

• only base products are displayed in the product list (category and search results pages). That’s called “variant rollup”.
• variant products are not presented in the product list

Cart/Order entries

• the same as in the previous section (I)

Known limitations and challenges

• (a) and (b) from the previous section
• different sections may have different rollup configurations. hybris doesn’t support it, the medium-size customization is needed

Technical details

You need to change the Solr indexing query used to index base products only. To get the attribute values of the variants into the index you use value providers and create solr index entries where you accumulate these values for index. The electronics demo store only indexes products (not variants), maybe that can be a template to work from and modify this to only reference variant base. Value provider is a java bean you register via Spring that gives the actual values to the indexer. You need to configure an index entry and reference a value provider. Then you need to implement and register this value provider (by changing SolrIndexedProperty).

III. Product families

Overview and data model

For this option, the data model is simpler: there is no additional items or tables/itemtypes for the variant products.

• There is an attribute called “family” that has the same value for the group of similar products.
• There are variant-specific attributes that also group products inside the product family.
• There is no base product in the database. All products are equitable variants. If all variants have the same attribute value, there will be a duplication.
• If you need to manage these attributes together, you need to implement a custom functionality in Product Cockpit, “Product Family Editor”.

For the regular products (that have no variants), the product family field contains the same value as the Product Name field. Very often this data model reflects the ERP’s data model, that makes easier to migrate data and implement the regular data import. Variant products can be created in ERP in any order, and hybris will group them automatically. It is possible to create ProductFamily as a separate entity and connect it with a given Product not by a hard reference using PK but rather through a kind of soft reference using the ProductFamily identifier. Decoupling will help you to make enriching the product family optional. “Grouping configuration” is an optional attribute that helps hybris to display the variant navigation properly. For example, the order of variant attributes in the form on the product page may be different. Another use of this field is to specify a set of variant attributes used in the form on the product page (by default all the variant fields are used to build a form).

Product pages

Since this approach is 100% custom, there is no default/OOTB behavior. So you can implement one of the following:

• Each variant has its own product page. There is an in-page navigation between the products of the same product family.
• There is a product family page only. All variants are presented as a list of variations on the product family page with numerous BUY/more info buttons. There is no separate product pages for the variants.

If the family info is present in FamilyProductInfo by product family name, the data from FamilyProductInfo is used along with the variant product information. FamilyProductInfo is optional. Otherwise, only the variant info is used.

Search results and category pages

Since this approach is 100% custom, there is no default/OOTB behavior. So you can implement one of the following:

• only product families are displayed in the product list (category and search results pages).
• only variant products are presented in the product list.

The logic can be different for different product types. If the family info is present in FamilyProductInfo by product family name, the data from FamilyProductInfo is used along with the variant product information. Otherwise, only the variant product info is used.

Cart/Order entries

• Once all the products are of the Product type, all cart entries refer to the variant products (if any) or to the regular product (that has no variants).

Known limitations and challenges

The major drawback is that there are data duplication and redundancy. That is why this approach is not suitable for every project. If you need to change common attributes for the bunch of variant products, you need to use Hybris Mass Edit feature or implement your own custom tools to make these operations easier.

IV. Using categories in role of base products

Overview

In this pattern, the complex products are basically categories. All products inside the category represent product variants. The category page looks like a product page for the categories of this kind. It is convenient for the complex products with a large number of variations and complex filtering. You can leverage the SOLR facet search and custom category page templates to make the interface more convenient and relevant to the specific product. This approach is especially good for manufacturers with a limited set of base products and complex product variations. All products have the same type, based on the default Product type.

Product pages

Product pages are only for variants. Category pages are used as a base product pages.

Search results and category pages

The simplest option with minimal customization is put only variant products in the search results.

Cart/Order entries

Once all the products are of the Product type, all cart entries refer to the variant products (if any) or to the regular product (that has no variants).

Known limitations and challenges

Category pages need customization for the variant groups. Using Category object s for other purpose than handling categories may confuse or mislead, so it should be documented propertly, the special purpose category type should be named properly etc.

Examples

For instance, this approach will work well for the tire shop. As you possibly know, the tires are defined by the following key attributes:

• Brand – Model
• Seasons (all year, winter, summer)
• Width
• Height
• Diameter

Note, that the width, height and diameter can be grouped in the one field called “Tire size”. Basically, all tires of the same (Model + Model + Season) look similarly. The description and other attributes are also the same, so tires can be used as a classical example of the variant products. Tires can be grouped differently depending on user preferences and marketing considerations:

• Brand – Model – Tire size
• Tire size – Brand
• Tire size – Seasons – Brand
• Car Brand – Car Model – Seasons – Brand

One of the possible solutions for variant products is using categories for

• tire brands
• tire seasons (all winter tires, for example)
• tire models (as subcategories of tire brands)

The following attributes can be used as filters:

• brands
• seasons
• size (width / height / diameter)
• width
• height
• diameter
• tire seasons

However, you need to design a procedure of adding new products. For example, if a product of the new brand was arrived, you need to add both a brand a product model.

V. Multi-dimensional products

Overview

Multi-dimensional products are described using multiple Categorys (dimensions) and multiple VariantValueCategorys (attributes). VariantCategory represents one of the variant dimensions, such as a size, or color.  Unlike the alternative default approach, you can have more than two levels of the dimensions. In order to specify what dimensions are required for the product, the VariantCategory item is assigned to this product as a regular product supercategory. When one or multiple VariantCategory items assigned to the Base Product item it starts acting as a template indicating what dimensions are used for the variant products. These Variant Categories can be chained, i.e. organized into a hierarchical structure. VariantValueCategorys represents all available values for VariantCategory. In order to specify what value the product variant attribute has for the specific product, the appropriate VariantValueCategory item is added to the variant product’s supercategories list. Hybris uses field for product variant modeling (in addition to the main purpose of this attribute, positioning the product in the product hierarchy). hybris uses  differently for base products and variant products. For the base products this field tells hybris about allowed variant types. For the variant product it is a way of handling variant attribute values. For both product types this field is also used for assigning a product to regular categories (navigation, brands etc).

Product pages

• every variant product has its own product page
• base products don’t have separate pages

Search results and category pages

• only variant products are displayed in the search results
• base products aren’t displayed in the search results

Known limitations and challenges

• Fixed list of possible values. If you have a new value for the variant attribute, you need to add it to the list first, and then pick it from the list
• The type conversion issue is also relevant to this approach. The hybris platform does not support item type promotion. The only way is to deactivate the product and create a new one with the desired type.

© Rauf Aliev, October 2016