What is a Backbone Taxonomy

Having discussed with a wide range of retailers as well as a lot of their suppliers, we have discovered that taxonomy is a very diverse concept: while some companies have thousands of sub-sub-sub-sub-categories and gazillions of attributes, others simply don’t have anything clearly stated on how their products should be organized, classified or described. But what exactly is taxonomy when it comes to retail? To us, it groups the three tools that help categorize and break down the characteristics of a product:

1. the category tree (how can I group my products by nature?)
2. the attribute list (what additional information on my product can I give?)
3. the attribute value list (what are the most common values for a given attribute?)

Through our discussions with 20 retailers and more than 80 of their suppliers, we have found out that about

• 23% do not have a fixed category tree
• 49% do not manage a proper set of attributes for their products
• 68% do not use a list of values.

In any retailer the objective has always been to standardise product information and to foster more efficient information exchange between e-commerce parties – both suppliers and customers. Please note that most of the retailers will have dual category trees, one for their back/middle office solution often manifesting in the MDM Tool as the Primary Product Hierarchy or Backbone and one for their website, the Web Selling Taxonomy.

There are a few differences. In the Backbone Taxonomy tree, a given product will only be in one category while on the website a product might be in several categories, to enhance its visibility. Also, the website categories might be frequently changed based on performance monitoring and/or strategic decisions, while the back-office category tree should be more rigid and less often changed, and hence should be designed as robust and comprehensive as possible from the start. The website will always be a partial reflection of the organisation of the core category tree. The number, names and accuracy of the categories and attributes should match the size, organisation and maturity of the company. 

But why you would you need a robust, comprehensive backbone taxonomy? Here are just a few of the perks:

Easier transfers: If you are a manufacturer or a supplier, providing the right classification information and a list of characteristics as extensive as possible to your retailers also simply makes sense in order to ease the customer’s journey to your products. You might not have the exact same category tree with your retailers, or the same attribute names but if you give them a clear and organized set of categories and description of your products, you’ll save their time and ensure your products are given the exposure they deserve.

Stronger reporting: For any company, identifying the over or under performing divisions is a vital necessity. When you’re a retailer, it all starts with a proper product classification, doesn’t it? The more accurate it is and the more efficient, decision-supporting and value-creating your reporting will be. And trust us, you’ll save time. A lot.

Better product page:  the category tree may be the backbone tool helping a customer to get to your product, but the attribute list will definitely make them buy (or not) your product. And whether it’s the power of that set of speakers or the length of the cord of that rice cooker, at some point, there is someone out there who is going to ask. It’s always better to have the answers ready.

Better Onsite classification and search: if you manage an e-commerce website, you’ll be aware that facet or filter attributes and search bar efficiency are key to your customers’ experience, and to your conversion rate. The backbone taxonomy drives the filter attributes of categories and makes finding the right product easier.

How to Build a Product Taxonomy

Now let us discuss what would be the best practices for product taxonomy, how to build an efficient category tree or how to differentiate between what’s category material and what should be treated as an attribute.

First of all, a bit of vocabulary about product taxonomy. There are three main tools :

1. The category tree (also known as product hierarchy): it helps group products by nature in a set of hierarchized categories.
   
   Example: Home > Home Appliances > Kitchen > Cooking > Rice Cookers
2. The attribute list (also known as facets, dimensions or refinements): additional information attributes, used to qualify the products in a same category. When applied to a product, an attribute will require a value.
   
   Example: Bowl capacity, colour, type of sole …
3. The value list: for some attributes, the finite, predefined set of possible values, for Booleans (yes/no) or rich attributes
   
   Example: Blue, 1.5 litres, 220V, strong, …

Each attribute will apply to several categories, and have various values. Values are linked to one and only attribute.

Understanding the relationships between those three tools is essential to the understanding of taxonomy design. What will follow is a set of advice based on our experience and research and intended to help the would-be and the seasoned taxonomists in their designing or revamping of product classifications.

How many is too many ?

In our opinion a robust and understandable category tree should have a hierarchy depth of 3 to 5 category levels, and between 5 and 15 level one categories. This is of course dependent on the width of the assortment you are selling and your product normalization. For the attributes, and the values, there’s no limit! The more you have, the more accurate product description will be.

Where should I start ?

Check your inventory and the products you sell. That should give you a good view on how deep your category tree should be. If you are running a physical store and wish to go online, do not necessarily replicate the organisation of your store on your website categories. That might help the loyal customers, but the whole point of an e-commerce website is to go beyond your customer base and reach new customers. The use of physical space and the use of screen space are very different, as well as the customer behaviour online and offline. Remember that the categories will help your customer find your product, through navigation or search. Attributes will help the customer access in-depth information about the product.

How should I name my categories and attributes ?

There is often a question about whether a difference in product nature should be treated as an attribute or a subcategory :

Example: should I have a category for denim shirts and one for jersey shirts, or a shirt category, with the attribute fabric = “denim” or “jersey”

The answer often comes with a bit of common sense and experience of the e-commerce industry (category = product class that can stand by itself, attribute = descriptive element that can be used on several product types), but there are a few rules:

If you can re-use the qualifier on other categories (“denim jackets”), it makes sense to define it as an attribute (DRY = Don’t repeat yourself !)

It all boils down to having one additional attribute or one additional level of categories: try to balance between those two lists

Try to understand what your customers are looking for: would they consider denim a subcategory of shirts (i.e. they would look for denim shirts exclusively) or an additional information on the product ?

Should products appear in more than one category ?

Offering the same product in several aisles of a physical store or various categories of a website can enhance the visibility of this product and thus its sales.

For instance, a Ski jacket could be in Sports equipment and also in Apparel>Jackets

Sometimes a product can be displayed also in a special category (“offers of the week”, “Best deals”…)

However, that has to remain a front-end or store display option only. In your product management system or WMS, a product cannot be in more than one category. Otherwise, there are many risks: double-counting at reporting, mix-up in the stock management, inconsistencies in your purchase orders…

Most e-commerce software allow to display a product on several categories online, but this should be seen as a marketing tool only, and not interfere with the product back-end management

What level of standardization should I apply to my values ?

Once again, choosing to standardize values for an attribute (= all the values for this attribute can only be picked in a pre-defined, finite set of values) is often a tough choice, mixing flexibility, IT constraints, ease of management of the product list…

We’re not going to deny that there are perks to a strictly standardized value system, among others:

IT-wise, it helps ensuring the quality of the data appearing online, It can help to do cross-category and cross-attribute reporting or filtering It keeps the consumer in known grounds and will be less confusing for him (I know what Pink is, but what colour is Amaranth ?)

That might sound appealing, but one shall not forget the constraints:

• Having to reformat/”translate” all the information received from your suppliers can be extremely time-consuming if you don’t have the right tools
• You might be missing slight nuances in meaning

Forcing your system to accept only some values can, and will, lead to issues at product creation: products that will not update, system rejections…

We believe this has to be done on an attribute-by-attribute basis. It boils down to the number of different values for an attribute. Managing a set of 8 or 10 shirt sizes is achievable, but some attributes just don’t do very well with fixed values even though it might seem possible to standardize, simply because there are too many possible values (Brand, Colour…)

There are no strict rules to product taxonomy. However, the various elements listed in this article need to be thought of beforehand to make sure your product taxonomy will be able to help your business grow and never represent a hindrance to your daily management. Having the right tools to help you manage and interconnect your taxonomy with your business partners is also a wise choice.