How to structure product categories so your reports mean something

Most category trees are built to help someone find a product at the till. That is a real need and it is the wrong design brief, because finding things is what the search box is for.

What the tree actually does is decide the shape of every number you will ever look at. Sell-through, margin, stock turn, open-to-buy: all of them group by category, because category is the only field that says what kind of thing a product is. If the tree does not match the way you buy, no report built on it will answer a buying question, however good the underlying data is.

That is the brief to design against. Not can I find this, but would I make a decision about this group as a whole? A category you would never buy for, budget for, or compare against another category is not earning its place in the tree.

This is the question people get wrong in both directions, and the two failures look nothing alike.

Too shallow is one category holding eight hundred products. The report runs, the number is real, and it tells you nothing: a category that mixes everything you sell has an average that describes none of it. Shops in this state usually know it, because they quietly stop opening the reports.

Too deep is sixty categories holding four products each. Every percentage is computed on a handful of sales, so it swings wildly month to month and none of the movement means anything. This failure is the worse of the two because it does not feel like one. The reports look sophisticated. They are noise with decimal places.

The workable level is the one where a category holds enough products that a percentage is stable, and few enough that the products inside it are genuinely comparable to each other. In practice that is the level at which you would make a single buying decision: if you would sit down and set a budget for it, it is a category; if you would not, it is a level too far.

Three levels is enough for most catalogs. Four is occasionally justified. Five is almost always someone using the tree as a filing cabinet.

Some systems allow a product to sit in several categories at once. Use one anyway.

A product in two categories is counted twice in exactly the report the tree exists to produce. Category totals stop summing to the business total, and the discrepancy is invisible because every individual number still looks plausible. Worse, the size of the error is not stable: it depends how many products happen to be multiply filed, which changes every time someone adds stock.

The case that tempts people is the genuinely ambiguous product. A cycling jersey in a bike shop is both apparel and cycling equipment, and both answers are defensible. Pick one, write down why, and apply it to every jersey after it. The consistency matters more than the choice, because a rule you can predict is a rule you can report against, and either answer produces usable numbers as long as it is the only answer.

Almost every overgrown tree comes from one confusion, and it is worth naming precisely. Three different facts about a product belong in three different places, and putting one of them in the wrong place is what produces two hundred categories.

The category is what kind of thing it is. It answers a reporting question, and it should stay true of the product for its whole life.

An attribute is how versions of it differ. Length, finish, size, color execution. These belong on the variant group rather than in the tree, because you want them compared within a family instead of scattered across it.

The name is everything else that identifies it. Model, series, the vendor's own designation.

The tell that this has gone wrong is a tree containing sizes, colors or finishes. A shop with Bolts > 50mm and Bolts > 75mm as separate categories has filed an attribute as a category, and it can no longer answer the only question that level was for: how are bolts doing? The lengths were never meant to be compared against the rest of the catalog. They were meant to be compared against each other.

The distinction is identical everywhere. Only the words change.

Read the middle column as the test. If a fact belongs there and you have put it in the tree, you have a category nobody can report on and a family that has been split. If a fact belongs in the tree and you have put it in the name, you have products no report will ever group together.

Four facts get filed as categories, and every one of them costs the tree the ability to answer the question it exists for.

Brand. The most common by a distance. A tree organized by brand can tell you how one supplier performed but not how outerwear performed, and those are different questions asked by different people at different times. Brand belongs in its own field, where you can filter by it and still report by category.

Season. A date, not a kind of thing. Filing by season puts this year's stock and last year's version of the same product in unrelated places, which removes the comparison you most wanted.

Supplier. A purchasing fact rather than a merchandising one. You buy the same kind of product from several vendors and you should be able to compare them, which a supplier-shaped tree makes impossible.

Price band. Derived, and it moves. A product changes band the moment you discount it, so its history walks between categories on its own.

All four are legitimate things to filter and report by. None of them is what the product is, which is the only job the tree has.

Trees do get rebuilt. Businesses change what they sell, and a structure designed for one range stops describing the next.

What makes a rebuild expensive is that history does not reliably follow. Depending on the system, past transactions either keep the category they were recorded under, which strands last year in a tree that no longer exists, or they inherit the new one, which silently rewrites what last year looked like. Both are defensible behaviors, and both break year-on-year comparison at exactly the moment you want it.

Two things make it survivable. Do it between seasons rather than mid-cycle, so the discontinuity lands on a boundary you already treat as a break. And never bulk-reassign on a rule without reviewing the output: a rule that is right about most products is wrong about some, and the ones it gets wrong are the products that do not fit the pattern, which are disproportionately the interesting ones.

The cheapest version of all of this is getting the depth roughly right at the start, when a change costs renaming a node rather than rewriting a year.