# Ecommerce Filtering UX: Why Customers Can't Narrow Results

Ecommerce filtering UX breaks when filters are missing, values are duplicated or labels confuse. See what Baymard found and how to fix the data behind it.

A customer lands on your women’s jackets page looking for something to get through a Melbourne winter. There are 400 products and one thing they care about: it has to be waterproof. They open the filters and find brand, price, colour and size, all working as intended, and nothing about waterproofing. So they scroll, open a few products to read the descriptions, and leave somewhere around the third row. You may stock thirty jackets that would have suited them. The listing page had no way to show them.
This post is for ecommerce managers and heads of digital whose listing pages have a full set of filters that still don’t help customers narrow anything down. It follows our posts on site search, category navigation and product pages, and the pattern will be familiar from those: what the customer sees is built on product data, and that data was assembled for a different purpose. Below is where ecommerce filtering fails customers in Baymard’s testing, which fixes belong in the theme, and which belong in your product data.
Ecommerce filters can only show the data you have
Shopify, Adobe Commerce, BigCommerce and WooCommerce all generate filter options (often called faceted navigation) from structured fields attached to products, whether the platform calls them attributes, options, custom fields or metafields. Whatever values sit in a field become the options in the filter. If the field is empty on half the products in a category, those products drop out of the results the moment a customer uses it. The same applies if your listing pages run on a search and merchandising engine such as Algolia or Typesense: the engine can only offer filters on fields you send to its index.
That makes the filter panel the most direct view a customer gets of your product data. A gap in the data turns into a filter that doesn’t exist, an inconsistency turns into duplicate options, and an attribute nobody ever recorded turns into a question the customer can’t ask.
Baymard Institute’s 2025 benchmark rates 58% of desktop sites and 78% of mobile sites as mediocre or worse on product list UX, from more than 21,000 scored parameters across 170+ leading US and European sites. That benchmark covers product lists as a whole, of which filtering is a large part.
Where product filters fail customers
The filter the customer needs isn’t there
Baymard’s testing identified five filter types that should always be provided where they apply, because they are commonly used: price, user rating, colour, size and brand. Its 2025 benchmark finds 51% of sites don’t provide all five.
The essentials are the easier part, since most catalogues already hold price, brand, colour and size in structured fields. Rating is the exception: the average lives in your reviews platform and has to be written back to each product before a filter can use it. The harder gap is the filters specific to a product type. Baymard’s examples are temperature rating for bedding and compatibility for electronic accessories. For an Australian retailer it might be waterproof rating on jackets, wattage on heaters or battery platform on power tools. These are the attributes customers decide on, and they tend to arrive in supplier spec sheets and product descriptions rather than as structured fields.
A useful check is the product tile itself. Baymard found 38% of sites don’t offer filters for all the information they display in the product list. If the tile says “waterproof” and the filter panel doesn’t, the information exists somewhere, usually in the product name or description, but not in a field a filter can use. Baymard notes that “missing filters may be a symptom of an even more foundational issue of poor product data.”
The same value listed four ways
Open the colour filter on a category stocked from several suppliers and you may find “Navy”, “Navy Blue”, “NAVY” and “Midnight” as separate options. Sizes do the same thing: “10”, “AU 10”, “10 AU” and “Size 10” sitting in one list. Each supplier names things its own way, and when their data is loaded without being normalised, every variation becomes a filter value. Own-brand ranges reach the same result by a different route, when each season’s colour names (“Midnight”, “Ink”, “Storm”) go straight to the colour filter. The fix there is to keep the descriptive name on the product and filter on a separate colour family field.
Nothing tells the customer this has happened. Someone who ticks “Navy” gets a tidy set of results and has no way of knowing that the products labelled “Navy Blue” were excluded. Baymard’s guidance is that to offer consistent filter values, “the vendors’ product data and branded feature names need to be post-processed into a ‘common name’ product attributes”. That post-processing is data work, and it has to happen every time new stock arrives.
One value at a time
Baymard’s 2025 benchmark finds 14% of sites don’t let customers combine multiple values within the same filter type, such as two sizes or two brands at once. Baymard sets out the workaround this forces on customers: apply one value, remember the products, remove it, apply the next and compare from memory. One participant shopping for boots on a budget put it simply: “Oh, it looks like you have to pick one or the other.”
Labels written in your suppliers’ terms
Baymard finds 62% of sites use unclear filter labels that users may skip when trying to find what they want. In testing, a participant looking at wallets ignored an “RFID” filter option: “I don’t know what ‘RFID’ means so, probably a bad call.” Baymard also notes that some users leave the site to look up an unfamiliar term, at the risk of finding the product elsewhere and not coming back.
It is the same vocabulary problem that shows up in category navigation and site search. When attribute names come straight from a supplier feed or the ERP, they reach the filter panel in the supplier’s language. Baymard recommends using plainer terms where you can (“temperature” rather than “season rating”), explaining the terms that have to stay with a tooltip on desktop or a tappable icon on mobile, and using thumbnails for attributes that are easier to judge by eye.
Nothing for the themes customers shop by
Customers often shop by occasion, season, style or use: a dress for a wedding, a jacket for hiking, a gift for a teenager. Baymard calls these thematic filters. In Baymard’s 2015 filtering research, thematic filters saw “very high utilization rates (above 50%)” among test participants on the sites that offered them, while on sites without them, a lack of thematic filters often led participants to abandon. Usually they decided the few relevant products would be nearly impossible to find, and sometimes they concluded the store didn’t carry what they wanted at all.
Usually these attributes don’t exist anywhere yet. An ERP has no reason to record that a jacket suits hiking, and supplier feeds seldom say a dress works for a wedding. Somebody has to decide the values and apply them to every product, which makes these the most expensive filters on this list to add.
That cost is a reason to be selective. No catalogue can carry a filter for every way a customer might describe what they want, and each filter you add makes the panel longer for everyone using it. Baymard’s own view is that thematic filters “will typically have to be tailored uniquely to a site’s product catalog”, so the job is choosing the one or two themes that matter in each category: season for outerwear, occasion for dresses, activity for footwear. Your site search log is the best evidence for which ones, because customers type the themes they shop by. Some themes are better served without a filter at all. A theme with steady demand, such as hiking jackets, can be a category page of its own, and a seasonal one can be a collection that runs for the weeks it matters.
Customers can’t see what they’ve applied
Baymard finds 28% of sites don’t show an overview of applied filters. The problem is sharpest on mobile, where the filters sit behind a button. In Baymard’s testing, participants opened the filter interface just to confirm what they had selected, because nothing in the product list told them, and without an overview, removing a filter means opening the interface again.
Promoting the most-used filters into the product list itself helps here. Baymard finds 61% of sites don’t promote filters in the product list, and notes they are particularly helpful on mobile, where a promoted filter can save the customer a trip into the filter interface.
A presentation problem or a data problem
These failures fall into two groups, with different owners and very different costs.
Multi-select, the applied filters overview, promoted filters, explanations for unclear labels and truncating long lists of values are all presentation. A competent frontend developer can fix them on any platform, often in a sprint, and you should do it.
Missing category-specific filters, inconsistent values and thematic filters are data. Adding a “Waterproof” filter to the theme takes an afternoon. Populating that attribute accurately across 4,000 products, and keeping it populated as the range turns over, is the actual job. A filter built on a half-populated attribute is worse than no filter at all, because it hides every product where the field is blank from the customers who use it.
Where filter data has to come from
Your ERP holds what purchasing, stock control and finance need: SKUs, suppliers, costs, and the size and colour that define each variant. An ERP can often carry a few extra attributes in custom fields, and for a handful of filters that may be enough. Beyond that it runs into an ownership problem: nobody in purchasing or finance is responsible for waterproof ratings or occasions, and the ERP has no workflow for enriching them. Supplier data often does contain the technical attributes, in each supplier’s own naming. Neither source produces customer-facing filters on its own.
Getting there starts with ownership. Customer-facing attributes need an owner in the team that answers for the website, usually ecommerce or merchandising, and a decision about which system holds each one. From there it means keeping a controlled list of allowed values for each attribute so there is exactly one “Navy”, and mapping every supplier’s terms onto that list as data comes in. It also means an integration that carries those fields to the storefront on every sync rather than dropping the ones it wasn’t built for, and a rule that new products don’t go live until the attributes their category filters on are filled in.
That is the work a PIM exists to organise, and filter quality is one of the clearer signs of whether you need one. We cover that decision in our post on PIMs. The same attributes feed your site search index and your category rules, so fixing them for filters pays off in both places.
Auditing your own ecommerce filters
Work through these on your own store. None of them need a researcher.

