How to build a product taxonomy that scales

The single most common reason taxonomies collapse under growth is conflating two different things: the category hierarchy (where a product lives in the tree) and its attributes (the structured properties that describe it). When you mix them, every new variation forces a new branch, and the tree explodes.

The rule of thumb: if a property would create a new category for every value, it's an attribute, not a category level.

• Wrong (attributes baked into the tree): Gloves > Nitrile > Blue > Large > Powder-Free. Now add a new color and you've duplicated the whole subtree. Add 'powdered' and you fork it again. At scale this is thousands of near-empty leaf nodes.
• Right (thin tree, rich attributes): Category = Safety > Hand Protection > Disposable Gloves. Attributes = material: nitrile, color: blue, size: L, powder: free. One leaf node, filterable a hundred ways.

The category hierarchy answers what kind of thing is this? Attributes answer what are its specifics? Buyers narrow by category first (browse to disposable gloves), then filter by attribute (nitrile, size L). Your taxonomy should mirror that two-step motion, not flatten it into one giant tree.

Practical test for each candidate level: would a buyer ever browse to it as a destination, or would they only ever use it as a filter? Destinations are categories. Filters are attributes.

Internal taxonomies tend to ossify around how the company thinks: by supplier, by buying department, by warehouse zone, by the order the product lines were acquired. Buyers don't think that way, and search and navigation built on internal logic quietly hides products from the people trying to buy them.

Build the tree around the way buyers search, compare, and decide:

• Group by the job the product does, not who makes it or where it ships from. A contractor looking for a 1/2" copper elbow is in a plumbing-fittings mindset, not a 'Mueller Industries' mindset. Brand is an attribute, not a top-level category.
• Match the granularity of how buyers actually distinguish products. If buyers routinely choose between ball valves and gate valves, those are separate nodes. If a distinction never shows up in how anyone shops, don't model it as a branch.
• Mine your own demand signals before you design. Internal search query logs, zero-result searches, the terms in sales-rep quotes, and the facets buyers click most are the cheapest, truest map of how your buyers carve up the catalog. A spike of where-used or cross-reference searches tells you a category needs a node you don't have.
• Use the words buyers use. If the trade calls it Romex, a node labeled Nonmetallic-Sheathed Cable (Type NM-B) is technically correct and practically invisible. You can make the formal term the node name and carry the colloquial term as a synonym, but don't pretend the buyer's vocabulary doesn't exist.

This is also where build-vs-adopt enters: a public standard (next section) gives you a buyer-neutral skeleton, but the leaf-level granularity still has to reflect your buyers' decisions. Standards get you 80% of the structure; your demand data earns the last 20%.

You almost never want to invent a taxonomy from a blank page. Mature classification standards encode decades of categorization work and — critically — give you a shared language for trading partners, marketplaces, and data exchange. The question is which standard, and how much of it.

The major options, and where each fits:

• GS1 GPC (Global Product Classification) — brick-level codes used in GDSN and retail data pools. Good if you sync to retailers via GDSN.
• UNSPSC — broad, procurement-oriented, eight-digit hierarchy. Common in spend analysis and ERP; serviceable as a backbone, weak on the attribute detail buyers filter on.
• eCl@ss — strong in manufacturing, MRO, and industrial supply, with rich attribute models (especially in Europe).
• ETIM — the de facto standard for electrical, HVAC, plumbing, and building-installation products; defines both classes and the technical attributes per class. If you're in those verticals, this is usually the answer.
• Google Product Taxonomy / schema.org — what you need for paid feeds, Shopping, and AI/answer-engine surfaces. Treat this as a mapping target, not your internal structure.

The pattern that scales: maintain one internal master taxonomy, then map it to each external standard. Don't try to make Google's tree, ETIM, and your merchandising navigation all be the same tree — they have different jobs and different update cycles. Your master taxonomy is the source of truth; the standards are projections of it.

When to extend rather than adopt wholesale: standards lag fast-moving or niche categories, and their leaf nodes are often too coarse for merchandising. The right move is to adopt the standard's upper structure (for interoperability) and add your own deeper leaf nodes and attributes underneath — while keeping the mapping back to the standard code intact so you don't lose interoperability.

A few concrete structural rules separate taxonomies that age well from ones that rot:

1. Make each level MECE — mutually exclusive, collectively exhaustive. Every product has exactly one obvious home at each level, and there's a home for every product. If a SKU could reasonably sit in two sibling nodes, the boundary is wrong and merchandisers and algorithms will classify it inconsistently forever.
2. Keep depth in the 3–5 levels range for most catalogs. Shallower and your leaf nodes are too broad to carry meaningful facets; deeper and buyers get lost and maintenance balloons. Depth should be consistent for similar product types — a catalog where one category is two levels deep and a comparable one is six levels deep signals the tree grew by accident.
3. Watch breadth at each node. A node with 2 children is usually a false split (collapse it); a node with 40 children is a wall the buyer can't scan (add an intermediate level or convert some 'children' to attribute filters). There's no magic number, but if a level can't be skimmed, it's not helping anyone navigate.
4. No orphan or 'Misc' nodes. A Miscellaneous or Other bucket is where discoverability goes to die — it's an admission that the structure doesn't fit, and it only grows. If products keep landing there, you're missing a real node.
5. Avoid single-child chains. A > B > C where B has exactly one child every time is just A > C with extra clicks.
6. Decide your polyhierarchy policy deliberately. A product genuinely living in two places (a heated work glove that is both hand protection and a cold-weather item) is sometimes legitimate. But polyhierarchy multiplies maintenance and breaks the 'one obvious home' principle. The scalable default: single primary category in the master taxonomy, plus attributes/tags that let it surface in multiple browse and filter contexts — rather than literally duplicating the node.

