Product variants in ecommerce: turning a supplier’s rows into one product with sizes and colours

What a variant is, and what a supplier file sends instead

A product variant in ecommerce is one purchasable version of a product that comes in more than one option: the medium navy hoodie, as distinct from the hoodie. Google defines variants as “a group of similar products that only differ from one another by product details such as colour and size for clothing”.¹ Shopify’s model says the same from the store’s side: each variant is a purchasable combination of option values with “its own price, inventory, and barcode”.¹²

Supplier files rarely arrive in that shape. The same hoodie turns up three ways, sometimes in one spreadsheet.

• One row for the product, with every size crammed into a cell: Size “S/M/L/XL”.
• One row per colour with nothing to say they belong together: HD-200, HD-200-BLK and HD200-GRY, the grey one at a higher price.
• A colour column that means one colour and says it three ways: Navy, navy blue, NVY.

The first offers nothing a shopper can buy in size M. The second has rows and no group, so a store makes three hoodies of them. The third puts one colour into a filter three times.

What each platform needs to see

The three platforms describe one shape in three vocabularies: Google groups rows with a shared key, Shopify nests rows under one product, and WooCommerce points child rows at a parent.

Google Merchant Center: one row per variant, one item_group_id

Each variant is submitted as a product of its own, with its own ID and the same item_group_id as its siblings. Google’s example is a T-shirt in three sizes and three colours, sent as “a total of nine separate products” sharing one item group ID.¹ The value is 1 to 50 characters, and the attribute is required for free listings of variants and for Shopping ads on variants in six countries, the United Kingdom among them.¹

The differences travel in standard attributes. Colour [color] takes up to three colours joined by a slash, 100 characters in all, and is required for clothing and accessories; size [size] takes up to 100 characters and is required for clothing and shoes.²³ Two optional attributes refine size: size_type for the cut (regular, petite, plus, tall, big or maternity) and size_system for the country convention, such as UK, EU or US.⁴⁵

In May 2026 Google added variant_option, which lists each property that varies alongside its value: “Shoe width:narrow,size:8” in one CSV cell.²⁶ Every variant in a group must use the same names, in a combination of values no other variant has.⁶ Its own page calls it optional, while the item group ID page lists it among the minimum requirements.⁶¹ Send it: Google says the attribute will be used to show a product with its variants “in conversational AI as well as traditional search experiences”.⁶ Its partner, item_group_title, names the group in up to 150 characters.⁷

Shopify: options and variants under one handle

A Shopify product has up to three options, and each combination of option values can be a variant, up to 2,048 per product.¹⁰ In the product CSV the URL handle is the group, and it is required when you add variants: the first row carries the product’s fields, and each following row repeats the handle, skips Title, Description, Vendor and Tags, and holds one variant’s details.¹¹ An update that touches a variant column, such as SKU, needs Option1 name and Option1 value as well; without them “a new default variant is created and existing variants are deleted”.¹¹

WooCommerce: a variable parent and its variation rows

WooCommerce’s importer reads a Type column: the parent row is variable, each child row is variation, and the child’s Parent column holds the parent’s SKU, or its ID in the form id:100.¹⁴ The parent row lists every value in Attribute 1 value(s), such as “S, M”, and each variation row holds only its own: “A variation needs one value; if you provide more than one, WooCommerce uses the first.”¹⁴ Every variation needs a unique SKU and a price: “Variations without prices don’t show in your store.”¹⁴¹³

What may vary inside a group, and what must not

Each variant has its own identifier, price, stock and image, and a combination of option values no other variant in the group shares.¹²¹³ Google requires a unique ID per variant and recommends a separate landing page URL for each; Shopify will not save “an exact duplicate of another variant that already exists”.¹¹⁰

Everything that holds the group together has to match on every row.

• The group key. Casing does not separate groups: abc123 and ABC123 “are interpreted as the same product”, so ranges whose codes differ only in case merge.¹
• The group title. “All variants of the same product must have the same item group title”.⁷
• The set of properties that vary. If one row names colour and size, every row must. Google flags “Missing colour for product variants” when a product in a group has no colour, and asks for “the same set of variant attributes” across the group.⁸

Some things look like variants and are not.

• A parent SKU. “Don’t submit a parent SKU as a separate product.” It belongs in item_group_id on the variants.¹
• A set. Google’s examples of products that are not variants include “a suit consisting of a jacket and trousers or a set of bath accessories”.¹
• A part that fits many models. Windscreen wipers that fit many cars are submitted once, with the compatibilities listed “in its product description”.⁹

How supplier files break a group

Supplier files break groups in six ways, each visible in a single cell.