Open your three highest-revenue categories and list the filters on each. Check for the five essentials, then for at least one filter specific to that product type.
Compare the information on a product tile with the filter panel. Anything shown on the tile but not filterable is a gap.
Open your colour and size filters and read every value. Count the duplicates and near-duplicates.
Pick a product you know qualifies for a filter, apply the filter, and check the product appears.
Try to select two values in one filter, such as two sizes.
On a phone, apply three filters and check you can see all three without reopening the filter panel.
Read your filter labels as a first-time customer would and mark any that need an explanation.
If your analytics records filter use, list the filters customers apply most, and the ones they apply and then immediately remove.
Export the catalogue and check what share of products in each category has a value for each attribute that category filters on.

The last one takes the longest and tells you the most, because it shows how many products your filters are silently excluding.
What to fix first
In rough order of return on effort: fix the presentation defects (multi-select, the applied filters overview, promoted filters on mobile and explanations for unclear labels), then merge the duplicate values in the filters you already have, then add the missing category-specific filters to your highest-revenue categories, populated properly before they go live.
The handful of thematic filters worth having, and catalogue-wide attribute coverage, come last, because they are the largest job and they reach back into your systems. Until that work is done, any clean-up is temporary, because every delivery of new stock brings the supplier’s values back in with it.
If you would like someone else to review your product listings, our UX audit is led by a Baymard-certified UX Professional, and its broader review covers product listing and filtering. If the problems lead back to your product data and how it moves between systems, that is the work we do most, so get in touch and we can look at it with you.

