Variants, Attributes, and the Data Model Behind a Clean Catalog

The data model, how you structure products, their variants, and their attributes, is what decides whether your catalog is clean or quietly broken. Two distinctions matter most: a product versus its variants (one t-shirt design versus that design in red, size M), and structured attributes (colour, size, and material as consistent, machine-readable fields) versus the same facts buried in free-text description. Get the model right and search, filtering, recommendations, and channel feeds all work. Get it wrong and no front-end tool can fully rescue it.

This is a core of the Catalog & Product Data pillar, under the cornerstone that product data is the foundation everything runs on. The cornerstone made the case that the data is the foundation. This piece is about the part of the data that's hardest to get right and most decisive when you do: the model underneath it.

The model, not the data, is usually the problem

Here's the thing most people get backwards about messy catalogues. The problem is almost never missing data. The facts are usually all there somewhere. The problem is that they're unstructured: trapped in prose, held inconsistently, or attached to the wrong thing. A catalogue that has every fact but holds them as free text, inconsistently, is nearly as broken as one that's missing facts, because a machine can't use what it can't parse.

So the work isn't usually "go find more product information." It's "structure the information you already have so it can actually be used." That's what the data model is: the structure that turns facts you have into data you can use.

Product versus variant

The first distinction is the relationship between a product and its variants.

A product is the thing in concept, a particular t-shirt design. A variant is a specific buyable version of it, that design in red, size M. Variants share most of their data (the description, the brand, often the images and the story) and differ on a few defined axes (size, colour). Modelling that relationship correctly is the foundation of a clean catalogue, and it goes wrong in both directions:

• Splitting variants into separate products. If "Red M," "Red L," and "Blue M" are three independent products, the catalogue fragments: the same item is scattered across multiple listings, reviews and ratings get split, search shows near-duplicates, and the product page can't offer a clean "pick your size and colour." It's the same product pretending to be many.
• Cramming different products into one. The opposite error, treating genuinely different products as variants of one (a t-shirt and a hoodie as "variants" of a garment), produces a confusing page and breaks filtering, because the things grouped together aren't really the same thing.

The right model is one product with structured variants on clear option axes. One clean page where the customer picks the version they want, and clean data underneath where each variant is a defined combination, not a separate island.

Attributes versus free-text (the big one)

The second distinction does more damage than any other when it's wrong. An attribute is a structured fact, held in a defined field: Colour = Red, Material = Cotton, Sleeve = Long. It's machine-readable, consistent, and queryable. The exact same fact written into the description, "this lovely red cotton tee with long sleeves," reads perfectly to a human and is completely invisible to a machine. Search can't reliably filter on it, a facet can't use it, a channel feed can't map it, an AI can't cleanly extract it.

That leads to one durable rule that governs the whole model: anything you might filter by, search by, recommend by, or feed to a channel must exist as a structured attribute, not just as prose. This is the data-model expression of the merchandising principle that you filter by the customer's decision, the decision can only become a filter if the fact behind it is a structured attribute. The description is for the story; the attributes are for the facts. Confuse the two and you get a catalogue that reads beautifully and can't be searched, filtered, or fed anywhere.

The consistency killer

Having facts as attributes isn't enough; the values have to be consistent, and this is where clean-looking catalogues quietly fall apart. If one product's colour is "Red," another's is "red," a third's is "crimson," and a fourth's is "RED," then your colour filter has four separate buckets for what's really one colour, and none of them is complete. The customer filtering for red sees a fraction of the red products and assumes you don't stock the rest.

The fix is a controlled vocabulary: a defined set of allowed values for each attribute, so "red" is always entered as the same value. It's unglamorous, it's tedious, and it's the difference between a filter that works and a filter that lies. Most filtering problems that look like a tool failure are actually a controlled-vocabulary failure underneath, the same inconsistent-value root showing up as a broken facet.

Granularity, and keeping the tree out of the attributes

Two refinements finish the model.

Granularity: model the axes that matter, not every conceivable property. The variant axes and attributes worth structuring are the ones that drive the customer's decision and the ones the channels require, not every property you can think of. Too few attributes and customers can't filter to what they want; too many and you've buried the useful ones in noise and created a maintenance burden nobody keeps up. More structured data isn't automatically better; the right structured data is.

Keep the category tree and the attributes in their separate jobs. This is the callback to the taxonomy work: the tree is where a product lives (its category), and attributes are what a product is like (its qualities). The classic mistake is smuggling attributes into the tree, a "Sale" category, a "Red" category, a "Summer" category, which bloats the navigation and breaks as products change. In a clean data model, "on sale," "red," and "summer" are attributes you can filter and combine, not fixed places in the tree. The data model is exactly where you enforce that separation.

The payoff for getting all of this right is the one the cornerstone promised: a clean model means search finds the product, facets filter it, recommendations relate it, feeds accept it, the page renders it, and AI can read it, one model, every benefit. And because the model lives in one authoritative place (the single-source-of-truth idea the feeds piece builds on), you fix "crimson" to "Red" once, not in five different channels.

What this comes down to

A clean catalogue isn't about having more product data; it's about structuring the data so machines and customers can both use it. Products and variants modelled in the right relationship. The facts that matter held as consistent, structured attributes rather than buried in prose. The tree and the attributes kept in their separate jobs. Controlled values so a filter tells the truth.

The catalogue mess is almost never a missing-data problem. It's a missing-model problem, the facts are usually there, just trapped where no tool can use them. Get the model right once and every system on top of it works. Get it wrong and you'll spend forever patching symptoms downstream, a broken filter here, a rejected feed there, that all trace back to the same unstructured root.

A few common questions

What is a product data model, in plain terms? The structure that decides how your products, variants, and attributes are organised. Its two most important parts are the product-versus-variant relationship (one design versus its specific buyable versions, like red in size M) and structured attributes versus free text (a fact held in a defined, machine-readable field versus the same fact buried in description prose). A good model turns facts you have into data your systems can actually use.

What's the difference between a product and a variant, and why does it matter? A product is the thing in concept (a t-shirt design); a variant is a specific buyable version (red, size M) that shares most data but differs on defined axes. Modelling it wrong breaks the catalogue: split each variant into a separate product and you fragment listings, duplicate near-identical pages, and split reviews; cram genuinely different products together as "variants" and you get a confusing page and broken filtering. The right model is one product with structured variants on clear axes.

Why shouldn't I just put product details in the description? Because a fact in the description reads to a human but is invisible to a machine, search can't reliably filter on it, a facet can't use it, a channel feed can't map it, and an AI can't cleanly extract it. The durable rule: anything you might filter, search, recommend, or feed by must exist as a structured attribute, not just as prose. The description is for the story; the attributes are for the facts.

Why do my filters show incomplete results even though the data is there? Usually a consistency problem in the attribute values. If colour is entered as "Red," "red," "crimson," and "RED" across different products, the filter has four separate buckets for one colour and none is complete, so a customer filtering for red sees only a fraction. The fix is a controlled vocabulary, a defined set of allowed values per attribute, so the same colour is always the same value. Many "the filter tool is broken" problems are really this underneath.