The data model behind a manufacturer’s export catalogue

Every manufacturer catalogue project reaches the same fork in its first week, and the answer determines almost everything that follows: what is a product?

Take a profile made in twenty-seven dimensional sizes. Is that one product with twenty-seven variants, or twenty-seven products? It sounds like a question for the developer. It is not. It decides the URL structure, what appears in a search result, what a filter operates on, what a buyer puts in a sample request, and how the range is counted when someone asks how many products you make.

The two answers and what each costs

Treating the size as a variant gives one page per profile with a size selector. The page accumulates all the search authority for that profile, the range reads as tidy, and adding a size later is a data change rather than a new page. The cost is that a buyer searching for a specific dimension lands on a page where their size is one option among twenty-seven, and has to find it.

Treating each size as its own product gives a page per size. A buyer searching a precise dimension lands exactly on it. The cost is twenty-seven thin pages competing with each other, a catalogue that looks larger than it is, and a maintenance burden every time the range changes.

Neither is correct in the abstract. The right answer follows from how buyers actually search, which the company already knows from its enquiries — and which nobody thinks to ask before building.

Attributes are what filtering runs on

A filter is only as good as the attribute data behind it, and attribute data in most manufacturers is a mess for an ordinary reason: it was recorded by different people, over years, for internal use. The same dimension appears as 14.8, as 14,8, as "14.8 mm" and occasionally as a note in a description field. No interface can filter across that.

So most of the real work in a catalogue project is normalisation — deciding the canonical form of every attribute and rewriting the existing data into it. It is unglamorous and it is where the value is. A clean attribute set makes filtering, comparison, cross-referencing and export to a distributor all possible. A dirty one makes every one of those a manual job forever.

Organise around selection, not around stock codes

Internal product codes encode how a company manufactures and stocks. A specifying engineer thinks in application, system and dimension. These are rarely the same tree, and when a site follows the internal codes the company concludes that buyers do not want to browse — when in fact buyers could not navigate what they were given.

The internal codes should still be present and searchable, because existing customers use them. They should not be the navigation.

Cross-references are the underrated asset

For components, the most valuable thing a manufacturer or distributor can publish is often a cross-reference: this part is equivalent to that competitor part, this bore and rod combination takes this seal kit. It is knowledge the company already has, held informally by experienced staff, and almost nobody publishes it.

It is also defensible in a way that price is not. Anyone can undercut a price. Encoding what your people know about fitment takes years to accumulate and cannot be copied from a listing.

The order of work

• Export whatever product data exists, in whatever state it exists in
• Decide what constitutes a product and what is a variant — with the people who sell it
• Normalise the attributes that will become filters
• Model the tree the way a buyer selects, keeping internal codes searchable
• Add cross-references where the knowledge exists
• Only then design pages

A catalogue built in that order can be redesigned in a week. One built in reverse has to be migrated.