Ask anyone who has replatformed a catalogue what went wrong and you will not hear about the platform. You will hear that the colour attribute was free text, that variants were modelled as separate products, that dimensions were stored as a string with the unit in it, and that by the end nobody could write a query that returned a reliable answer.
None of those are platform problems. They are modelling decisions, made early, cheaply, by someone under time pressure.
Short answer: four decisions determine whether a product model survives. Whether attributes are typed, how variants relate to their parent, which fields are localisable, and whether the model is enforced or merely documented. Everything else can be changed later. These four get baked into every downstream integration within about six months.
Decision one: type every attribute, including the ones that look like text
An attribute has a type, a unit where relevant, and a vocabulary where the values are drawn from a set. Free text is a type of last resort, not a default.
The test is whether you will ever want to filter, convert, validate or compare on the field. If yes, it is not text. If you want a public reference point for what a minimally typed product record looks like, the Product schema and its Offer companion are a reasonable floor rather than a ceiling.
- Number with a unit. Store
weight: 2.4andweight_unit: kgas separate typed values, never"2.4 kg". The moment a market wants pounds you will thank yourself, and the moment a marketplace requires grams you will not have to write a parser. - Enumeration. Colour, material, closure type, certification. Draw from a list. The list can be extended; free text cannot be un-extended.
- Boolean.
dishwasher_safe: true, not a text field containing “yes”, “Yes”, “y” and “safe for dishwasher”. - Date. Launch date, discontinuation date, certification expiry. Dates as strings sort alphabetically, which is a bug waiting for a locale change.
- Reference. A link to another record, whether that is a category, a related product or an asset identifier. Never a copy of the other record’s fields.
The cost of typing late is not the schema change. It is the cleanup pass over existing values, which is manual, and which nobody will fund.
Decision two: variants are children, not siblings
This is the modelling error that causes the most rework, and it is invisible for the first year.
A t-shirt in six colours and five sizes is one product with thirty variants. It is not thirty products, and it is not one product with a text field containing a size list. The distinction matters because the shared attributes have to live in exactly one place.
The workable structure has three levels: a family that defines which attributes exist, a product that carries the values shared across all its variants, and a variant that carries only the values that differ. Fabric composition sits on the product. Size and colour sit on the variant. Price may sit on either, depending on your business, and if you cannot say which, that is worth resolving before you build anything.
Model variants as separate products and every shared attribute gets copied thirty times, which means it gets updated in twenty-nine places and missed in one. Attributes, variants and the SKU problem goes through the combinatorics and the two cases where flattening genuinely is correct.
Decision three: decide what is localisable, and be stingy
Every attribute is either global or per-market. Choosing badly in either direction hurts.
Mark everything localisable and you multiply your empty cells by the number of markets, and your completeness reporting becomes noise. Mark nothing localisable and you will be doing a schema migration during a market launch, which is the worst possible time.
The rule that holds up: an attribute is localisable if its value legitimately differs by market, not if its presentation does. Net weight is global; the fact that one market displays it in pounds is a presentation concern and belongs in the channel mapping, not in the data. Colour is global; the colour name is localisable, because “taupe” is not a word in every market. Marketing copy is localisable by definition. Regulatory fields are localisable and are usually forgotten until the first compliance review.
A useful discipline is to keep a fourth category: attributes that are global today but have a plausible market-specific future. Do not localise them, but do note them, so that the eventual change is a decision rather than a discovery.
Decision four: enforce it, or accept that it is fiction
A schema that is documented but not enforced describes what people intended, not what is in the database. After a year those two things have very little in common.
Enforcement means the system rejects a value that is not in the vocabulary, refuses to save a required field as empty, and blocks publication to a channel whose rules are not met. It has to happen at write time. Validation reports that run nightly are a way of measuring how bad it got, not of preventing it.
This is also the honest argument for a dedicated system over a spreadsheet, and it is a narrower argument than the category marketing makes. A spreadsheet can hold a good model. It cannot enforce one. If your model is enforced by convention and a shared understanding among three people, it will survive exactly as long as those three people do.
Taxonomy, which is a separate thing from attributes
Categories answer “where does this sit in a browsable hierarchy”. Attributes answer “what is true about this”. Teams routinely encode attributes into the category tree and end up with branches like Furniture > Chairs > Blue Chairs > Blue Oak Chairs, which cannot be maintained and cannot be filtered.
Keep the taxonomy) shallow and about kind, not about properties. Four levels is usually plenty. Everything that feels like it needs a fifth level is an attribute wearing a category costume, and it should be filterable rather than navigable.
Expect to maintain more than one taxonomy, because your browse structure and a marketplace’s required category codes will never be the same tree. The mapping problem is old enough to have its own standards work, and the GS1 global data synchronisation network exists largely because two trading partners never agree on one tree. Map between them explicitly rather than trying to satisfy both with one hierarchy.
What should you model before choosing a platform?
All four decisions above, on paper, against a real sample of your catalogue. Pick the twenty products that are most awkward, not the twenty that are easiest, and write out their full records by hand. The awkward ones are where the model breaks, and finding that in a document costs an afternoon rather than a quarter.
Then check the platform against your model rather than the other way round. A tool that cannot express your variant structure will make you flatten it, and the flattening will be permanent. The API-level questions to ask are in what to demand from a PIM API before you buy.
The model also has to agree with whatever holds your images, because the association between the two is itself a modelled relationship. That boundary is set out in DAM vs PIM, and the discipline that keeps it stable is in single source of truth applied to product data. If you are still deciding whether you need a dedicated system at all, what a PIM actually does is the honest version of the pitch.