If the category tree is the skeleton, attributes are the muscle — and they're what buyers actually filter on, what feeds require, and what AI search reads. A thin tree with a strong attribute model scales; a deep tree with sloppy attributes does not.

Do this per category (or per standard class, if you're using ETIM/eCl@ss):

• Define a required attribute set per leaf node. Disposable gloves must have material, size, color, powder, and AQL. A pipe fitting must have material, connection type, nominal size, and pressure rating. This is your completeness contract.
• Control the values. Every attribute gets a defined type and, where possible, a controlled vocabulary or allowed-value list. Blue, blue, BLU, and Royal Blue are four values to a filter and one color to a human. Uncontrolled free-text attributes are the silent killer of faceted navigation.
• Standardize units and formats up front. Decide mm vs in, how you express ranges, and whether 1/2" and 0.5 in and DN15 are one normalized value. Mixed units make filters lie.
• Separate marketing attributes from technical/spec attributes. Both matter, but they have different owners, different completeness bars, and different consumers (a spec table vs. a feed vs. a description).
• Map attributes to the channel fields that consume them. Google's feed wants gtin, color, size, material, gender in its shapes; a marketplace wants its own. Your attribute model should make those mappings mechanical, not manual.

The scalability test for attributes: when you add a new product to a leaf node, does the system already know exactly which fields it needs and what values are legal? If yes, enrichment and QA become a coverage problem you can measure. If no, every new SKU is a fresh judgment call.

Taxonomies don't decay because the initial design was bad. They decay because nobody owns them and change is uncontrolled. Governance is the difference between a taxonomy that's still coherent at 200,000 SKUs and one that's been quietly forked into incompatibility.

The minimum viable governance:

• Name an owner (a taxonomy steward or council). One accountable person or small cross-functional group approves new nodes and attribute changes. Without this, every product manager invents their own corner of the tree.
• Write naming conventions down. Singular vs. plural, title case, no ampersands vs. allowed, no abbreviations in node names, how synonyms are recorded. Boring, and it prevents Valves, Valve, and VALVES from coexisting.
• Use stable IDs, not labels, as the key. Every node and attribute gets a permanent internal ID. You will rename Cell Phones to Smartphones someday; if downstream systems keyed off the label, you just broke them. Key off the ID and labels become free to edit.
• Version the taxonomy and treat changes as releases. Merging two nodes, splitting one, or deprecating a category is a migration with a before/after mapping — not an in-place edit. Keep deprecated nodes mapped to their replacements so historical data and old links still resolve.
• Have an intake process for new categories. When a genuinely new product type arrives, there's a defined path: propose, check against existing nodes and the standard, approve, add required attributes, map to channels. Ad-hoc additions are how Misc nodes are born.
• Audit on a cadence. Quarterly, review zero-result searches, nodes with one product, nodes growing past the breadth limit, and attribute null rates. The taxonomy tells you where it's straining if you look.

Your master taxonomy is internal. Every channel — Google, Amazon, a marketplace, a GDSN data pool, a distributor's own punchout — has its own tree and its own required fields, and they all change on their own schedules. Two things have to be true for this to scale.

1. Maintain mappings, not copies. Each external taxonomy is a lookup from your master node to theirs. When Amazon restructures a browse node or Google updates its product taxonomy (it does, periodically), you update one mapping table, not 50,000 product records. Products inherit their channel category from their master node automatically. The day you start hand-categorizing the same product separately for each channel is the day the catalog starts drifting out of sync.

2. Re-classification has to be machine-assisted past a certain catalog size. Mapping a hundred thousand SKUs into the deepest correct node — per channel, and keeping it current as both your tree and theirs change — is more judgment than a team can apply by hand consistently. This is the same problem as initial classification, just recurring. The work is high-volume and rules-plus-judgment: read what a product actually is, place it in the most specific accurate node, fill the required attributes for that node, and re-check when taxonomies shift.

This is exactly where an enrichment layer earns its place. A PIM stores the taxonomy and the attribute schema; it doesn't do the work of classifying every SKU to the deepest correct node per channel, filling the required attributes, scoring completeness, and writing it back. Anglera sits alongside your PIM and does that part — gathering, cleaning, enriching, and classifying every SKU against how buyers actually search, then writing it back to your source of truth — so the taxonomy you designed stays populated and current instead of being correct in theory and half-empty in practice. The taxonomy is the plan; keeping every product correctly placed and fully attributed across channels is the ongoing work.