First, an unfortunate fact: The majority of eCommerce merchants only learn the category/classification distinction after systemic elements break down: It might be filters which stop working, uncontrolled categories multiplication, a slowdown in supplier onboarding, or a PIM platform implementation which becomes a dispute about taxonomy. Whether it’s one, some, or all of these, the results come at a price to your business.
The root cause of this mayhem is structural. Classification and navigation aren’t the same system. They might both look like category trees, but they serve different users and follow different sets of rules.
Classification is how you define what a product is.
Navigation is how you help people (and bots) find it.
Confusing the two degrades the value of both.
Classification: the internal logic of your product universe
Classification is the back-end “source of truth” for product data. It defines:
- how products are grouped into categories
- which attributes belong to those categories
- what ‘complete’ means for each product type
- how variants and families are structured
- which governance rules apply
Classification is essentially inward-facing. It reflects how the business understands its own products, not how customers browse.
In the context of PIM, classification is where the data model becomes enforceable. A category isn’t just a label, but a template which propels attribute requirements. For instance, a hammer and a screwdriver may share shared fields like SKU or dimensions, but they diverge immediately when it comes to category-specific requirements. A hammer needs hammer type, face material, claw type. A screwdriver needs head style, tip size, shaft length. Those differences aren’t merely ‘useful to highlight.’ They determine whether the product can be validated, compared, filtered, and accepted by downstream channels.
The above is why classification is very often:
- Attribute-led: driven by standardised values such as dimensions, material, voltage, operating pressure, weight
- Aligned with industry standards-: many businesses use ETIM, ECLASS, UNSPSC, or GS1 GPC (or their internal equivalent) to minimise ambiguity and ensure consistency across the supply chain
- Stable: a “12V drill” remains a drill irrespective of whether marketing is running ‘Christmas gifts’ or “Summer DIY”
If your classification is weak, every task downstream becomes manually-focused, inconsistent, or impossible to scale. That means foundational areas like enrichment, automation, and channel transformation.
Navigation is the customer-facing map
Navigation is the browsing and discovery layer that sits atop your data. It defines:
- how customers browse categories
- how category pages are grouped and labelled
- which products appear where
- how filters behave in context
- how search engines crawl your catalogue
It’s outwards-oriented, reflecting customer intent and deploying the language of marketing, not the internal product logic which your teams need.
Navigation is typically:
- Fluid and contextual: it changes based on seasonality, campaigns, and merchandising strategy (such as “New Arrivals,” “Best Sellers,” “Energy-Efficient Office,” “Gifts for Gardeners”).
- Polyhierarchical: as in, the same product can appear in multiple places to improve discoverability.
Navigation also performs a structural role that teams often underestimate – Search engine Optimisation. Search engines can’t function by using your own site search bar. They rely on linked structures (category paths and internal linking) to discover products and pages. Thus, navigation isn’t only part of the UX; It’s a key component of your customer acquisition architecture.
Why do teams confuse the two?
The confusion is frequently inherited from legacy structures:
- ERP category trees built primarily for internal reporting
- print catalogue layouts built for publishing, not filtering
- historical website menus mirroring those of internal departments
- PIM system implementations which adopt existing hierarchies wholesale, without any redesign
That’s why teams end up with category trees which match organisational charts, attribute sets built for operations not comparison, and a navigation menu that mirrors the taxonomy instead of customer intent.
The whole thing looks like an eCommerce problem, but from our experience, it’s usually a data modelling problem.
What ends up broken when classification drives navigation
If you push internal classification directly into your website navigation structure, three failures quickly rear their heads:
- Customers can’t find what they’re looking for
It’s rare for internal labels to match with customer language. That causes the menu to skew towards being unintuitive: users generally bounce back to search, or they simply leave.
- Filters become inconsistent or irrelevant
If your attribute schema wasn’t built cleanly by category, facets cannot behave reliably. The invariably high incidence of missing filters, ‘messy’ values, and the dreaded ‘zero results’ pages strangle conversion.
- Merchandising becomes a workaround cottage industry
Teams create exceptions, overrides, and duplicate versions of data to patch up problems and make the site usable. Operational costs add up and this manual approach soon erodes basic data quality.
So, navigation problems are generally symptoms of weakness in classification and certainly aren’t just a backlog of ‘UX tweaks’ when you get round to it.
What breaks down when navigation drives classification?
The opposite mistake, that is, designing classification around the website menu, is just as damaging to the business.
Navigation evolves. It changes frequently. Classification is foundational. It shouldn’t change. What happens if UX-first navigation becomes the default taxonomy model?
- the taxonomy becomes shallow and generic
- attribute requirements lose specificity
- variant logic collapses
- supplier onboarding becomes chaotic
- automation and validation checks stop functioning
In a few words, a taxonomy which has been built for browsing simply can’t carry the weight of governance, efficient onboarding, and multi-channel transformation.Navigation is a view, not the foundation.
Getting the relationship right: classification first, navigation second
The two must work together, but in the right order.
- Classification defines the truth: identity, attributes, families, rules.
- Navigation expresses that truth: regrouping, relabelling, and mapping for discovery.
Operationally, the pattern is one-to-many mapping:
- Maintain product data once in classification.
- Map products to multiple navigation nodes based on intent.
An example taken from B2B makes this concrete. A high-pressure hydraulic valve might be classified deeply for data integrity (Fluid Power > Valves > Directional Control > Solenoid Operated) with mandatory attributes like operating pressure, flow rate, voltage, and mounting pattern. But that same product can appear in multiple navigation paths depending on user intent: It could be “Spare Parts,” or “Automation & Control,” or “Brands,” or “Solutions” by industry. But there’s only one product truth, despite there being several routes to find it.
When this relationship is aligned:
- filters perform consistently because the product’s attributes have been inherited from classification
- terminology can be translated (technical classification names, user-friendly navigation labels)
- cross-sell logic becomes scalable because relatedness is driven by shared technical attributes
- channel outputs are easier because the core model remains stable
Where SKULaunch fits: enforcement protocols, not matters of opinion
Even when teams agree on the fundamental difference, there are still major operational challenges:
- Applying classification consistently during onboarding
- Enforcing attribute requirements
- Maintaining variant logic
- Generating navigation views that stay aligned as channels evolve
That’s why we at Start with Data developed our SKULaunch platform – to eliminate the challenges and bugbears of this distinction by acting as the enforcement layer across onboarding, enrichment, and channel transformations. It applies taxonomy and schema rules so that your classification remains reliable, and navigation remains predictable for the end user.
If you’re suffering from filters which don’t work, or chronically multiplying product categories, or your PIM feels harder to use than it should, start with your product structure. Get in touch today to book a structural review with us so we at Start with Data can identify where classification, sch