Model the product catalog

When designing the content model for the product catalog, it is recommended to use content storage options provided by Xperience by Kentico instead of developing custom classes or modules. In this release of the digital commerce feature, there are no dedicated commerce fields (e.g., price, currency, stock).

There are two options when it comes to storing your product catalog. Either you can store products as reusable content items in the content hub, or you can store them as pages in a website channel.

General recommendations

The following recommendations are valid regardless of the selected catalog storage option:

• Use reusable field schemas for common product fields. The schema should contain all fields that are used when displaying products in a listing. For more information, see Product fields.
  • ProductFields (reusable field schema)
    • ProductFieldsName
    • ProductFieldsDescription
    • ProductFieldsPrice
    • …
• Create content types for individual product types depending on required product fields:
  • Book (product type)
    • ProductFields (reusable field schema)
    • BookAuthor
    • BookCoverType
    • BookGenre
    • …
  • Reader (product type)
    • ProductFields (reusable field schema)
    • ReaderManufacturer
    • ReaderStorageSize
    • …
  • Accessory (general product without any extra fields)
    • ProductFields (reusable field schema)
    • ProductFields (reusable field schema)
• You can use reusable field schemas for sub-groups of product types. For example, all clothing has common properties in addition to the basic product fields:
  • ClothingProductFields (reusable field schema)
    • ClothingProductFieldsColor
    • ClothingProductFieldsSize
    • ClothingProductFieldsMaterial
    • ClothingProductFieldsManufacturer
• A field storing the product manufacturer can be separated into a reusable field schema

Product variants

It is recommended to model product variants as “child” items of a parent product, which holds all the shared information. Create a dedicated product content type for product variants and include only the fields that need to be overwritten from the parent. We recommend defining reusable field schemas that group the modified fields, so you can easily reuse them across different types of variants.

A sample configuration can look like the following:

• ProductSizeFields (reusable field schema)
  • ProductSizeFieldsValue
• Shirt (parent product type)
  • ProductFields (reusable field schema)
  • ShirtMaterial
  • ShirtColor
• ShirtSizeVariant (variant product type)
  • ProductSKU (reusable field schema)
  • ProductStock (reusable field schema)
  • ProductSizeFields (reusable field schema)

Note that the parent product doesn’t need to store an SKU, since you cannot buy a shirt without specifying the variant. On the other hand, the variant product doesn’t need to store product fields, since the shirts are identical except for their size.

Variants in the content hub

When storing products as reusable content items in the content hub, the parent product should include a Variants field configured as a combined content selector restricted to the product variant content type. This allows you to clearly link variants to their parent. The parent product also you to create a page to provide a public URL.

Product variants appear in the same flat list as the parent products. To organized products, use clear naming conventions. We recommend to name the variant using the parent product’s name followed by a distinguishing suffix, for example: “Striped grey T-shirt - M”. Since product variants typically don’t require their own public URLs, there’s no need to create a page for them.

Variants in website channels

When storing products as pages in a website channel, use the content tree to reflect the parent-child relationship between products and their variants by placing variants under the parent product. The parent product acts as the main product entry and should have its own URL.

For product variant content types, you can disable the Include in routing setting, as they usually don’t need to be accessed through a separate URL. Follow the same naming recommendation: use the parent product name and add a variant-specific suffix: “Striped grey T-shirt - M”.

Product fields

The base product reusable field schema should contain all fields that are used when displaying products in a listing. This enables you to easily work with the products programmatically and display all products in a universal way.

Recommended product fields are:

• ProductFields (reusable field schema)
  • ProductFieldsName
  • ProductFieldsDescription
  • ProductFieldsPrice
  • ProductFieldsImage
  • ProductFieldsCategory
  • ProductFieldsTags

SKU field

An SKU (Stock Keeping Unit) is a unique code used to identify and track a specific product or product variant in a store’s inventory.

Create a reusable field schema with a SKU field:

• ProductSKU (reusable field schema)
  • ProductSKUCode

The SKU field can be included in the Product fields reusable field schema. However, when implementing product variants, you may want to have a distinct SKU for each product variant, but only need Product fields for the parent product.

Product stock

Depending on the products you are offering, you may need to implement products with infinite stock (e.g., e-books, software, online courses, gift cards).

• If you offer products with infinite stock, create a separate reusable field schema that contains the stock field. This schema can be omitted when modeling products with infinite stock.
  • ProductStock (reusable field schema)
    • ProductStockNumber
• If you don’t offer products with infinite stock, the stock field can be added to the SKU reusable field schema.
  • ProductSKU (reusable field schema)
    • ProductSKUCode
    • ProductSKUStockNumber

SEO fields

If you use content hub as the storage for your product catalog and you want to automatically generate pages for each product, it is recommended to store SEO fields (e.g., title, description, keywords) together with the product in the content hub, so that you can edit all properties of a product in one place.