Plan your data model
Do this before you create anything in the Cockpit. It takes an afternoon and it is the difference between a catalog that scales and one that has to be redone.
Step 1: Pick your three reference products
Do not start from the whole catalog. Pick three products that differ from each other as much as possible: your most complex, your most typical, and your most awkward.
Model those three properly. Whatever structure handles all three will handle most of the rest, and you will find the real edge cases in hours rather than months.
Step 2: Separate facts from prose
Take your existing product descriptions and split every piece of information in them into two piles:
- Facts: thread size, material, weight, voltage, norm, certification. These become attributes, with a type, and usually a restricted list of options.
- Prose: the application note, the selling argument, the "use this when…". This stays free text.
Everything that ends up in the facts pile and is currently buried in a paragraph is a filter you cannot offer today. This step is where most of the value of a PIM project is found.
Step 3: Decide what a buyer filters by
Go through the facts pile and mark the ones a buyer would narrow a search by. Those must be single-select or multi-select attributes with defined options, never free text, because otherwise the filter cannot exist.
Be strict here. "Material" as free text will be entered as V4A, 1.4571,
Edelstahl V4A and Edelstahl (V4A) by four different people, and no amount
of search tuning recovers from that.
Step 4: Group products into families
Now look at which products need which attributes. Products that need the same set of fields belong to the same family.
The test is the attribute set, not the marketing category. If hydraulic and
pneumatic fittings need the same fields with a different value for medium,
that is one family.
Expect ten to fifty families. If you are heading for several hundred, you are almost certainly modelling categories as families; stop and re-read The catalog data model.
Step 5: Find the variant axes
Within each family, ask: does this product exist in several versions that differ only along one or two dimensions, such as size, colour, length or voltage?
If yes, that is a family variant with those dimensions as axes. Decide now what lives on the shared model (description, manufacturer, certificates) and what lives on the variant (SKU, barcode, the size-specific measurements).
Getting this wrong is the single most expensive modelling mistake to correct later, because fixing it means merging products that already have order history.
Step 6: Decide your channels and languages
List the destinations your catalog will be published to and the languages you will serve. Then mark which attributes differ between them.
Be conservative. Every localizable attribute is translation work forever; every scopable attribute multiplies maintenance. See Channels, locales and completeness.
Write it down
Before you build, you should have a one-page table like this:
| Attribute | Type | Group | Options? | Localizable | Scopable | Filterable |
|---|---|---|---|---|---|---|
name | text | Marketing | — | yes | yes | no |
description | textarea | Marketing | — | yes | yes | no |
material | single-select | Technical | 12 options | no | no | yes |
thread_size | single-select | Technical | 24 options | no | no | yes |
pressure_rating | measurement | Technical | bar | no | no | yes |
weight | measurement | Logistics | kg | no | no | no |
manufacturer | reference | Commercial | → Manufacturer | no | no | yes |
…and a list of families with their required attributes and variant axes.
That table is the thing to review with the people who know the products. Reviewing a table takes an hour; reviewing a half-built catalog takes a month.
Next
- Attributes and attribute groups — start building it.