Quanto del traffico del tuo negozio online non è fatto da persone

Il numero che non tornava

Le statistiche di PrestaShop registrano ogni richiesta che arriva al negozio come una "visita", a meno che un filtro interno non la riconosca come un programma automatico e la scarti. Il giorno in cui abbiamo controllato per la prima volta i numeri del nostro negozio, la tabella delle statistiche diceva 43.478 visite. Le persone vere, quello stesso giorno, erano circa 300. Centoquarantacinque "visitatori" finti per ogni visitatore reale.

Non è un caso limite raro: è quello che succede quando il filtro anti-robot integrato in PrestaShop non viene mai aggiornato. E la tabella che si riempie con quei numeri non è gratis: sul nostro negozio pesava oltre 1,3 GB, cresciuta giorno dopo giorno con righe che non servivano a nessuno. Dopo la pulizia era scesa a 24 MB.

Perché il filtro del core non basta più

PrestaShop ha già un metodo che dovrebbe riconoscere i robot, Connection::isBot(), e funziona confrontando lo user agent della richiesta con un elenco scritto dentro il codice. Il problema è che quell'elenco non è mai stato aggiornato: dentro ci sono nomi come Scooter (il crawler di AltaVista) e altri motori di ricerca chiusi da anni, ma non c'è nessuno dei raccoglitori nati negli ultimi tempi per addestrare le intelligenze artificiali, e non ci sono nemmeno versioni più recenti dei crawler dei motori che esistono ancora oggi. Un filtro pensato per il web di quindici anni fa lascia entrare, senza riconoscerli, proprio i programmi che oggi generano più traffico automatico.

La conseguenza pratica è che "numero di visite" in un negozio PrestaShop non aggiornato non misura le persone: misura le persone più una quota, spesso maggioritaria, di programmi che il filtro non sa riconoscere. Decisioni prese guardando quel numero, dal budget pubblicitario al giudizio su una pagina che "funziona" o "non converte", partono da un dato sbagliato.

L'errore che abbiamo fatto noi, per primi

Aggiornare quell'elenco sembra un lavoro innocuo: si aggiunge una regola generica che riconosce la parola "bot" nello user agent, più i nomi propri dei crawler che passano davvero dal negozio (quelli dei motori di ricerca, quelli di Meta, quelli delle intelligenze artificiali). La prima versione che abbiamo scritto diceva, semplificando, "se lo user agent contiene bot, è un robot". Funzionava benissimo, tranne per un dettaglio: prendeva anche la fine della parola CUBOT, un marchio di telefoni Android.

PrestaShop usa lo stesso isBot() non solo per le statistiche, ma anche dentro il controller che aggiunge i prodotti al carrello: se la richiesta sembra fatta da un robot, l'aggiunta al carrello viene saltata in silenzio, e il sito risponde comunque "fatto", senza nessun errore visibile. Risultato: un cliente vero con un telefono CUBOT cliccava "aggiungi al carrello", vedeva il messaggio di conferma, e il carrello restava vuoto. Nessun errore nei log, nessun avviso: solo un cliente che non riusciva a comprare e probabilmente non capiva perché.

L'abbiamo trovato passando la nuova regola su 153.113 righe vere di cinque giorni di log del negozio, confrontando quanti robot riconosceva la regola vecchia e quanti la nuova: la differenza erano esattamente le 31 richieste del telefono CUBOT. Corretto scrivendo un'eccezione esplicita per quel marchio, e riprovato lo stesso confronto prima di mettere la regola in produzione. È il genere di errore che si nota solo se lo si va a cercare: un filtro troppo severo non genera un errore, genera un cliente che se ne va senza dire perché.

Il filtro può anche funzionare bene e il problema restare

Riconoscere i robot in arrivo non basta se poi si dice loro esplicitamente di entrare. Nello stesso periodo, il log di Apache del negozio mostrava in un giorno 38.144 richieste di un unico crawler, quello che Meta usa per addestrare i propri modelli: il 78% di tutto il traffico della giornata. Non erano richieste sparse: il crawler era entrato in un ciclo, seguendo un parametro di ritorno al login che si annidava dentro se stesso a ogni passaggio, e ogni richiesta era una pagina PrestaShop generata per intero, non una risposta rapida.

La causa non era un difetto del crawler: era un file robots.txt che, per una configurazione pensata per aprire ai raccoglitori "buoni" delle intelligenze artificiali, aveva finito per aprire anche a quello specifico, che invece va tenuto fuori perché addestra modelli, non riporta traffico. Corretta la configurazione, il traffico di quel crawler è sceso del 95% nelle quindici ore successive. Anche qui la lezione non riguarda il crawler: riguarda il fatto che un filtro "buono" scritto in un punto può essere scavalcato da una regola scritta altrove, e l'unico modo per saperlo è guardare davvero i log, non fidarsi della configurazione sulla carta.

Cosa controllare prima di fidarvi delle vostre statistiche

• Non guardate il numero di "visite" da solo: confrontatelo con una fonte indipendente (per esempio uno strumento di analisi lato browser) per lo stesso giorno. Se la differenza è di un ordine di grandezza, il filtro robot non sta facendo il suo lavoro.
• Se aggiornate voi stessi l'elenco dei robot riconosciuti, provatelo su un campione vero di log prima di metterlo in produzione, non solo su qualche user agent scritto a mano: un marchio di telefono, una libreria, un client HTTP legittimo possono contenere per caso la stessa parola che identifica un robot.
• Controllate se il filtro che alimenta le statistiche è lo stesso che decide se un cliente può comprare. Se lo è, un filtro troppo severo non sporca solo un numero: blocca un ordine, senza errore visibile.
• Guardate i log del server, non solo la configurazione: una regola pensata per aprire la porta a un crawler può finire per aprirla a un altro, e solo il traffico reale lo dimostra.
• Tenete presente che l'elenco dei robot da riconoscere non è mai definitivo: nascono nuovi raccoglitori, in particolare per le intelligenze artificiali, e un elenco scritto una volta e mai più toccato torna vecchio nel giro di mesi, non di anni.

In sintesi

Il numero di "visite" che un negozio online mostra in back office non è un dato neutro: dipende da un filtro che va mantenuto, e un filtro mantenuto male può sbagliare in due direzioni opposte, lasciare entrare troppi robot nelle statistiche o bloccare troppi clienti veri dal carrello. Sul nostro negozio, il giorno in cui abbiamo guardato per la prima volta, il rapporto era di 145 visite finte per ogni persona vera. Ripulirlo non ha richiesto un progetto complicato, ma ha richiesto di guardare i log davvero, correggere un errore che avevamo fatto noi per primi, e ricontrollare tutto su dati veri prima di fidarci.