Variant Management: Building a Colour-Size Matrix

Variant management means grouping the colour, size, capacity or other options of the same product under one parent and tracking each option with its own stock and barcode. The colour-size matrix is the most common shape: colours in rows, sizes in columns, one variant per cell. Get the matrix right and a single listing translates to every marketplace; get it wrong and every channel becomes a separate problem. This guide covers matrix design, channel differences and a step-by-step setup checklist.

Parent, axis and cell: getting the structure right

There are three levels in variant management, each with a distinct job.

• Parent product (model): The identity of the product family. Name, description, category, brand and shared images live here, along with the model code.
• Variant axis: The attribute that differentiates units. Colour and size for apparel, colour and shoe size for footwear, capacity and colour for electronics.
• Variant (cell): The sellable unit at the intersection of the axes. Red 38 is a variant with its own SKU, barcode and stock.

The most common design error is storing variant-level data on the parent or the other way round. Colour images belong to the variant; the description belongs to the parent. The barcode is strictly variant level; our GS1 and EAN barcode guide explains why every cell needs its own code.

When a colour-size matrix works, and when it does not

The matrix is ideal for products with two axes. Five colours and six sizes make twenty-four cells, all visible in one table; an empty cell simply means "this combination is not produced".

With three axes the matrix stops being a table. Add fit (slim, regular, relaxed) to colour and size and the cell count quickly passes a hundred. The healthier move is usually to push one axis up to the parent: "Slim fit trousers" and "Relaxed fit trousers" become two models, each with its own colour-size matrix.

For single-axis products (colour only, or capacity only) a flat list is enough, but still build it as parent and variants. Retrofitting a second axis later is expensive.

How marketplaces want variants

Every channel has its own variant model, and that is the real burden of multichannel selling. The typical differences:

• Some channels force colours from a fixed list; if "burgundy" is missing, you end up choosing "red". Keep your own colour name in a separate field.
• Some restrict size values by category and want "Medium" instead of "M" or "38 EU" instead of "38".
• Some merge both axes into one option: "Red / 38" becomes a single choice.
• Image rules vary: one channel wants an image per colour, another applies the parent image to every variant.
• Cross-border channels add size conversion. Selling to the US may require sizes shifted up by one; international size and measurement conversion covers this.

Rather than managing these differences by hand on each channel, keep one internal matrix and define a translation rule per channel. A rule like "Burgundy → Red (Trendyol), Burgundy (Etsy)" is written once and applied to every product.

Step-by-step matrix setup checklist

This list is for teams building the matrix from scratch or bringing order to a messy catalogue.

1. Define the axes. For each category, which attributes create variants? Colour and size, or capacity? Try to keep it to two axes.
2. Build a value dictionary. Colour names and size values come from one list. "Red", "RED" and "red " are not three colours.
3. Write the model code rule. Every parent gets one permanent model code; it is the key for variant grouping on marketplaces.
4. Write the SKU rule. Choose a readable template such as model + colour + size, and allow no exceptions.
5. Assign a barcode to every cell. Leave unproduced combinations empty; never create phantom cells.
6. Attach images to the right level. Colour images to variants, shared images to the parent.
7. Define channel translation rules. Map colours and sizes once per channel.
8. Upload a test model and verify. Push all variants of one model to one channel, confirm the options group correctly on the listing page, then roll out to the rest.

A matrix is only as good as its worst cell. One wrong barcode or missing image in a single cell can make the whole product family problematic on a marketplace.

Common variant mistakes

The issues we see in real operations tend to fall into a few patterns.

• Listing each variant as a separate product. Customers cannot switch between colours, reviews are scattered, and search ranking weakens.
• Deleting a sold-out size. When stock returns, listing history, reviews and ranking are gone. Set stock to zero instead.
• Free-text colour names. The same product ships to three channels under three names and content quality suffers. Product content and quality score shows how such findings are detected and fixed.
• Keeping variant prices on the parent. If larger sizes cost more, price must sit at variant level.
• Changing the model code. Marketplace grouping breaks and variants scatter.
• Entering stock into an empty cell. A combination that is never produced gets sold.

Variants and stock: the living side of the matrix

The matrix is not a static table; every cell's stock changes constantly. Sell-outs happen per cell: black 38 runs out while black 40 sits on the shelf. Low-stock alerts and days-of-cover calculations therefore need to run at variant level; a model-level view says "in stock" while the best-selling size is long gone.

Stock synchronisation must be cell-based too. A black 38 sold on one channel should reduce only black 38 on the others. Stock synchronisation and overselling explains how a single stock pool handles that.

How it works with Bulutegra

Bulutegra reads the parent and variant structure from your ERP or e-commerce platform as it is. In the Match step, each variant is linked to its marketplace listing by SKU and barcode; blank, duplicate or ungrouped variants are collected in one list. Channel translation rules for colours and sizes are defined once and applied across the catalogue. The quality tab surfaces missing colour, title and category findings that you can fix with one click.

Stock and price sync run at variant level: the single stock pool tracks every cell separately, and low-stock alerts and the days-of-cover report arrive per size. The price matrix holds list, sale and floor prices per channel and per variant. For US orders, size conversion is applied automatically according to the product's own size list. The ownership flag shows which channel of a variant is managed by Bulutegra and which by an external system.

To see your own catalogue's matrix in the Integration Panel, request a demo or browse the solutions overview.