• Sizes crammed into a cell. Size “S/M/L/XL” is four variants in one cell, and Google’s size attribute takes one value per product, so a feed reads it as the size of one product.³
• Variants listed as unrelated products. HD-200, HD-200-BLK, HD200-GRY. With no shared key there is no group, and Google has no way to show them “as a group, instead of separately”.¹
• One colour, four spellings. Navy, navy blue, NVY, NAVY. Shopify shows option values to customers as they choose a variant, so the supplier’s spelling is what they read.¹⁰ Google wants the feed to use the landing page’s name for the colour: if the page says “Toasted Walnut”, the feed should not say “Brown”.²
• Option names that drift. Colour, Color, Shade. WooCommerce wants attribute names spelt identically across parent and variations, and Google the same set of names across a group.¹⁴⁶
• Values that are not values. “N/A”, “see image”, “assorted”. Google’s colour attribute rules out “variety”, “men’s”, “women’s”, “N/A” and anything that points at the image; its size attribute rules out “n/a”, “none” and “multi-size”.²³
• Commas where a slash belongs. A two-tone jacket sent as “Navy, White”. If commas separate the colours, Google applies only one; the format is Navy/White.²

Spelling variants multiply options: every spelling of navy is one more choice in the picker for one real colour. Normalising attribute values is how to fold them back.

The same rows before and after

Here is the hoodie from the opening, field by field.

The group key is the supplier’s base code, HD-200, following Google’s best practice of using the parent SKU as the item_group_id and never submitting it as a product.¹ The grey rows keep their higher price, because Shopify and WooCommerce hold price on the variant.¹²¹³ And the group title leaves colour and size to the variant titles: “Don’t include details that only apply to individual variants, for example, size and colour.”⁷

Rebuilding the rows, step by step

This is spreadsheet work: a filter, a formula and a sort at each step.

1. Choose the group key. The supplier’s parent code if there is one, otherwise brand plus model, and never change it once assigned.¹
2. Decide which properties vary. Usually colour and size. Use the same set on every row of the group.
3. Split compound cells into rows. “S/M/L/XL” becomes four rows, each carrying every shared field from the original: three colours in four sizes is twelve rows.
4. Give every row its own identifier. A variant SKU, and a barcode where the supplier gives one per variant; HD-200-NVY-S reads at a glance.
5. Normalise the option values. One spelling per colour, matched to the product page, and one format per size: “S”, “M” and “L”, not “S”, “Medium” and “Lrg”.²³ WooCommerce’s advice for supplier files is the same: “use one capitalization for each value, and map synonyms to one value”.¹⁴
6. Fill each variant’s own fields. Copy shared values down to the size rows, keep a different price only where it belongs, and put each colour’s photo on that colour’s rows.
7. Write the titles. A generic group title, and variant titles with colour and size in them.⁷
8. Shape it for the destination. An item_group_id column for Google; repeated handles with Option1 name and Option1 value for Shopify; a variable parent row, then variation rows with Parent set, for WooCommerce.¹¹¹¹⁴
9. Check the group before export. The same key and option names on every row, no combination twice, no compound cell left, and no parent row sent to Google as a product.

When it is ambiguous

Two questions need an answer before any row is split.

Is it a variant or a different product? Variants differ only by details such as colour and size.¹ Where each version “is considered a different product by design”, Google asks for the difference in the title and description and a GTIN or other unique identifier on each.⁹ A hoodie in grey is a variant; a zip-up version of the same hoodie is a different design.

Is the slash a list or a range? Settle it before the split, because both readings turn up in the same column.

The limits bite at the top end too. Shopify allows 2,048 variants per product but warns that some themes, apps and sales channels “might not support more than 100 variants”.¹⁰ WooCommerce’s dropdowns stop narrowing to the combinations that exist once a product passes 30 variations, a default developers can change.¹³

Where RefynData fits, and what to do next

Variants are one part of turning a supplier’s file into a catalogue; product data enrichment covers the rest, from each product’s identity to its category and images. RefynData’s product data enrichment service handles the value side of this job. It matches each SKU or barcode to the real product, splits compound cells, folds spellings such as NVY and navy blue onto one canonical value, clears non-values such as “N/A”, and finds the full-size original behind a thumbnail. It cross-checks each title against its own specs and flags what does not add up. Every value keeps a link to its source, and a grade per product puts the worst first without blocking the export.

To start, sort the supplier’s file by product name: a product that appears once with a slash in its size cell, or three times under three codes, is a group waiting to be built. Settle the group key and the option set first, then split, normalise and fill in. Do it in the supplier file rather than in the store, so the next delivery maps onto the same groups, for the same reason supplier data onboarding maps each supplier’s columns once. Then run the group check before export, alongside the product data quality checklist.