A buyer choosing between three products opens three tabs. If your specification is written differently from the other two, they cannot compare, and the cognitive cost of working it out usually resolves in favour of whoever made it easy.
Comparable specifications require three things: consistent naming, consistent units, and structure. None is difficult, and all three decay without deliberate maintenance.
Consistent naming
The same attribute must have the same name everywhere it appears. This sounds trivial and is the most commonly violated rule in technical catalogues, because attribute names are usually copied from whatever the supplier called them — and every supplier calls them something different.
| What suppliers write | What it should be |
|---|---|
| Input V / Supply voltage / Voltage in / U-in | Supply voltage |
| IP / Ingress protection / Protection class | IP rating |
| Op. temp / Working temperature / T-amb | Operating temperature |
| Dims / Size / L×W×H | Dimensions (L × W × H) |
Build the canonical list once per category and map supplier names onto it during import. The mapping is a small piece of configuration per supplier; the alternative is a catalogue where filtering can never work.
Consistent units and precision
Three rules cover most of it.
Pick one unit per attribute and convert on import. If some products list millimetres and others centimetres, sorting and filtering are meaningless. Convert at the point of entry, not at display time.
Put the unit in the attribute name, not in every value. "Supply voltage (V)" with a value of "24" beats "Supply voltage" with a value of "24V", because the second cannot be sorted numerically or filtered by range.
Match the supplier's precision, do not invent it. If the manufacturer publishes 1.5 kW, do not store 1.500 kW. Implied precision is a quiet form of inaccuracy, and in technical sales it costs credibility.
Structure: the single most valuable change
The difference between a specification stored as text and one stored as structured fields is the difference between a catalogue you can search and one you can only read.
Stored as text — "24V DC, 10A, DIN rail mount, IP20" — the information is visible to a human and invisible to your storefront. You cannot filter to products between 20 and 30 volts. You cannot sort by current. You cannot show a comparison table.
Stored as fields, each of those becomes a filter, a sort and a facet. The work is the same at entry; the capability afterwards is completely different.
- Numeric attributes stored as numbers, with the unit in the label
- Enumerated attributes (mounting type, material) stored as a controlled list, not free text
- Ranges stored as two fields — minimum and maximum — not as "‑20 to +60"
- Tolerances stored separately from nominal values
Handling ranges and tolerances
Two cases cause most of the difficulty.
Ranges. An operating temperature of −20 °C to +60 °C is two numbers. Stored as one text field it cannot answer "will this work at −15 °C". Stored as minimum and maximum, it can.
Tolerances. A 100 Ω resistor at ±1 % is a nominal value and a tolerance. Buyers filter on the nominal and qualify on the tolerance, so they are different fields with different jobs.
Migrating existing free text
If you already have thousands of products with specifications as prose, the migration is real work but it is tractable, and it does not have to be done all at once.
- 01Pick the single category with the most revenue.
- 02Define the canonical attribute list for it — usually six to twelve fields.
- 03Parse what you can automatically; most specification text is more regular than it looks.
- 04Review the exceptions by hand. Expect 10 to 20 percent.
- 05Turn on filtering for that category and measure whether it changes anything.
- 06Only then do the next category.
Do one category properly and measure the result before committing to the whole catalogue. If filtering does not move anything in your best category, it will not move anything in the others either — and that is worth knowing before you spend a quarter on it.
Common questions
- Why should product specifications be stored as fields rather than text?
- Because text is visible to a human and invisible to your storefront. Stored as '24V DC, 10A, DIN rail mount, IP20' you cannot filter to products between 20 and 30 volts, cannot sort by current and cannot build a comparison table. Stored as fields, each of those becomes a filter, a sort and a facet. The work at entry is the same.
- How should units be stored in a product specification?
- Pick one unit per attribute and convert on import rather than at display time, and put the unit in the attribute label rather than in every value. Mixed millimetres and centimetres in the same field make sorting and filtering meaningless.
- How do you migrate specifications that are already written as prose?
- One category at a time. Pick the category with the most revenue, define its canonical attribute list — usually six to twelve fields — parse what you can automatically, review the exceptions by hand and expect 10 to 20 percent, then turn on filtering and measure the result before starting the next category.
Where to next
Who wrote this
The Smart Station team
Written by the engineering and delivery team at Smart Station (Pty) Ltd, the South African software company that builds GetShopSync. The material here comes from building catalogue systems for distributors — it is what we have measured and what we have got wrong, not a survey of the literature.