Building a hierarchy that scales How to set it up and what to consider
By Elias Gröndal, Founder & CEO at Resourced. Updated .
What the tree is for
The hierarchy classifies products so they can be counted, planned and found. It can be the reporting axis, and it is easier if it is, but a budget tree can differ from a sales tree. If you need a second one, map it from the first rather than classifying twice.
It tends to stay constant, so things get built on it: reports, shop navigation, ERP groups, automations. That is why it is worth a little thought up front. Changing it later is possible; it just takes consideration of what hangs off it.
A useful test: list the questions your buying and planning meetings ask, and see which the tree answers by grouping alone.
As many levels as the range needs
Three levels is the most common shape. Four tends to appear in bigger groups, around €50m of turnover or a very wide catalogue, and it takes about that scale to carry that many products. The example runs to four on one branch so the type level can be seen.
A level has earned its place when somebody can name the question it answers, and two people who have never met would file the same article there and agree. A node with too few articles is a sign you can remove it.
Depth costs more than breadth
A new category is one decision. A new level is a decision on every article from now on. The sequence is always the same.
Padded against shell is a real distinction, but padding is a property of a jacket. In the tree it needs one answer per article. As a tag it costs nothing.
A shallow tree you are sure of beats a deep one you guessed at.
One article, one place
If an article fits two categories, the fault is in the tree, not in the person filing it. Two answers look reasonable at the time, and both cost more than they seem.
Leave it to whoever files it
Two people file the same kind of article in two different places. The tree then records who created each article rather than what it is, and every report by category is quietly wrong, with nothing in the numbers to show it.
Add a level to hold the difference
Every article from now on needs one more decision, to settle a case that came up once.
Recommendation: merge the two categories if the difference has no significance to the business as a whole. Or keep one and move the difference into a tag.
What is a level, and what is a tag
A level is a place. A tag is a property. An article has one place and many properties, so anything that can be true alongside something else is ideally a tag.
Season, collection, fit, fabric, a claim, carryover, and usually gender: ideally all tags. A report that splits by a tag is the same report, without the tree changing shape.
Here is a slice of the Resourced Hydro range drawn out to product level. Some branches need a type, some stop at the category. The dots under each name are the tags found beneath it, grouped by what they describe. Pick one and watch the routes light.
- Apparel
- Outerwear
- Jackets
- Puffer
- Aero Puffer
- Outdoor Puffer Vest
- Fleece
- Explorer Fleece Jacket
- Plaid Fleece Jacket
- Puffer
- Coats
- Outdoor Parka Jacket
- Wool Coat
- Jackets
- Knitwear
- Aero High Neck Knit
- Cream Knit Sweater
- Knitted Overshirt
- Sweats
- Hydration Hoodie
- Basic Hoodie
- Fleece Half-Zip Sweatshirt
- Outerwear
- Footwear
- Sneakers
- Aero Trek
- Court Sneaker
- Explorer Marathon 1
- Boots
- Wintex Boots
- Tjakke II Trekking Boot Mid
- Sneakers
- Accessories
- Bags
- Aero Backpack
- Aero Cross Body Bag
- Aero Travel Bag
- Hats & Caps
- Explorer Bucket Hat
- Explorer Cap
- Bags
Twenty-two products from the Resourced Hydro range, each in exactly one place. Some branches stop at the category, some run to a type: as many levels as each needs. The dots are the tags found beneath a node, grouped by what they describe.
The article’s own example. Four products in two divisions, a vest and a pair of boots among them. As a level it would need a node under each, and a ruling on every lightly padded shell. As a tag it is a tick.
Six products in three divisions, boots and bags among them. A level would have to hold a boot and a backpack in one place, or hold waterproof twice.
Six products in two divisions, and the tree did not move. An organic knit is a knit that happens to be organic.
Eight products in three divisions. A claim about the material, not a place for the product.
Seven products carried over. Next season it is a different seven, and the tree has not moved. A status a product passes through cannot be a place it lives.
Six products never out of stock, across three divisions. The same point from the other side: the status is stable, but it is still a status.
Nine products new this season. By next season they are carryover or gone. Filed as a level, every one of them would have to move house.
Six products in three divisions, sharing their nodes with men’s and unisex products throughout. As a level, every one of those nodes would split.
Seven products in two divisions, beside the women’s and unisex products in the same nodes. The gender travels with the product.
Nine products across three divisions at once. As a level, each would need a home that does not exist, or two that do, and every one would be counted twice in a report.
If two answers can be true at once, you are looking at a tag wearing a level’s clothes.
The exception is division. It could be a tag, but the business already runs on it: separate budgets, separate buyers, separate meetings. That is what earns a level: the organisation already treats the distinction as one.
A second hierarchy, without a second classification
Budgeting, follow-up or a legacy system may need a tree of its own. That does not mean classifying every article twice. A mapping table derives the second code from the first: each combination of product hierarchy and tags points at one budget code, and the article gets it in the background the moment it is classified. The highlighted part is where a tag does the work.
In Resourced the mapping is a lookup table feeding a calculated field. An article is classified once in the product hierarchy, and the budget code appears on it, worked out from the hierarchy and whatever tags the lookup needs. Change the mapping and every article follows.
Moving things later
Changing a hierarchy is possible. Adding a node is easy. Reclassifying products is possible: they keep their numbers and their history and take a new place. A completely new structure takes more effort, because reports and automations hang off the old one, but it is still possible.
The biggest change is usually the organisational one, and it runs both ways. A reorganisation may be why the tree changes. Or thinking about the tree may be what shows that the business would be better organised another way.
Keeping the category out of the article number is what makes reclassifying cheap. More on article numbers
Questions this usually raises
How many levels should a product hierarchy have?
As many as the range needs and no more. A level earns its place when every branch needs it and two strangers would file the same article there and agree. Too few articles on a node is the sign it can go; a branch can stop early while another runs deeper.
When is something a level and when is it a tag?
Anything that can be true alongside something else is a tag: season, fit, fabric, a claim, gender. A level is a place an article can be in only once. If an article fits two places, the fault is in the tree, not in the person filing it: merge the two categories if the difference is not significant to the business as a whole, or keep one and move the difference into a tag.
Can we have a second hierarchy for reporting or the webshop?
Yes, but not as a second tree to maintain. Keep one operational hierarchy and map its nodes to the second structure with a mapping table, so budget, sales and planning read the same products grouped differently without anyone filing twice.
What happens when a product moves to another category?
The product moves and its history goes with it. Nothing else should have to change, which is one more reason the article number must not encode the category. What does need consideration is whatever is tied to the tree downstream: shop navigation, ERP groups, analytics and automations.
How is the hierarchy set up in Resourced?
As one tree per brand, as deep as the brand decides, with tags for everything that is a property rather than a place. Statuses, size systems, default units and number templates can hang from a node, so the tree does real work, and a mapping to a second structure is a table rather than a copy.
Before you draw it
Half an hour with the people who read the reports beats a week of tidying afterwards.
- What questions do the buying and planning meetings ask? Which does the tree answer by grouping alone?
- For every level: would two strangers file the same article there and agree?
- For every node: does it hold enough articles to be worth its own line?
- Which levels are really properties (season, fit, fabric, a claim, gender) and should be tags?
- Does one tree serve budget, sales and planning? If not, can the second be mapped from the first?
- What is tied to the tree downstream: shop navigation, ERP groups, analytics, automations?
A tree you are sure of is easy to build on. One you guessed at gets argued every season.