One of the most common questions you encounter when dealing within any e-commerce platform is how variant product  are dealt with. By variants I mean products with options - for example you might have a T-shirt in red, green and blue. This would be a product with 3 options - a variant product.

For the hi-res .psd visit mockupdated.com
Photo by Anomaly / Unsplash

Across e-commerce platforms - broadly speaking there are two ways variant products are dealt with -

  1. A ‘parent child’ relationship - there is one ‘master’ SKU for the parent product - and the ‘child’ products (in this example our red, green and blue T-shirt’s) are items under the parent product with a unique SKU.
  2. A ‘sister’ relationship - products are grouped together - typically by a shared name - and each variant is a product of its own right, grouped under the same umbrella as the other variants. There is no ‘master’ or ‘parent’ product - products are grouped as opposed to sitting under a hierarchy.

This presents a challenge when you look to integrate two systems which take differing approaches to the ‘product variant’ question.

Let’s go back to our T-shirt example - we have it in red, green and blue -

Product Variant SKU
T-Shirt Red T-RED
T-Shirt Green T-GREEN
T-Shirt Blue T-BLUE

These are ‘sister’ products - grouped together but with no ‘master’ SKU or listing. Let’s say this is how we’ll store our product data.

If we’re taking this data and pushing it to a system with the same approach to product variants - there’s not issue. You’d match products based on SKU and update the products accordingly. These updates would be reflected on the listings.

But what if these variants - the different coloured T-shirt’s sit under a ‘parent’ listing. Let’s look at another possible variant structure -

Product Variant SKU
T-Shirt T
T-Shirt Red T-RED
T-Shirt Green T-GREEN
T-Shirt Blue T-BLUE

We’ve got a parent product with not match to our product catalogue.

We have a match to the variants of the product - but not the ‘master’ item - which one might assume holds a culminate stock level, base price etc. which may be presented on the front end.

We could rely on the store to calculate total stock for the parent / master product if the variants / child products are updated - but recent experience tells me this isn’t always the case.

So how do you deal with this problem? And where do we see these difference in the approach to variant items?

’ll let you know if I come up work the perfect answer! Or if you know- get in touch!

Formulas on an old blackboard
Photo by Roman Mager / Unsplash

...Then got the issues associated with multi option variants (i.e a Red T-Shirt in medium) - but those problems tend to fall not on the storefront side - but the system you are trying to connect to. To the problem goes on...!

Update - 23/02 - An old colleague got in touch with some good questions -
Sensible question not covered in my article.
Via Jon Boon - @boomboonpow

A variant product may well exist with multiple 'options' - in our T-Shirt example - perhaps 'color' and 'size'.

Jon - What if you have multiple variants, I.e size and colour?

Same problem arises really regardless of number of options. The aggravating factor being the presence of a ‘parent’ SKU to consider - even if that’s the ‘parent’ of a variant subset.

Jon - How many different sets of variants can you have? Are they still called Variants? Like set 1, set 2 etc?

Depends on the system - in theory with the ‘parent / child’ relationship you can go on pretty much forever but it becomes incredibly complex to manage - via a UI or in bulk. Some systems will limit you to one / two options otherwise the number of possible variants gets nuts!

Thread - Twitter

You can deal with lots and lots of product options with either approach to variant structure - but either way it can quickly come messy and hard to manage. It's doable via a well executed UI - but can become tricky when creating or updating products in bulk with a CSV file or similar.

Lets look at what happens when we add another variant / option to one of our T-Shirts -

Product Variant 1 Variant 2 SKU
T-Shirt Red Small T-RED
T-Shirt Red Medium NEW SKU
T-Shirt Red Large NEW SKU

This is manageable -often a store requirement and it can work well.

Expand this by X variants and you've quickly got a complex product structure to deal with. For each conceivable combinations of the X options - you need to assign a product. Now this is manageable - and I've seen it work - but get beyond maybe 4 options and it becomes a challenge to maintain.

Now of course in some situations a retail is going to demand this approach - it's a request within reason. Personally I tend to question the value in grouping the variants to such a degree - and relying on a great number of simple products.

The question to asks to ask are - do they physically group products in that manner for packing/ shipping purposes and are the products materially different that they should actually be split out. Less variable products can also make to an easy stock count and dispatch process.

If any one else has any further questions - give me a shout!