How to Group Product Variants Into One Family

A cable gland in five sizes shouldn't be five unrelated catalog entries. Here's how to structure variants so search, filtering, and inventory all make sense.

A cable gland comes in M12, M16, M20, M25, and M32. Each size has its own SKU — correctly, they’re genuinely different products with different part numbers and stock levels. What often goes wrong is treating them as five unrelated catalog entries instead of five variants of one family: search returns five disconnected results instead of one product with a size selector, and nobody browsing the catalog can easily see “this comes in five sizes” without searching for each one separately.

Variants aren’t duplicates, and treating them as either extreme causes problems

This is the inverse of the deduplication problem. Merging real variants into a single SKU is wrong — they have different stock, different prices, sometimes different lead times, and inventory needs to track them separately. But leaving them fully disconnected is also wrong — it breaks the customer’s ability to find “the gland I want, in the size I need” as one browsing decision, and it breaks any reporting that wants to answer “how much of this product line, across sizes, did we sell.”

The right structure is a parent-child relationship: one parent record representing the product family, with child records for each variant carrying their own SKU, price, and stock, linked to attributes that differ (size) and inheriting attributes that don’t (material, IP rating, thread type).

How to build this without a manual pass per family

Identify variant families by shared identity minus one or two distinguishing attributes. If two products share manufacturer, product line, material, and every spec except size, they’re very likely variants of the same family — this is a specific application of entity resolution logic, tuned to detect “almost the same” rather than “exactly the same.”

Confirm the distinguishing attribute is genuinely a variant dimension, not a different product. Size, color, and pack quantity are classic variant dimensions. A different voltage rating on an otherwise identical-looking product usually isn’t a variant — it’s a different product that happens to look similar in a spreadsheet.

Build the parent record with the shared, canonical attributes, and structure children under it with their own identifiers and their own stock/pricing.

What it looks like fixed

Before	After
5 disconnected SKUs, 5 separate search results	1 parent product, size selector, 5 tracked variants
No way to report “total gland sales across sizes”	Parent-level rollup, child-level detail
Manual work to notice they’re related	Detected automatically from shared attributes

Catalog full of unlinked variant families? Book a 30-minute call.

Glossary

What is a canonical product record?

The normalized parent record variant families inherit shared attributes from.

Glossary

What is entity resolution?

The matching logic used to detect records that are nearly the same, or related as variants.

FAQ

How is grouping product variants different from deduplication?

Deduplication merges records that describe the same product into one. Variant grouping links genuinely different products — different SKU, stock, and sometimes price — that belong to the same family under a shared parent, without merging them.

How do you automatically detect that products are variants of the same family?

By identifying products that share nearly all attributes — manufacturer, line, material, and other specs — differing only in a recognized variant dimension like size, color, or pack quantity.