PrestaShop Product Filters: Why The Number Next To A Filter Sometimes Does Not Add Up

The problem nobody reports, but everybody notices

A shopper on a category page ticks a filter that says "Red (12)", expects 12 products, and the listing shows 8, or 15. No error message, no explanation, just a number that did not add up. This is not a cosmetic detail. It is the kind of inconsistency that kills trust in the rest of the site within half a second: if the filter lies about a small, visible number, why would I trust the price or the stock status?

The reason this problem is so common in faceted filters (the ones that show several filter categories together, each with a count) is not sloppiness. It is that computing that number so it always matches the click is harder than it looks, and it is one of the places where faceted search engines genuinely differ from one another.

Why a count can disagree with the click

The most frequent cause is that the count and the click are computed with two different pieces of logic. A typical case: a merchant groups several similar values under one label (for example "Red" covering the catalog's Crimson, Scarlet and Burgundy variants). If the count adds up how many times each variant appears, while the click instead applies "must have all of these variants together" instead of "must have at least one of these variants", the number shown and the number obtained are answering two different questions. The rule that keeps everything consistent is simple to state and easy to break in code: the count must answer exactly the same question the click will apply, not a similar one.

A correct way to solve it, verified across several search engines (PrestaShop's native driver and Elasticsearch), is to treat a group of values as a single set from the start: the count is a single "count the distinct products that have at least one of these values" (a `COUNT(DISTINCT ...)` in the database, or a dedicated aggregation on an engine like Elasticsearch), and the click applies exactly the same condition. The number shown stops being a sum that can overpromise, and becomes the real union, the same one the click produces.

There is also an honest choice worth knowing about: with Meilisearch, for grouped values the number next to the filter is simply not shown, rather than risk showing a wrong one. It is a declared design decision in the merchant's settings panel, not a hidden limitation. When it comes to trust, a filter with no number is always better than a filter with a false one.

The cost of always getting the number right

Even when the logic is correct, computing an exact count for every value of every filter has a real cost, and it depends heavily on which search engine is used. With an external engine like Elasticsearch or Meilisearch, counts come as part of the same query that computes the results, so the extra cost is minimal. With PrestaShop's native engine, which works inside the shop's own database, every single filter value can require its own counting query.

On a 200,000-product catalog with around 2,250 attribute and feature groups, turning off exact filter counts (showing the list of available values without the number next to them) took a category page with one active filter from 43.3 seconds to 11.9 seconds, and on the feature and attribute facets alone from 6.8 and 5.4 seconds respectively to 15 and 19 milliseconds. These numbers tell a simple story: that little number in parentheses, on a large catalog with a database-only engine, can cost more than the rest of the page combined.

What to do, in practice

• On a catalog of a few thousand products, exact counts are almost always worth their cost, keep them.
• On a large catalog with only the native engine, consider whether to turn off exact counts (showing just the list of available values) or move to an external engine that computes them at no extra cost.
• If you use filters with grouped values (several variants under one label), ask explicitly how they are handled when "all filters together must match" (AND mode): this is the case where sum and union diverge the most, and it is the case a customer notices first.
• Always prefer a filter that shows no number over a filter that shows a wrong one. If a search module cannot guarantee an exact count in a given condition, the right choice is to hide it, not to guess.

The short version

A wrong number next to a filter is not a graphic detail, it is a sign that the count and the click are answering two different questions, and on a large catalog with the wrong engine it can also be the single most expensive part of the page. In cll_essearch we addressed this at the root, with one shared calculation that both the count and the click use, across the native driver, Elasticsearch, OpenSearch and Meilisearch, and with the option to turn counts off when the catalog is too large for computing them in real time to be worth it. If a shopper has ever written to you saying "the filter said one thing and then I found nothing", this is probably the problem you have.

Elasticsearch Search & Faceted NavigationLightning-fast, typo-tolerant search and modern modal faceted navigation with the built-in engine, or powered…€99.99View product