{"@context":"https://schema.org","@type":"FAQPage","mainEntity":[{"@type":"Question","acceptedAnswer":{"@type":"Answer","text":"There's no fixed number. Baymard's research points to five essential filter types (price, user rating, colour, size and brand) plus the filters specific to each product type, so a category of power tools needs a different set from a category of dresses. With a long list, promote the two or three customers use most so they're visible without scrolling. For long lists of values within one filter, Baymard's truncation guidance is to show up to 10 values before truncating, since testing found users mistaking a badly truncated list for the full list."},"name":"How many filters should a category page have?"},{"@type":"Question","acceptedAnswer":{"@type":"Answer","text":"Usually not. Filters generate a URL for every combination, and Google's guidance on faceted navigation notes that \"oftentimes there's no good reason to allow crawling of filtered items, as it consumes server resources for no or negligible benefit\". Its advice is to prevent crawling of filtered URLs you don't need indexed, and for any you do, to follow its URL conventions, including returning a 404 for filter combinations with no results. Where a filtered view matches something customers search for, such as waterproof hiking jackets, make it a proper category page with its own content rather than relying on a filter URL to rank."},"name":"Should our filtered pages be indexed by Google?"},{"@type":"Question","acceptedAnswer":{"@type":"Answer","text":"Some platforms allow it, Shopify included, and it works on a small catalogue maintained by one person. Tags are free text with no fixed list of allowed values, so as more people and more suppliers add products, the variations creep in and the filter fills up with near-duplicates. A structured attribute with a controlled list of values holds up as the catalogue grows, and it can be checked for completeness in a way tags can't."},"name":"Can we build filters from product tags?"},{"@type":"Question","acceptedAnswer":{"@type":"Answer","text":"Not to start. Multi-select, the applied filters overview and merging duplicate values all proceed without one. A PIM earns its place when you are maintaining customer-facing attributes across thousands of products from several suppliers and need one owned home for each attribute, a fixed list of values and a check that products are complete before they go live. We cover the decision in more detail in our post on whether you need a PIM."},"name":"Do we need a PIM to fix our filters?"}]}

                Frequently asked questions

    How many filters should a category page have?

There's no fixed number. Baymard's research points to five essential filter types (price, user rating, colour, size and brand) plus the filters specific to each product type, so a category of power tools needs a different set from a category of dresses. With a long list, promote the two or three customers use most so they're visible without scrolling. For long lists of values within one filter, Baymard's truncation guidance is to show up to 10 values before truncating, since testing found users mistaking a badly truncated list for the full list.

    Should our filtered pages be indexed by Google?

Usually not. Filters generate a URL for every combination, and Google's guidance on faceted navigation notes that "oftentimes there's no good reason to allow crawling of filtered items, as it consumes server resources for no or negligible benefit". Its advice is to prevent crawling of filtered URLs you don't need indexed, and for any you do, to follow its URL conventions, including returning a 404 for filter combinations with no results. Where a filtered view matches something customers search for, such as waterproof hiking jackets, make it a proper category page with its own content rather than relying on a filter URL to rank.

    Can we build filters from product tags?

Some platforms allow it, Shopify included, and it works on a small catalogue maintained by one person. Tags are free text with no fixed list of allowed values, so as more people and more suppliers add products, the variations creep in and the filter fills up with near-duplicates. A structured attribute with a controlled list of values holds up as the catalogue grows, and it can be checked for completeness in a way tags can't.

    Do we need a PIM to fix our filters?

Not to start. Multi-select, the applied filters overview and merging duplicate values all proceed without one. A PIM earns its place when you are maintaining customer-facing attributes across thousands of products from several suppliers and need one owned home for each attribute, a fixed list of values and a check that products are complete before they go live. We cover the decision in more detail in our post on whether you need a PIM.