All Posts

    For small businesses with limited product assortments and small budgets, maintaining two hierarchies for their products can be cost-prohibitive. They often don't have the capital or resources to manage any extra cost. However, when a seller grows to have more complex product lines, more extensive assortments, and additional marketplaces and resellers, they'll need separate taxonomies for product classification and website navigation.

    The differences between these two types of taxonomies are essential for selling on your website and any marketplace you want to syndicate to. 

    This guide explores the differences between a product classification taxonomy and a website navigational hierarchy and explains when and why you need both.

    Difference #1: Usage

    When You Need a Product Taxonomy 

    A product taxonomy is a structure that classifies a product using the category-specific metadata that should be assigned to a product. Although some metadata attributes will be the same across every product a seller carries, category-specific attributes define a particular set of metadata attributes that describe that product type.

    For example, a hammer has a few similar attributes to a screwdriver. They have a SKU number, package dimensions, and other shared characteristics. However, a hammer requires additional information: 

    • Hammer type: claw, framing, chipping, riveting, etc.
    • Face (striking surface) material: hardened steel, titanium, soft-face materials, etc.
    • Claw type: straight or curved 

    A screwdriver has none of the hammer's attributes, but it does have a head style, which is vital to classifying or finding a screwdriver:

    • Head style: Phillips, slotted, hex, square, etc. 

    Product classification taxonomies define the attributes that are specific to a category.  

    Therefore, product taxonomies are vital to describing the attributes by category you need to display on your website AND all partner websites to sell those products.  

    When You Need a Navigational Hierarchy 

    A website hierarchy has a different role than a product taxonomy. Website navigation aids in the findability of products. It does not create data or define the differences between various products. It's simply a way for users to find products. 

    Although some customers may use the navigation of a website hierarchy, most users on an e-commerce website use search. When customers know what they want, they search to retrieve that informationIf they are still determining what they want, they will browse to discover what products or services are available.  

    Frequently, users will shift between retrieval and discovery in the same session. First, users search for a category and filter their options using facets that appear as navigational nodes. Customers on websites that use search convert at twice the rate as those that use navigation, and most users prefer to search to get to a category of products and follow up with faceted filtering to narrow down their selection. 

    The way that users interact with search is why Amazon has de-prioritized navigation for search on its website and mobile app. It is the same reason there is no hierarchy available in Google Search. Users do not interact with navigation hierarchies to a level that justifies investing heavily for that purpose. 

    So why have a navigation hierarchy at all? Simple: Search Engine Optimization, or SEO, requires it. The bots that index websites cannot use search, as they do not have a context to search for. To have your products indexed on Google, you must have a navigational hierarchy; otherwise, Google will miss anything it can't find on your homepage.  

    This leads to another important fact: You must build your website navigation for the bots to index the underlying content, not just the customers who choose between search and navigation. Search indexing crawlers cannot use the search box on your website to find products and, as such, rely heavily on the navigation hierarchy to discover new products and pages. Your term choices must be thoughtful about how you want them indexed on Google or other search engines, not just how your customers think of them.

    Website navigation is integral to your SEO and customer acquisition strategy, as much as it is integral to your customer findability strategy.  

    Difference #2: Rules for Design

    Product taxonomies and website hierarchies are designed using different best practices because they have different goals. taxonomy-vs-web-nav-1

    Product Classification Type 

    Product taxonomies are mutually exclusive. On the surface, that means that every product can only be assigned to a single classification or leaf node. This rule is applied to ensure that a hammer isn't ALSO assigned as a screwdriver and suddenly requires attributes to be completed that make no sense against a hammer. If you have two hammer nodes, the attributes can stray over time, leading to inconsistent data quality. A single leaf node per product avoids data quality problems. 

    A website hierarchy is meant to present data in terms that resonate with the user, whether the user is a human or an indexing bot. Therefore, website navigation hierarchies are polyhierarchical, where a single product can be assigned to multiple nodes. The more nodes a product is assigned to, the easier it is for customers or indexing bots to find it. Therefore, you should assign products to multiple nodes in a website navigation hierarchyThere is a caveat, though – overusing polyhierarchies can confuse search engines and diminish your SEO, reducing findability. 

    Depth of Hierarchy 

    Due to their very nature, taxonomies can contain many levels of depth. The rules for how many levels of depth in these taxonomies are similar but differ in their purposes. For example, a product taxonomy should only be as deep as is needed to build differing classifications. Having a node for a Phillips screwdriver versus a slot screwdriver is unnecessary in a product taxonomy. Website navigation might want to include the terms Slot, Phillips, Robertson, and other blade types to feed indexing bots. However, a good website hierarchy is generally at most 3 levels deep.  

    The depth of a product taxonomy also depends on the tool you use to maintain the taxonomy. Some Product Information Management (PIM) and Master Data Management (MDM) tools require a consistent depth to your taxonomy, while others allow varying depth by category (called a ragged hierarchy). Nearly all e-commerce/CMS platforms will enable you to choose between the two options. Therefore, your taxonomy depth requirements are predicated on the limitations of your chosen tool.  

    Visibility 

    By design, a website navigational hierarchy is visible to your external users. Product classification taxonomies are rarely visible to external users. Therefore, a product taxonomy can use terms specific to a company, whereas navigation hierarchies should use industry-specific taxonomy to maximize their SEO. Understanding these differences allows for customization of the taxonomy to the user for which it is meant. Understanding use cases and user terminology is vital to both, but applying that knowledge is entirely different based on these terms' internal versus external visibility. 

    Term Choices 

    The terms you choose for a navigational hierarchy are based on the indexing bots, industry-standard terms, and findability strategies you employ. Product taxonomies can use proprietary terms your business utilizes, but only when the terms help you classify products efficiently.  

    Because product taxonomies are designed to assign category-specific metadata elements to a product, ensuring a product is classified correctly is vital. If a product is incorrectly classified, it will end up mapped to the incorrect spot in your website navigational hierarchy. The ripple effects of bad classifications affect all other aspects of the presentation of your products. 

    Nomenclature

    Nomenclature is closely related to term choice. Term choice is about understanding the purpose of the end use of that term – that is, selecting the best term for the intended audience – while nomenclature describes the origin of selected terms.

    If you are a manufacturer that only sells your own products, a product taxonomy can use your own internal terminology to define both the categories and the attributes you use. This is because your product taxonomy is not seen externally, and therefore, your own terminology based on your business needs is more efficient for classifying and attributing a product assortment. Your internal subject matter experts know your terminology and have an easier time managing that terminology.

    Businesses that rely on outside suppliers or vendors to provide data may want to stick with industry-specific terminology. Internal nomenclature creates inefficiencies in product classification, as those external users may not understand some of that internal terminology. Using terms in your classification hierarchy and your attribution avoids confusion that can slow the onboarding process and your speed-to-market.  

    Companies that sell on marketplaces and into retailers and distributors will also find it more efficient to use industry-standard terminology, as your internal nomenclature will rarely align with the terminology used by those channels. It is much faster to map industry terminology to their classification hierarchies than to attempt that mapping with specific internal terminology.

    Web hierarchies are all about the display of data to an end user. Therefore, the internal nomenclature might not make sense to an external user. A combination of user-centric and industry terminology is usually best unless your customers understand your internal product naming structures. 

    Therefore, a product taxonomy should use terminology that makes sense internally, while a web hierarchy should use terminology that makes sense externally. Due to the advancement in catalog management tools and mapping systems between platforms, translating your internal classification terminology to an external view is fairly easy to manage.

    Difference #3: Talent 

    The use cases for product taxonomy and website navigation differ significantly. So do the people who manage those hierarchies. Where an SEO expert is needed to manage a navigational hierarchy, the skillset to manage a product classification taxonomy is more research-oriented and highly dependent on the ability to describe products through product research. Where a marketing degree is helpful with a navigational hierarchy, a library sciences degree or product development experience is much more valuable for a product taxonomy. 

    Small businesses can sometimes use the same person to do both; some people are good at both. However, as the data requirements become more complete, the assortment gets more extensive, and the number of retailers and marketplaces increases, the need for separate teams to manage two uniquely different skill sets becomes self-apparent. 

    Summary

    Although product taxonomies and navigational hierarchies have two different use cases, they are intrinsically tied together. A product taxonomy classifies products and then provides the characteristic attributes that are displayed in a website experience based on a navigational hierarchy. You cannot have one without the other; making one into the other doesn't scale over time. Understanding the differences can assist your teams in hiring the right resources, building the proper best practices, and growing your business. 

    Dan O'Connor
    Dan O'Connor
    With over 15 years of experience in taxonomy, product data, and solving product data challenges, Dan has been involved with every aspect of Product Data. Working for Vendors, Clients, and Consultants, Dan has worked to catalog the issues from all viewpoints to understand the product data space inside and out.

    Recent Posts

    [Earley AI Podcast] Episode 41: Ian Hook

    Ian Hook on Advancing Operational Excellence with AI and Knowledge Management - The Earley AI Podcast with Seth Earley - Episode #041 Guest: Ian Hook

    [Earley AI Podcast] Episode 40: Marc Pickren

    Search Optimization, Competitive Advantage, and Balancing Privacy in an AI-Powered Future - Marc Pickren - The Earley AI Podcast with Seth Earley - Episode #040 Guest: Marc Pickren

    [RECORDED] Product Data Mastery - Reducing Returns to Increase Margin Through Better Product Data

    Improving product data quality will inevitably increase your sales. However, there are other benefits (beyond improved revenue) from investing in product data to sustain your margins while lowering costs. One poorly understood benefit of having complete, accurate, consistent product data is the reduction in costs of product returns. Managing logistics and resources needed to process returns, as well as the reduction in margins based on the costs of re-packaging or disposing of returned products, are getting more attention and analysis than in previous years. This is a B2C and a B2B issue, and keeping more of your already-sold product in your customer’s hands will lower costs and increase margins at a fraction of the cost of building new market share. This webinar will discuss how EIS can assist in all aspects of product data including increasing revenue and reducing the costs of returns. We will discuss how to frame the data problems and solutions tied to product returns, and ways to implement scalable and durable changes to improve margins and increase revenue.