Product variants: how to model sizes, colors and versions

The problem: the same record fifteen times

A T-shirt sold in five sizes and three colors is fifteen SKUs. If each one is treated as a separate product, the brand, description, composition and photos repeat fifteen times. When something changes, it has to change in fifteen places, and in the store buyers see fifteen nearly identical products instead of one with a selector.

Parent, children and axes

The way to avoid it is to separate what is shared from what varies:

• The parent product holds what all versions share: brand, commercial name, description, composition, general photos.
• The variants (children) are products with their own SKU that only hold what sets them apart: size, color, their photos, their stock.
• The axes are the attributes that differentiate the children: size, color, capacity. They are declared on the parent.

Axes work best as list attributes with allowed values: that way “M” is always “M” and the store can build the selector.

What channels ask for

Each channel receives variants its own way, but almost all need the same thing: to know which products form a group and how they differ.

• Google Merchant Center asks for a group identifier for variants, the same for every variant in a group and stable over time, and recommends using the parent SKU where possible. It also asks for the attributes that distinguish each variant, such as color and size.
• In structured data, Google describes variants with ProductGroup, which lists its variants and says which attributes they vary by.
• Stores often call the parent a “configurable product” and build the selector from the axes.

Common mistakes

1. Variants as separate products. Duplicated records and a catalog that looks bigger than it is.
2. Axes typed by hand. “Navy blue” on one child and “Navy” on another break the selector.
3. An axis that is not an axis. If two “variants” have different specifications, they are probably different products.
4. Photos only on the parent. Buyers want to see the color they picked.
5. The group identifier changes between uploads, and the channel loses the grouping.

The description: one for all

When variants share a description, write it on the parent. If each child needs its own text, it should start from the parent's text so they all sound the same: nine descriptions written separately for nine sizes end up saying different things about the same product.

Variants, photos and stock

Each variant sells something concrete: a size that can sell out, a color that looks different. That is why, even when it shares the description with its parent, it should have:

• its own photos when it looks different, especially for color;
• its own stock, so the store can stop offering the sold-out size without hiding the whole product;
• its own identifiers, such as the GTIN, because each combination has one.

What does not change between variants is not repeated: it is inherited from the parent.

How Bruxel handles it

In Bruxel each variant is a product with its own SKU that hangs from a parent product. They are linked on import, with a parent_sku column, or later from the product record. Axes are declared on the parent —list or yes/no attributes, up to four— and, when a child's description is generated, the parent's description is passed as a reference so they all sound the same. The variants guide explains it, and the attributes guide shows how to define axes as lists.

Where to start

Look for products in your catalog that repeat with a size or color in the name. Group them under a parent, define the axes as list attributes and check that each child has its value on every axis and, if it looks different, its own photos.