Ask a shopper to find a plant-based protein and they think in goals and forms — protein, powder, vegan. Ask a vendor and they think in the categories their shop happens to use. A product taxonomy is the translation layer between those two, and on a multi-vendor marketplace it is the difference between a catalog you can browse and a pile you can only search. Design it for the shopper who has never heard of your vendors, fill it with an AI classifier, and — the part everyone underestimates — plan to redo it regularly. Here is how.
Why vendor-first trees fail shoppers
The tempting shortcut is to adopt your vendors' own categories. It fails immediately at multi-vendor scale, because every vendor built their tree for their shop in isolation. One vendor files a recovery amino under "recovery", another under "amino acids", a third under "sports nutrition > other". Reuse all three and your marketplace has three shelves for one concept, none of them complete, and a shopper who clicks "recovery" sees a third of what you actually stock.
A marketplace needs one coherent tree that a newcomer can navigate without knowing which vendor sells what. That tree is a design artifact you own, not a union of the trees you ingested. The vendor categories become inputs to classification, not the classification itself. The symptom of getting this wrong is measurable, not aesthetic: incoherent categories show up as a high share of products landing in "other", as facets that return implausibly few results, and as shoppers who search for what they could not find by browsing.
Four dimensions: department, activity, type, use case
A single hierarchy cannot capture how differently people shop, so model the catalog along a few orthogonal dimensions and let facets combine them. Four carry most catalogs a long way:
| Dimension | Answers | Example values |
|---|---|---|
| Department | What broad area is this? | Nutrition, equipment, apparel, recovery |
| Activity | What is it for doing? | Strength, endurance, mobility, combat sports |
| Product type | What literally is it? | Protein powder, resistance band, foam roller |
| Use case | What goal does it serve? | Muscle gain, weight management, joint support |
Modelling these separately means a shopper can arrive from any of them — browse the "endurance" activity, filter to the "gels" type, narrow by a "long-ride" use case — and the same product appears wherever it honestly belongs. It also feeds faceted navigation directly, because a well-designed dimension is a facet in waiting, a point we develop in faceted navigation that converts.
AI classification into a human-designed tree
Designing the tree is human work; placing thousands of products into it is not. The pattern that works is a strict division of labour: a human designs the taxonomy for shoppers, and an AI classifier maps each product into it — never the reverse. Letting a model invent the tree produces categories that fit the data and confuse the shopper; letting it populate a tree you designed produces coverage at a speed no human can match.
Give the classifier the enriched product — normalised type, parsed attributes, ingredient list — not the raw feed, so it classifies clean signal rather than the defects covered in product data quality. And keep it honest with confidence: a low-confidence placement is a candidate for review, not a fact. This is the same discipline that governs product structured data for search engines, where the schema.org Product vocabulary rewards precise, consistent categorisation.
Watch the boundary cases, because they are where a classifier quietly fails. A product that could sit in two departments — a protein bar is both nutrition and a snack — needs a tie-break rule, and a genuinely novel product type needs an escape hatch to a review queue rather than a confident wrong guess. The confidence score is the signal that routes these: high-confidence placements publish, low-confidence ones wait for a human glance.
Reclassification is a recurring event
The mistake is treating classification as a launch task. It is a recurring event, because every new vendor arrives with a new category scheme and every catalog shift changes what the tree needs to hold.
When our marketplace grew from supplements into equipment, gear briefly reached nearly half the catalog and the old, supplement-shaped categories stopped being navigable. Worse, a martial-arts uniform onboarded before category-aware gating existed had been enriched as if it were a supplement — complete with serving sizes and dosage advice for a piece of clothing — and cached re-runs happily served the wrong answer again. The fix was two-part: category-aware profiles so gear never receives supplement fields, and the ability to reclassify and re-enrich the whole catalog cheaply enough to absorb a new vendor without a data-cleanup project each time. Budget for reclassification; do not treat it as done.
The enabling condition is cost: reclassification is only routine if re-running the classifier over the whole catalog is cheap, which is exactly what content-hash caching and change detection buy you. A marketplace that can re-classify for near-nothing treats a new vendor's odd categories as a Tuesday, not a project.
One design rule keeps the tree usable as it grows: keep it shallow enough to browse. A common failure is a taxonomy so deep that a shopper clicks five times to reach products — every level is a decision, and decisions shed shoppers. Favour breadth over depth at the top, let facets do the fine-grained narrowing rather than more hierarchy, and resist a category for every edge case; a "misc" bucket reviewed monthly beats a hundred near-empty leaves nobody browses.
Facets fall out of the taxonomy
A well-built taxonomy is not just for browse pages — it is the source of your filters. Each dimension becomes a facet, and because the classifier normalised every vendor's products into the same dimensions, a single "product type" filter works consistently across all six vendors instead of exposing six vendors' incompatible attribute names. The shopper filtering by "foam roller" does not know or care that three vendors called it three things; the taxonomy already reconciled them. Which facets earn a place, and how to keep facet pages from polluting your index, is the subject of faceted navigation, and how the underlying search uses these attributes is its own deep dive.
Key takeaways
- Design the tree for shoppers who have never heard of your vendors; a union of vendor categories is incoherent by construction.
- Model a few orthogonal dimensions — department, activity, type, use case — so shoppers can arrive from any of them.
- Humans design the taxonomy; an AI classifier fills it — never let the model invent categories that fit the data and confuse the shopper.
- Classify the enriched product, with confidence scores; low-confidence placements are review candidates, not facts.
- Treat reclassification as recurring, not a launch task — cheap re-classification is what lets you absorb a new vendor without a cleanup project.
Frequently asked questions
What makes a good ecommerce product taxonomy?
Should you reuse a vendor's categories on a marketplace?
How does AI classification of products work?
How often should you re-classify a catalog?
A catalog shoppers can actually browse.
We classify every vendor's products into one shopper-first taxonomy so browse and filters work across all of them — part of the managed marketplace we run.
Request early access See the live marketplace →