A distributor sends us a category export. It has eight or nine hundred rows. We sort by product count and the bottom third of the tree holds fewer than five items per node. Somewhere near the middle there is a level that exists because the website menu needed a third click. Product taxonomy design is rarely a question of how deep the tree should go. It is a question of which decisions belong to categories and which belong to attributes. Depth is what you notice when that split has gone wrong.
Depth is a symptom, not a decision
Every product taxonomy review starts with the same question from the client. How many levels should we have? It is the wrong question, and answering it directly produces a number that survives about six weeks.
The question that matters is what the discriminator is at each level. A level earns its place when it changes the attribute schema. Move down one node and a different set of attributes becomes mandatory, a different set becomes meaningless. That is a real level.
Here is the counter-case, and it is everywhere in electrical and industrial catalogues. Cable, then Armoured Cable, then SWA, then 3 core, then 2.5mm. Levels four and five are attribute values wearing a category costume. Core count and cross-sectional area are a small integer and a number in square millimetres. Put them in the tree and you get several thousand leaves, each holding one or two products, and no way to filter across them.
Compare that with Hand Tools, then Wrenches, then Torque Wrenches. Each step changes what you need to know. Torque wrenches carry a torque range, an accuracy class, a drive size and a calibration certificate. Adjustable spanners carry none of those. That is a level.
The working rule is short. If the children of a node share one attribute schema and differ only by a value in it, they are not children. They are filters.
The number we check first: products per end node
Pull the tree with a live item count against every node. Sort ascending. The distribution tells you most of what is wrong.
Nodes holding zero products are usually the remains of a range plan that never landed. Or a category built for a supplier who was never signed. Nodes holding one to four products are the over-split tail. They come from copying a supplier’s structure straight into the tree, one branch per brand catalogue.
At the other end, a node with several thousand items is only a problem if the attributes underneath it do not filter. Four thousand fasteners with material, thread, length and head type populated is a good node. Four thousand items in a node called Sundries is not a node at all. It is a queue.
Watch the fan-out too. A node with a single child is always wrong, without exception. A node with sixty children is missing a level above them, or it has become the place where unclassified items go to rest. In our experience a workable end node holds between twenty and a couple of hundred items. Treat that as a smell test, not a target.
How deep the standards actually go
This part surprises people, so it is worth putting the numbers down.
ETIM, the classification standard most European electrical and building suppliers publish against, has exactly two levels. Product groups and product classes, with each class assigned to a single group. Every ounce of discriminating power sits in the features, which are typed as alphanumeric lists, logical yes or no, single numerics, or numeric ranges. Two levels, for the whole of the technical trades.
UNSPSC uses four levels in an eight digit code. Segment, family, class, commodity, with an optional fifth pair of digits for business function. ECLASS also uses four, at two digits each, where the count of trailing zeros tells you which level you are looking at.
So the schemes designed to classify industrial products across entire economies stop at between two and four levels. If your internal tree runs to nine, that is not extra rigour. It is the attribute schema’s job being done by the category tree, badly.
The obvious objection is fair. These are classification schemes, not shop windows, and your website needs more granularity than four levels of UNSPSC. Correct. That granularity comes from facets over attributes, not from more nodes. Which is the whole argument of this piece. Our taxonomy and attribution work spends more time on the attribute layer than on the tree. The tree is the easy half.
Depth versus breadth: what you are actually trading
Every level you add has a running cost. Someone maps each new SKU to it. Someone maps every supplier category to it. Every channel feed needs the mapping. URLs, breadcrumbs, search facets and user permissions all hang off it. Add a level to a fifty thousand line catalogue and you have added fifty thousand decisions.
What depth buys you is precision in attribute scoping. Mandatory rules get tighter. Defaults get better. Enrichment briefs get shorter, because the node already says most of what the item is.
Breadth buys you speed. Fewer decisions per item, faster supplier onboarding, and more of the work carried by attributes and search. It also survives contact with reality better, because suppliers rarely send data at the grain your deepest level expects.
For most distributor catalogues a product taxonomy lands between three and five levels. We go to six only where categories genuinely differ in how they are specified. An electrical range, a PPE range and a fastener range do not need the same depth. Forcing symmetry across them is a common self-inflicted wound.
One asymmetry is worth planning around. A shallow tree with a strong attribute schema is easy to deepen later, because the values you would split on already exist in the data. A deep tree is expensive to flatten, because the split lives only in the node names and you have to reconstruct the attributes from them. When you are genuinely unsure, stay shallow.
When to split a node, and when not to
Four triggers justify splitting a node in a product taxonomy. Anything else is preference.
The attribute schema diverges. An attribute that is mandatory for part of the node is meaningless for the rest. This is the strongest signal there is, and it is the one to test first.
The operational workflow differs. If half the node arrives as structured ETIM data and half arrives as PDF datasheets, those items move through different processes. Splitting them makes the queue manageable even if the products look similar.
The comparison set differs. If no buyer would ever put item A and item B side by side, they are not siblings. This is the test that catches accessories filed next to the products they fit.
The compliance obligation differs. Safety data sheets, battery rules, machinery documentation. When the required evidence changes, the node should change with it.
Now the reasons that look like triggers and are not.
Volume alone is not a reason. Four thousand items in a node is fine when three attributes filter them down to ten. The supplier’s own structure is not a reason, and copying it is how you end up with a brand branch. Merchandising wanting a landing page is not a reason, and the next section deals with that. The ERP doing it that way is not a reason either, because ERP classification is built for stock and finance, not for how someone shops.
There is one more rule that catches more problems than the rest combined. One discriminator per level. Every child of a node must be split on the same axis. When a node’s children read “Cordless Drills, Corded Drills, Makita, Drill Bits”, you are looking at three different axes and an accessory. We find some version of that in almost every tree we review.
Where variants sit in the product taxonomy
Variants do not go in the tree. Colour, size, length, voltage, pack quantity and finish are axes on a product, not nodes above a SKU.
Classification happens at the product, then inherits down to the sellable items. Classify at SKU level and you will eventually file two SKUs of one product into different nodes. Nobody will notice for a year.
The test for whether something is a variant or a separate product is behavioural. Does the buyer land on one page and then choose? Would they search for it by its own name? A 10mm and a 12mm of the same spanner pattern are variants. A torque wrench and a calibrated torque wrench with a certificate are two products, because the certificate changes the buying decision and the price logic.
Some cases stay genuinely awkward. Pack quantity is usually a variant axis. Then the trade pack gets its own GTIN, its own demand pattern and its own promotions, and it starts behaving like a product. Left hand and right hand are variants. Paint colour is a variant axis with thousands of values, which is why paint nodes need their own treatment rather than the standard pattern.
Platform mechanics matter here more than people expect. Akeneo, for instance, separates the two concepts cleanly. A product belongs to exactly one family, which carries its attribute set, and can sit in several categories at once. Family variants declare the levels of variation and the axis at each level. So if the variant axis is inconsistent across products in the same family, the family is wrong, not the tree.
That gives you a practical completion rule. Every end node should name its variant axes. If you cannot say what varies within a node, the node is not finished, and the product attributes underneath it are not either.
Navigation is not your product taxonomy
These are two structures with opposite properties, and merging them is the most expensive mistake in this whole subject.
Classification is single parent, mutually exclusive, exhaustive and slow to change. Every item has exactly one home. It is owned by product data, and its job is to scope attributes, drive validation and support exchange with suppliers and channels.
Navigation is multi parent, deliberately incomplete, seasonal and fast. It is owned by ecommerce and merchandising, and its job is to get someone to a shortlist. There is no reason for those two things to be the same object.
The failure mode is always the same. Merchandising asks for Winter Workwear, or Own Brand, or Clearance. Someone with admin rights adds it to the master tree because that is where categories live. Now the tree carries a campaign axis, mutual exclusivity is gone, and attribute scoping starts producing nonsense because items sit in nodes with incompatible schemas.
The fix is to derive navigation from classification plus attributes. A landing page becomes a saved query: one or more nodes, plus attribute filters, plus brand. It can be created on Monday and deleted on Friday without a data migration. It can also be built by a merchandiser without a change request.
The two structures legitimately diverge on application. Buyers arrive thinking “I need to fix a leaking radiator valve”, not “I need Plumbing, Valves, Radiator Valves”. Application views are real and worth building. Build them as collections over the classification, not as branches inside it.
One last observation, since it explains a lot of over-deep trees. When site search is weak, people compensate by adding levels, because clicking through the menu is the only reliable path to a product. If your tree keeps growing and nobody can explain why, look at your search logs before you look at the taxonomy. This shows up constantly in industrial catalogues where the technical specification carries the real intent.
The awkward cases: kits, cross-category items and services
Kits and assemblies get classified by what the kit does, not by its largest component. A first aid kit is not a bandage. The components belong in a relationship on the product, not in the category tree.
Genuinely cross-category items need one home and several views. A cable gland is an electrical accessory and a fixing. Pick a home for classification, then surface it in both navigation paths. Multi parent classification sounds like the tidy answer and is not, because attribute scoping needs a single answer to the question “what is this”.
Accessories and spares are never siblings of the product they fit. Drill Bits under Drills is the classic version. Accessories belong on their own branch with a fits-with relationship to the parent product, which is also what makes cross-sell work. Vehicle fitment follows the same logic, which is what ACES got right for automotive: application data is a relationship, not a taxonomy.
Services, warranties, delivery charges and hire items need somewhere to live, and it should not be inside the product branches. Give them their own top level branch and keep them out of the attribute rules.
Testing a product taxonomy before you commit
Do not migrate a product taxonomy on the strength of a diagram. Six tests, all runnable against real data in a week.
- The attribute test. For every end node, name three attributes that are mandatory here and meaningless one node across. If you cannot, merge the nodes.
- The sibling test. Read a node’s children out loud. Same axis, same grain? Mixed axes are the most common defect and the cheapest to fix on paper.
- The distribution test. Item counts per node, sorted both ways. Read the tails, not the average.
- The stranger test. Hand a buyer twenty real products and the tree with no training, and ask them to file each one. Where two people disagree, your mapping will disagree too, at volume.
- The supplier test. Take your five largest suppliers’ own category structures and map them across. A supplier category that fragments across many of your nodes is a mapping cost you should price before go-live.
- The delete test. Remove a level and see what breaks. If the only casualty is the menu, that level was navigation all along.
Run these before the migration and the findings are edits. Run them after and they are a project. We go deeper on the classification side in our piece on B2B product classification. Sector specifics for regulated ranges sit on the electrical page.
Key takeaways
- A level is justified when the attribute schema changes, not when the menu needs another click.
- ETIM uses two levels and UNSPSC and ECLASS use four. Nine levels is not rigour, it is displaced attribute work.
- Three to five levels covers most distributor catalogues. Stay shallow when unsure, because shallow trees are cheap to deepen.
- Split on schema divergence, workflow, comparison set or compliance. Never on volume, supplier structure or a campaign.
- Variants are axes on a product, never nodes. Every end node should be able to name its variant axes.
- Classification and navigation are different structures. Derive navigation from the product taxonomy plus attributes.
If your tree has grown past the point where anyone can defend it, the fix is usually smaller than the fear. We run taxonomy reviews as a fixed scope exercise against your live export, and you get the node-level findings with a rebuild sequence. Thirty minutes is enough to work out whether it is worth doing. Get in touch. Or read how we approach taxonomy and attribution if you want the shape of the work first.