Filters that sell: what we changed and what it did to conversion

The color filter was there. It sat at position 22 in the sidebar.

I opened Hotjar. Zero clicks on that facet. Over a full month. On a store with decent traffic.

The problem wasn't Elasticsearch. The data was fine. The problem was that nobody scrolled far enough to see it.

The filter at the bottom of the list

We were working on a catalog with 28k SKUs. Elasticsearch was already running, aggregations were correct — facets returned real data from the index. Technically, nothing was wrong.

But the sidebar had 24 filter groups. That's a lot. Users opened the filters, saw the list, scrolled... and closed it. They either fell back to search or left.

Hotjar revealed another pattern: users clicked only on the first 4-5 facets in the list. Everything below the fold was essentially ignored. "Size" was first. "Color" was twenty-second. And in our category, color is one of the highest-converting filters you can offer.

It wasn't a search problem. It was an ordering problem.

What happens when you have too many facets

There's the classic jam study. More options, fewer purchases. Faceted navigation works the same way.

28k SKUs generate a lot of unique attribute values. Show all of them and users feel overwhelmed — they don't see a "narrowing tool," they see another problem to solve before they can buy anything.

On top of that: some facet values were phantoms. "Blue" — listed, but zero products in that color in stock. User clicks, sees an empty page, leaves frustrated. We were surfacing noise because the aggregation returned the full distribution without availability filtering.

More data in the sidebar isn't always better. Sometimes it's worse.

Elasticsearch aggregations as UX data, not just search infrastructure

Technically, Elasticsearch aggregations are a way to get catalog distribution in a single query — no separate request per facet. One query, you get both products and attribute breakdowns. It's fast.

But there's a second use we started paying attention to: aggregation logs as a signal of what shoppers actually care about. Which fields appear most often as the primary filter in a session. Which values get selected first. It's not perfect behavioral analytics, but it's data rather than intuition.

Paired with Hotjar (click maps, scroll depth, filter interaction heatmaps), it gave us enough to make a decision rather than a guess.

Elasticsearch also let us make facets dynamic — show only values where products are in stock. That killed the phantom values in one query.

The four changes we made

Each one took less than a day.

First: reordered facets by actual click frequency. We pulled data from aggregation logs and Hotjar — what gets clicked first, what never gets touched. Color moved from position 22 to position 3. Brand moved from 5 to 7. The order now reflects real user behavior, not someone's assumption about it.

Second: added quick filter chips above the listing. The top 3-4 facets — the ones users clicked most — got surfaced as chips directly above the product grid, visible without opening the sidebar. No extra scroll, no drawer to open.

Third: removed zero-result values. An Elasticsearch aggregation with an availability filter handles this in a single query. The sidebar got cleaner.

Fourth: mobile. On mobile, the sidebar is a hidden drawer you tap a button to open. We added a horizontal chip row below the listing header — the three most-used facets always visible without any extra tap. Same data, different presentation for different context.

None of this required a new cluster. No schema changes. No reindexing. Reordering and some custom display logic.

What changed

One week after deploy: filter click rate up 2.4x. That's not conversion yet — that's engagement with the tool.

Four weeks out: catalog-to-cart conversion up 14%. Not magic. Just what happens when people actually use a filter that was always there but wasn't visible.

One caveat worth being honest about: we didn't run an A/B test. Full deploy, no holdout group. The +14% is a before/after observation, not a controlled experiment. But we'd had several months of flat numbers before the change.

For the broader Elasticsearch story — how it affects search UX and baseline conversion — I wrote about that separately: Elasticsearch is not a fast database. It's a UX tool.

Antipatterns that kill faceted navigation

I've seen the same mistakes across different projects.

Showing all values including zero-result ones. The user selects a filter, sees an empty page, closes the browser. That's the worst possible place to lose someone — you had them in the purchase funnel.

Setting facet order based on database column order. Or alphabetical. Or "how the competitor does it." None of these strategies are based on what your users actually want to filter by.

No analytics on filter clicks. Google Analytics and Hotjar both support element-level click tracking. Without this data, you're configuring filters blind.

One layout for mobile and desktop. On mobile, a sidebar with 20 filter groups is an interface disaster. The context is different, the interaction pattern needs to be different.

The point

Elasticsearch was already running correctly in this project. The index was right. Aggregations returned accurate data.

Conversion wasn't moving because users didn't reach the facets they needed. We saw that in Hotjar, cross-checked with aggregation logs, reordered things — and got a result.

Faceted search isn't about the technology. It's about the order in which you offer people a choice.