Product variants: managing sizes, colours and packaging in a PIM

Sizes, colours, packaging, strengths — product variants are one of the most complex aspects of catalogue management. A data model that is poorly designed from the outset leads to errors, duplicates and unusable exports. Here’s how to decide what counts as a variant, how to structure the hierarchy, and how Pixee PIM projects it onto each sales channel.

The problem with variants without a PIM

Without a clear structure, variants create two opposing problems for retailers:

• Catalogue explosion — every combination (red T-shirt XL, red T-shirt L, blue T-shirt XL…) becomes a separate record, with no links between them. The result: thousands of duplicate records with the same descriptions and the same images.
• Loss of information — conversely, everything is grouped into a single listing with a generic description that makes it impossible to distinguish between variants.

In both cases, the customer experience across sales channels is compromised, and the catalogue teams spend a considerable amount of time making manual corrections.

Variant or distinct product: the decision rule

The question comes before the data model, and it is the one that gets settled badly. Two items are variants of each other only if the buyer considers them the same product and is choosing between predefined characteristics. Three simple tests cover almost every case.

1. Does one description hold for both? If the marketing copy has to be rewritten for the second reference, it is not a variant but another product.
2. Is the regulatory data identical? A professional version certified differently from the consumer version does not belong under the same parent, however similar the product looks.
3. Would the buyer land on the same page? If so, the variant helps; if not, it dilutes the record and penalises both references.

On identifiers, the GS1 GTIN allocation rules assign a distinct identifier to every consumer unit that differs by a predefined characteristic — declared net content, brand, functional characteristics. In practice, two variants sold separately do not share a code. Validating those codes is the job of the EAN Manager module.

The product/variant model in Pixee PIM

Pixee PIM uses a two-level hierarchical model:

• Parent product — attributes common to all variants: brand, category, generic description, shared images, shared technical attributes
• Variants (SKUs) — the attributes that differentiate the variants: size, colour, capacity, weight, packaging, a specific EAN, price, stock

A parent product can have N variants. Each variant inherits the parent’s attributes and overrides only what is different.

Variation axes: configure your model

Variation axes can be configured by product category. Common examples:

• Clothing / Fashion: Size (XS, S, M, L, XL, XXL) × Colour
• Electronics: Capacity (64 GB, 128 GB, 256 GB) × Colour
• Tools: Power (500W, 750W, 1000W) × Voltage (110V, 230V)
• Food / Household: Capacity (250ml, 500ml, 1L, 5L)
• Spare parts: Manufacturer’s part number × Model compatibility

You define your axes according to your sector — Pixee PIM does not limit the number of axes or values per axis. One piece of advice holds across sectors, though: an axis must carry a closed, reusable value. “Size” is an axis; “supplier comment” is not. As soon as an axis value is typed freely, grouping breaks on the first import and exports to channels become unpredictable.

The sparse matrix: not every combination exists

Six sizes and twelve colours do not make seventy-two references: they make the number of combinations the supplier actually produces, often far fewer. This is the most expensive mistake in the variant model, because it is invisible at the start and gets paid for everywhere afterwards.

A catalogue that generates the full cartesian product exposes references that never existed. Sales channels publish them, customers land on dead pages, completeness scores collapse since those ghosts have neither EAN nor image, and teams spend their time deactivating by hand what the model created on its own. The rule is simple: variants are declared from what the supplier delivers — one row received, one variant — never by expanding axes.

A corollary to hold in the data model: “does not exist”, “out of stock” and “discontinued” are three different states. The first must never become a record; the second stays published with zero stock; the third is deactivated while keeping its history. Confusing them produces either empty pages or references that vanish without trace.

Supplier import: how variants are detected

Your suppliers often send you CSV files with one EAN per SKU, without any indication of variants. Pixee PIM detects and groups variants in three ways:

• By parent product code — if the supplier provides a reference without variations, SKUs sharing this code are grouped
• By grouping rules — you define rules based on common attributes (same brand + same model reference + different colour/size = variants of the same product)
• Manually — for ambiguous cases, the interface allows you to merge or split products from the catalogue view

One point is worth settling before the first import: what should happen to a variant that arrives with no identifiable parent? Letting it in as a standalone product pollutes the catalogue for good, because nobody will come back to attach it. Putting it into an anomaly list, with the candidate parents, costs a few minutes per batch and avoids months of cleanup.

Inheritance and attribute overriding

One of the key strengths of the Pixee PIM model is its handling of inheritance. Basic rule:

