Qué parte del tráfico de su tienda online no es humana

La cifra que no cuadraba

Las estadísticas de PrestaShop registran como «visita» cada petición que llega a la tienda, salvo que un filtro interno la reconozca antes como un programa automático y la descarte. El primer día en que comprobamos de verdad las cifras de nuestra propia tienda, la tabla de estadísticas indicaba 43.478 visitas. Las personas reales, ese mismo día, eran unas 300. Ciento cuarenta y cinco visitantes falsos por cada uno real.

No es un caso raro: es lo que ocurre cuando el filtro de robots integrado en PrestaShop no se actualiza nunca. Y la tabla que se llena con esas cifras no sale gratis: en nuestra tienda había superado los 1,3 GB, una fila inútil tras otra. Después de la limpieza, bajó a 24 MB.

Por qué el filtro integrado ya no basta

PrestaShop ya ofrece un método destinado a reconocer los robots, Connection::isBot(), que funciona comparando el user agent de la petición con una lista escrita en el código. El problema es que esa lista nunca se ha renovado: contiene nombres como Scooter (el robot de AltaVista) y otros buscadores cerrados hace años, pero ninguno de los robots construidos más recientemente para entrenar modelos de inteligencia artificial, ni las versiones actuales de los robots de los buscadores que todavía existen hoy. Un filtro concebido para la web de hace quince años deja pasar sin reconocerlos justamente los programas que hoy generan más tráfico automático.

La consecuencia práctica es que el «número de visitas» de una tienda PrestaShop sin mantenimiento no mide personas: mide personas más una parte, a menudo mayoritaria, de programas que el filtro no sabe reconocer. Las decisiones que se toman mirando esa cifra, desde el presupuesto publicitario hasta el juicio sobre una página que «funciona» o «no convierte», parten de un dato falso.

El error que cometimos nosotros mismos, el primero

Actualizar esa lista parece inocuo: añadir una regla genérica que reconozca la palabra «bot» en el user agent, más los nombres propios de los robots que visitan realmente la tienda (buscadores, Meta, los distintos robots de IA). La primera versión que escribimos decía, a grandes rasgos, «si el user agent contiene bot, es un robot». Funcionaba perfectamente, salvo por un detalle: también reconocía el final de la palabra CUBOT, una marca de teléfonos Android.

PrestaShop utiliza ese mismo isBot() no solo para las estadísticas, sino también en el controlador que añade los productos al carrito: si una petición parece provenir de un robot, la adición al carrito se ignora en silencio y la tienda responde igualmente «hecho», sin ningún error visible. Resultado: un cliente real con un teléfono CUBOT pulsaba «añadir al carrito», veía el mensaje de confirmación y el carrito seguía vacío. Ningún error en los logs, ninguna advertencia: solo un cliente que no podía comprar nada y probablemente no sabía por qué.

Lo descubrimos al pasar la nueva regla por 153.113 líneas de logs reales correspondientes a cinco días de tráfico de la tienda, comparando cuántos robots atrapaba la regla antigua frente a la nueva: la diferencia correspondía exactamente a las 31 peticiones de un teléfono CUBOT. Lo corregimos con una excepción explícita para esa marca y repetimos la misma comparación antes de poner la regla en producción. Es el tipo de error que solo aparece si se busca: un filtro demasiado estricto no genera ningún error, produce un cliente que se marcha sin decirle por qué.

Un filtro que funciona no lo resuelve todo

Reconocer a los robots que llegan no basta si otra cosa les dice después, de forma explícita, que entren. En el mismo periodo, nuestro log de Apache mostraba 38.144 peticiones en un solo día procedentes de un único robot, el que Meta utiliza para entrenar sus modelos: el 78 % de todo el tráfico de la jornada. No eran accesos dispersos: el robot había caído en un bucle, siguiendo un parámetro de retorno tras el inicio de sesión que se anidaba sobre sí mismo en cada pasada, y cada una de esas peticiones era una página de PrestaShop generada por completo, no una respuesta ligera.

La causa no era un error del robot: era un archivo robots.txt que, en el marco de una configuración destinada a acoger a los «buenos» robots de IA, había acabado acogiendo también a ese, el que debería quedarse fuera porque entrena modelos en lugar de devolver tráfico. Una vez corregida la configuración, el tráfico de ese robot bajó un 95 % en quince horas. Una vez más, la lección no tiene que ver con el robot: un «buen» filtro escrito en un sitio puede quedar contradicho por una regla escrita en otro, y la única manera de saberlo es leer de verdad los logs, no fiarse de la configuración sobre el papel.

Qué comprobar antes de fiarse de sus estadísticas

• No mire el número de «visitas» de forma aislada: compárelo con una fuente independiente (una herramienta de análisis en el navegador, por ejemplo) para el mismo día. Si la diferencia es de un orden de magnitud, el filtro de robots no está haciendo su trabajo.
• Si mantiene su propia lista de robots reconocidos, pruébela con una muestra real de logs antes de ponerla en producción, no solo con unos cuantos user agents escritos a mano: una marca de teléfono, una biblioteca o un cliente HTTP legítimo pueden contener por casualidad la palabra que identifica a un robot.
• Compruebe si el filtro que alimenta sus estadísticas es el mismo que decide si un cliente puede comprar. Si es así, un filtro demasiado estricto no solo contamina una cifra: bloquea en silencio un pedido.
• Lea los logs del servidor, no solo la configuración: una regla pensada para abrir la puerta a un robot puede acabar abriéndola a otro, y solo el tráfico real lo demuestra.
• Tenga presente que la lista de robots que reconocer nunca está terminada: aparecen robots nuevos sin cesar, sobre todo para el entrenamiento de IA, y una lista escrita una vez y nunca retocada queda obsoleta en pocos meses, no en pocos años.

En pocas palabras

El número de «visitas» que una tienda online muestra en su back office no es un dato neutro: depende de un filtro que hay que mantener, y un filtro mal mantenido puede equivocarse en dos direcciones opuestas, dejando entrar demasiados robots en las estadísticas o impidiendo que demasiados clientes reales usen el carrito. En nuestra tienda, el día en que miramos por primera vez, la proporción era de 145 visitas falsas por cada persona real. La limpieza no exigió un proyecto complicado, pero sí leer de verdad los logs, corregir primero un error que habíamos cometido nosotros mismos y volver a comprobarlo todo con datos reales antes de fiarse.