Documentation

This is the early access documentation preview for Custom Views. This documentation might not be in sync with our official documentation.

Products and Product Variants

Product Variants represent your distinct SKUs or sellable goods while Products act as a parent structure to your Product Variants.

  • After completing this page, you should be able to:

    • Distinguish a Product from a Product Variant.

    • In Composable Commerce, a Product is an abstract sellable good or service. Products themselves are not sellable instead they act as a parent structure for Product Variants. Some examples of products include:

    • A pair of shoes
    • A mobile phone plan
    • An ebook
    • A license
    • A downloadable file

    On a data level, Products are based on a Product Type that is selected when the Product is created. Products can only define values for the Product Attributes defined in the chosen Product Type.

    A Product holds information that is common to all Product Variants at the Product level, such as Categories, as well as meta information like title, description, slug, and search keywords. You don’t need to create Product Attributes for this type of information. Keep in mind that you can not add new fields to the Product at the Product level; this would need to be done at the Product Type level.

    The key consideration when modeling products is deciding what to model as Products and what to model as Product Variants. Often sellable goods of a business are the same in most aspects but differ in a few of their attributes. Such products can be modeled as Product Variants and then grouped into one parent Product.

    Products: keep in mind

    Remember the Composable Commerce API limits when considering product modeling:

    • A Product can only have 100 Product Variants.
    • Having too many Product Variants can cause a resource to reach the JSON document size limit. In general, it’s better to have more Products with fewer Product Variants.

    Products: helpful questions

    When modeling products, ask yourself the following questions:

    • What characteristics of the product need to be captured? For example, size, colour, etc.?
    • Which groups of Products (or more specifically, classes of Products) can we build based on these characteristics?
    • Can we create Product Types using these groups (classes)?
    • What should be a Product Variant or a Product? Try it out a few different ways before committing to anything.

    Product Variants

    Product Variants generally represent a distinct SKU or sellable good. In some cases, similar products may have various sizes; these represent a group of sellable goods which are identical except for one or two Product Attributes. The attributes that differ are generally not usable as sorting or ordering selectors in site navigation. As such they are not modeled as Categories but are more useful as filters for search results.

    For example, a clothing store might have a product, "Women's Pants" which has the following Product Variants:

    • Red Women's Pants in size 36
    • Green Women's Pants in size 38
    • Green Women's Pants in size 40

    Product Variants in Composable Commerce contain additional fields to store Product Variant data required to sell that SKU. This information includes images, assets, prices, and inventory entries. Therefore you don’t need to create additional Product Attributes to store this data.

    When to use Product Variants

    Using Product Variants is a key decision which must be made before importing your product data into Composable Commerce. Product Variants are a powerful way to model catalog data, but the limit of 100 Product Variants per Product needs to be kept in mind.

    When deciding to use Product Variants, try multiplying the variable Product Attributes with each other. This gives a rough idea of how many Product Variants a Product might have.

    For example, 5 colors, 10 sizes, and 4 fabrics make a selection of 200 possible combinations. This would breach the 100 Product Variant limit we mentioned earlier. We'd recommend modeling this as multiple Products instead, taking one of the variable attributes (color or fabric, for example) and using that to create a separate Product.

    Test your knowledge