During our usability studies of how users navigate e-commerce sites, one of the most severe issues observed is over-categorization. This occurs when a site wrongly implements its product types as mutually-exclusive category scopes when instead they should have been implemented as combineable filters.
Testing showed over-categorization to cause severe usability issues, including:
Unsurprisingly such critical usability issues can have serious business implications, and over-categorization proved a direct cause of site abandonments during testing. So while this may appear like a subtle implementation detail on the surface – if a given product tagging are implemented as mutually-exclusive categories or as combinable filters – it has very serious implications on the user experience.
The sometimes minute interface differences between product type categories and product type filters may help explain why during our Product List & Filtering benchmark study we found that 54% of major US e-commerce sites suffer from over-categorization at one or multiple points in their category hierarchy – having wrongly implemented product attributes as sub-categories rather than filters. (Although on a positive note, we can report that this has improved slightly, with 10% fewer sites suffering from over-categorization compared to 2013.)
In this article we’ll therefore present our test findings on the severity of over-categorization, and present a simple rule on when a product attribute should be implemented as a filter or a sub-category.
The frequent misimplementation of a filtering attribute as a category is likely because a filter and a category tend to a) work in very similar ways, b) are often found displayed next to one another, and c) can technically be almost the same thing. However, filters and categories are in no way interchangeable implementations, as they come with important differences:
Because filters are combinable they afford the user much greater customization power over the product list, yet it is the user’s category scope that determines which filters are available to begin with. This interdependency between categories and filters can make them look all the more alike, yet actually just makes it even more important to correctly distinguish the two, as misimplementing one hurts automatically hurts the other.
Hopefully the distinction between categories and filters is clear at this point. When we talk of over-categorization, we are thus referring to a product type or attribute that was wrongly implemented as a category rather than a filter. The problem of this is – as covered in the previous section – that categories are mutually exclusive, which means they cannot be combined and users therefore aren’t able to select and see products matching multiple values within that product type or attribute.
Over-categorization means a site’s category hierarchy has become too deep. The site has taken product types and attributes that should have been combinable filters and mistakenly implemented them as categories instead. The consequences of this misimplementation are manyfold and severe, with the three most important issues observed being:
While it’s clear that the vast majority of product attributes should be implemented as filters, “product types” (and, in particular, “sub-product types”) are often difficult to correctly classify as either a category or a filter. To help determine whether a given product type should be a category or a filter, the “Shared Product Attribute Test” can be used.
Shared Product Attribute Test: If the product attributes are the same across the different product types in question, then the set of product types should (typically) be implemented as filters
The trick is to look at the potential benefits of turning a given product type into a set of categories rather filters. If the product attributes are the same across the different product types in question, then the set of product types should (typically) be implemented as filters, because there are no scoping benefits to implementing them as categories. On the other hand, if most of the product types have unique sets of product attributes, then it is worth considering if the product types should instead be implemented as a category scope to segregate the unique filtering options within them.
Let’s try to apply this for some of the previously mentioned examples:
A decent supplementary tool for quickly scanning a large and deep product catalog for any misimplemented categories is to programmatically query each category for the number of products it contains. If a category only contains a few products (5-30, depending on industry), it can be a sign of over-categorization, and thus warrant further manual evaluation using the prior mentioned “shared product attribute test.”
However, treat this scanning tool as a starting point, not the final destination – it can help you figure out which categories to look at first, but given the severity and frequency of misimplementations, all categories should ultimately undergo proper evaluation.
One reason we often see for over-categorization is ad-hoc product tagging, the all-too-frequent “let’s just create this ‘winter jackets’ category now because we don’t have the setup or time to do a proper ‘seasons filters’ at the moment.” There may be legitimate reasons for a “quick and dirty” fix every now and then – but any such fixes should be treated as temporary solutions. Yet in practice, we often see these seemingly innocent “one-off” fixes accumulate over the years, never getting fixed and slowly making their way into more and more of the site’s category hierarchy, greatly limiting users’ product list control.
Now, while ad-hoc product tagging certainly help explain some of the 54% of sites that during our benchmark study were found to over-categorize, there’s an even more common cause. When working with clients we often see important product types and attributes wrongly implemented as categories simply because their site design provides more exposure to categories than filters. While the underlying intent of this is good (users should be nudged towards important paths), our Product List & Filtering study revealed a much more effective design pattern to ensure exposure to important product type filters without (mis)implementing them as categories. These research findings will be the focus of our next article.
This article presents the research findings from just 1 of the 850+ UX guidelines in Baymard Premium – get full access to learn how to create a “State of the Art” e-commerce navigation experience.
Join 22,000+ readers and get Baymard’s research articles by RSS feed or
Topics include user experience, web design, and e-commerce
Articles are always delivered ad-free and in their full length
1-click unsubscribe at any time
Great post but has a very troublesome typo, here in what is arguably the most key sentence in the whole article:
“If the product attributes are the same across the different product types in question, then the set of product types should (typically) be implemented as filters, because there are no scoping benefits to implementing them as filters.”
Pretty sure that last word was meant to be “categories”. Right?
Hi Tim, sorry for that, thanks for point it out. It’s fixed.
Settle down. He got the point across well.
I would have thought that the reason most websites adopt this strategy is because they feel having a landing page for “kids lamps” for example would give them an SEO benefit for the organic search. Which leads into the whole Filters vs. Facets argument.
Great point, but note that we’ve found it’s important each filtering value from a usability perspective have a unique URL (use history.pushState() to invoke a URL rewrite/browser history event w.o. page reload).
Hence, a “Kids” filter can have unique page headers, page title, content, etc. (as in, if the alternative “Kids Lamps” category would simply have contained a product list with all “Kids Lamps” there’s very little/no difference in the actual landing page content for a proper filter implementation vs. a category implementation). This should mitigate any SEO implications that needs to be outweighed against have a much more users friendly site hierarchy. I’ll see if I can fold some of these details into the next article as well.
This implementation could result in thousands of unique URLS with unique page titles and headings but with overlapping and sometimes duplicate contents for the combination of filters being applied turning that into a bot trap which is not considered as a best practice in terms of technical SEO.
So what is the ideals solution?
Great article Christian with excellent articles that bring this issue to life for e-commerce retailers. We’re going to share this in our monthly round up of the best retail marketing articles from across the web.
In particular I thought your point about ad hoc product tagging was bang on. PIM is a discipline in itself and I don’t think many of the SME retailers we work with understand the importance of this for analytics-purposes. We’re undoing a Government funded innovation project at the moment which uses product types and filters as an input into our machine-learning models and the issues we’re finding all relate to the set-up and management of the product hierarchy, which is forcing us to force test clients to improve it.
Look forward to the next article!
Great read. Not only pointing out the problem, but also handing a solution.
No offense, but you should consider some “usability studies” on your comments section. It looks horrendous with all that forms and input fields…
P.S. Nice post tho
Great article, thank you, it is exactly what I was looking for (Categories vs Type Filters). Greetings.
Great read. Not only pointing out the problem, but also handing a solution.
I just came across your article and it certainly raises a really valid point.
However, I wonder if you agree that there is room for some middle ground?
To show what I mean, I will use your Wayfair ‘Lamps’ example;
Let’s assume that Wayfair know that Buffet Lamps are a big seller and a product with high search volume that a lot of users on their site want to purchase. They want a targeted SEO/PPC landing page for this product type, and an easy way for customers to find the products that fall within this type.
They might therefore create a sub category under ‘Table Lamps’, that essentially gives a quick link for people who know that they do want a buffet lamp, and serves as that landing page.
However, they might also have this type of lamp as a filter under the ‘Table Lamps’ category. This option is then helpful for people who know they want a table lamp, but might not specifically want (or understand what is meant by) a buffet lamp.
© 2021 Baymard Institute US: +1 (415) 315-9567 EU: +45 3696 9567 firstname.lastname@example.org