• If a variant has no value for an attribute, it inherits the value from the parent product
• If a variant has its own value, it overrides the parent’s value for that attribute only

Practical example: you update the marketing description of the parent product — all variants immediately see the new description, without having to modify each SKU individually.

The trap with inheritance lies elsewhere, and it is silent. An import that dutifully copies the parent’s description onto each variant turns living inheritance into thirty frozen copies: the next update to the parent will no longer propagate, and nobody will understand why. A well-configured import writes at the right level — shared attributes on the parent, only the differentiating ones on the variants. That is the exact counterpart of the previous rule: what is inherited must not be written.

One last subtlety: returning to inheritance after an override is an explicit action, not an empty value. Clearing a field on a variant may mean “this product does not have this characteristic” or “take the parent’s”; the model must tell the two apart, otherwise a typo correction reintroduces a value you had just deliberately removed.

Variants and sales channels

Each sales channel has its own way of displaying variants:

• Shopify — product options (up to 3 dimensions), native variants with images per variant; the synchronisation detail is in our article on Shopify and PIM
• Amazon — Parent/Child ASINs, each variant is a child ASIN attached to a parent ASIN under a declared variation theme; the mechanics are detailed in our article on the Amazon SP-API
• Fnac / Cdiscount — product_family model with variation attributes defined by the marketplace
• WooCommerce / PrestaShop — variable products with native variation attributes; the mapping is detailed in our article on PrestaShop combinations

Each channel’s connector handles the transformation of the PIM model into the expected format. Two constraints show up everywhere: the number of axes accepted is capped on the channel side, and the axis declared when a record is created is generally no longer editable afterwards. That means an internal model richer than the channel has to decide what it projects — for instance by promoting a weakly discriminating third axis to a plain attribute — and that this choice is made before the first publication, not after.

Images per variant

Pixee PIM includes an Asset Library (DAM) module to manage images by variant. You can associate specific images with a variant (photo of the T-shirt in red, another photo in blue) whilst sharing generic images (back view, fabric detail) at the parent product level.

When pushing to channels, each image is sent to the correct level — variant image vs product image — according to the target platform’s rules. The question to settle is the default: when a variant has no image of its own, should the parent’s image be pushed, or nothing? Publishing a red photo on the blue variant costs more in returns than a record without a visual, so the answer depends on the axis: generally no on colour, yes on size.

Variants and completeness: measuring at the right level

A completeness indicator calculated on parent products alone shows a healthy catalogue while half the SKUs are not publishable. It is mechanical: the missing attributes sit exactly where inheritance does not apply — EAN, dimensions, specific image, price. The score must therefore be read at both levels, and the publication rule applied at SKU level.

The practical consequence is that a parent can be distributable with only some of its variants, the others staying on hold. That is preferable to the alternative — blocking the whole parent, or publishing incomplete variants. Configuring thresholds per channel is covered in our article on the completeness score.

Typical scenario: a textile distributor

Example modelled on observed configurations; the orders of magnitude are not a commitment. A textile distributor receiving a weekly file with one row per SKU and an average of eight variants per model typically configures:

• automatic grouping into parent products by model reference, with rows that have no identifiable parent going to an anomaly list rather than becoming standalone products
• a description written or enriched once at parent level, inherited by every variant — and never copied back down by the import
• price and stock updated per SKU on every import, then synchronised to the channels
• a completeness threshold evaluated at SKU level, letting complete variants through and holding back the others

Frequently asked questions

How many variation axes should you plan for?

As few as possible, and never more than your channels accept. A weakly discriminating third axis is better turned into a plain attribute: it stays visible, it does not multiply combinations, and it does not block publication on platforms limited to two or three dimensions.

Do you need one EAN per variant?

Yes in almost every case. The GS1 rules assign a distinct identifier to each consumer unit that differs by a predefined characteristic, and marketplaces as well as retailers require that identifier at the level of the SKU being sold. A variant without a code is a variant that cannot be published: better to hold it as an anomaly than to let it go out with the parent’s code.

How should you handle a variant discontinued by the supplier?

By deactivating it, not by deleting it. Deletion loses the sales history, the inbound links and the code mappings on the channels, which will resurface on the next import. A deactivated variant stays attached to its parent, stops being distributed, and can be reactivated if the reference comes back.

Can you change a variation axis after going live?

On the PIM side, yes; on the channel side, rarely. Most platforms freeze the variation structure when the record is created and afterwards accept only changes of values, not of axes. In practice, changing an axis means recreating the records on the channel — so losing seniority and customer reviews. That is why the variation model is decided before the first publication.