Filtros de producto en PrestaShop: por qué el número junto al filtro no siempre cuadra

El problema que nadie notifica, pero que todos notan

En una página de categoría, un cliente marca un filtro que indica «Rojo (12)», espera 12 productos y la lista muestra 8, o 15. Ningún mensaje de error, ninguna explicación, solo una cifra que no coincide. No es un detalle estético. Es el tipo de incoherencia que destruye en medio segundo la confianza en el resto del sitio: si el filtro miente en una cifra pequeña y bien visible, ¿por qué fiarse del precio o de la disponibilidad?

Que este problema sea tan frecuente en los filtros por facetas (los que muestran varias categorías de filtros a la vez, cada una con su recuento) no se debe a descuido. Se debe a que calcular esa cifra para que siempre coincida con el clic es más difícil de lo que parece, y es uno de los puntos en los que los buscadores por facetas se diferencian de verdad unos de otros.

Por qué un recuento puede contradecir al clic

La causa más frecuente es que el recuento y el clic se calculan con dos lógicas distintas. Un caso típico: el comerciante agrupa varios valores parecidos bajo una misma etiqueta (por ejemplo, «Rojo» para las variantes Carmesí, Escarlata y Burdeos del catálogo). Si el recuento suma el número de apariciones de cada variante, mientras que el clic aplica «debe tener todas estas variantes a la vez» en lugar de «debe tener al menos una de estas variantes», la cifra mostrada y la cifra obtenida responden a dos preguntas distintas. La regla que mantiene todo coherente es sencilla de enunciar y fácil de romper en el código: el recuento debe responder exactamente a la misma pregunta que aplicará el clic, no a una pregunta parecida.

Una forma correcta de resolverlo, comprobada en varios buscadores (el driver nativo de PrestaShop y Elasticsearch), consiste en tratar desde el principio un grupo de valores como un único conjunto: el recuento pasa a ser un solo «contar los productos distintos que tienen al menos uno de estos valores» (un COUNT(DISTINCT ...) en la base de datos, o una agregación específica en un buscador como Elasticsearch), y el clic aplica exactamente la misma condición. La cifra mostrada deja de ser una suma que puede prometer de más y pasa a ser la unión real, la misma que produce el clic.

Existe también una opción honesta que conviene conocer: con Meilisearch, para los valores agrupados, la cifra junto al filtro sencillamente no se muestra, en lugar de arriesgarse a mostrar una falsa. Es una decisión de diseño declarada en el panel de ajustes del comerciante, no un límite oculto. En cuestión de confianza, un filtro sin cifra siempre es mejor que un filtro con una cifra falsa.

El coste de una cifra siempre correcta

Aunque la lógica sea correcta, calcular un recuento exacto para cada valor de cada filtro tiene un coste real, que depende mucho del buscador utilizado. Con un buscador externo como Elasticsearch o Meilisearch, los recuentos llegan con la misma consulta que calcula los resultados, de modo que el sobrecoste es mínimo. Con el buscador nativo de PrestaShop, que trabaja en la base de datos de la tienda, cada valor de cada filtro puede necesitar su propia consulta de recuento.

En un catálogo de 200.000 productos con unos 2.250 grupos de atributos y características, desactivar el recuento exacto de los filtros (mostrar la lista de valores disponibles sin la cifra al lado) hizo pasar una página de categoría con un filtro activo de 43,3 segundos a 11,9 segundos, y solo en las facetas de características y de atributos de 6,8 y 5,4 segundos respectivamente a 15 y 19 milisegundos. Estas cifras cuentan una historia sencilla: ese pequeño número entre paréntesis, en un catálogo grande con un buscador limitado a la base de datos, puede costar más que todo el resto de la página junto.

Qué hacer, en concreto

• En un catálogo de unos pocos miles de productos, los recuentos exactos casi siempre compensan su coste: conserve el recuento.
• En un catálogo grande con el buscador nativo como única opción, plantéese si conviene desactivar los recuentos exactos (mostrando solo la lista de valores disponibles) o pasar a un buscador externo que los calcule sin sobrecoste.
• Si usa filtros con valores agrupados (varias variantes bajo una misma etiqueta), pregunte explícitamente cómo se gestionan cuando «todos los filtros deben coincidir a la vez» (modo Y): es el caso en el que suma y unión más divergen, y el que un cliente nota primero.
• Prefiera siempre un filtro que no muestre ninguna cifra a un filtro que muestre una falsa. Si un módulo de búsqueda no puede ofrecer un recuento exacto en una situación dada, lo correcto es ocultarlo, no adivinarlo.

En resumen

Una cifra falsa junto a un filtro no es un detalle gráfico: es la señal de que el recuento y el clic responden a dos preguntas distintas y, en un catálogo grande con el buscador equivocado, también puede ser la parte más costosa de la página. En cll_essearch hemos tratado este problema de raíz, con un cálculo único compartido por el recuento y por el clic, en el driver nativo, Elasticsearch, OpenSearch y Meilisearch, y con la posibilidad de desactivar los recuentos cuando el catálogo es demasiado grande para que merezca la pena calcularlos en tiempo real. Si un cliente le ha escrito alguna vez «el filtro decía una cosa y luego no encontré nada», es probable que este sea su problema.

Búsqueda Elasticsearch y Navegación por FacetasBúsqueda ultrarrápida y tolerante a errores de tecleo con navegación por facetas moderna en panel modal, con e…99,99 €Ver producto