Jaka część ruchu w Państwa sklepie internetowym to nie ludzie

Liczba, która się nie zgadzała

Statystyki PrestaShop zapisują jako „wizytę” każde żądanie, które dociera do sklepu, chyba że wewnętrzny filtr najpierw rozpozna je jako program automatyczny i odrzuci. Pierwszego dnia, gdy naprawdę sprawdziliśmy liczby w naszym własnym sklepie, tabela statystyk wskazywała 43 478 wizyt. Prawdziwych osób tego samego dnia było około 300. Stu czterdziestu pięciu fałszywych odwiedzających na jednego prawdziwego.

To nie jest rzadki przypadek: tak dzieje się, gdy wbudowany w PrestaShop filtr botów nigdy nie jest aktualizowany. A tabela, która wypełnia się tymi liczbami, nie jest darmowa: w naszym sklepie przekroczyła 1,3 GB, wiersz po bezużytecznym wierszu. Po czyszczeniu spadła do 24 MB.

Dlaczego wbudowany filtr już nie wystarcza

PrestaShop ma już metodę przeznaczoną do rozpoznawania botów, Connection::isBot(), która działa, porównując user agent żądania z listą zapisaną w kodzie. Problem w tym, że ta lista nigdy nie była odświeżana: zawiera nazwy takie jak Scooter (robot AltaVista) i innych wyszukiwarek zamkniętych od lat, ale żadnego z botów zbudowanych niedawno do trenowania modeli sztucznej inteligencji ani aktualnych wersji botów wyszukiwarek, które nadal istnieją. Filtr zaprojektowany dla sieci sprzed piętnastu lat przepuszcza bez rozpoznania właśnie te programy, które dziś generują najwięcej ruchu automatycznego.

Praktyczna konsekwencja jest taka, że „liczba wizyt” w nieutrzymywanym sklepie PrestaShop nie mierzy ludzi: mierzy ludzi plus część, często większościową, składającą się z programów, których filtr nie umie rozpoznać. Decyzje podejmowane na podstawie tej liczby, od budżetu reklamowego po ocenę strony, która „działa” lub „nie konwertuje”, opierają się na błędnych danych.

Błąd, który popełniliśmy sami, jako pierwsi

Aktualizacja tej listy wydaje się banalna: dodać ogólną regułę rozpoznającą słowo „bot” w user agencie oraz nazwy własne botów, które naprawdę odwiedzają sklep (wyszukiwarki, Meta, różne boty AI). Pierwsza napisana przez nas wersja mówiła w skrócie: „jeśli user agent zawiera bot, to jest robot”. Działała doskonale, z jednym szczegółem: rozpoznawała także końcówkę słowa CUBOT, marki telefonów z Androidem.

PrestaShop używa tej samej metody isBot() nie tylko do statystyk, ale także w kontrolerze, który dodaje produkty do koszyka: jeśli żądanie wygląda na pochodzące od robota, dodanie do koszyka jest po cichu pomijane, a sklep mimo to odpowiada „gotowe”, bez żadnego widocznego błędu. Skutek: prawdziwy klient z telefonem CUBOT klikał „dodaj do koszyka”, widział komunikat potwierdzenia, a koszyk pozostawał pusty. Żadnego błędu w logach, żadnego ostrzeżenia: po prostu klient, który nic nie mógł kupić i prawdopodobnie nie wiedział dlaczego.

Odkryliśmy to, uruchamiając nową regułę na 153 113 wierszach prawdziwych logów z pięciu dni ruchu w sklepie i porównując, ilu robotów wyłapywała stara reguła, a ilu nowa: różnica odpowiadała dokładnie 31 żądaniom telefonu CUBOT. Poprawiliśmy to jawnym wyjątkiem dla tej marki i powtórzyliśmy to samo porównanie przed wdrożeniem reguły na produkcję. To rodzaj błędu, który ujawnia się tylko wtedy, gdy się go szuka: zbyt surowy filtr nie generuje błędu, tylko klienta, który odchodzi, nie mówiąc, dlaczego.

Działający filtr nie rozwiązuje wszystkiego

Rozpoznawanie przychodzących robotów nie wystarcza, jeśli coś innego następnie wprost im mówi, żeby weszły. W tym samym okresie nasz log Apache pokazywał 38 144 żądań w ciągu jednej doby od jednego robota, tego, którego Meta używa do trenowania swoich modeli: 78% całego ruchu tego dnia. Nie były to rozproszone wejścia: robot wpadł w pętlę, podążając za parametrem powrotu po zalogowaniu, który przy każdym przejściu zagnieżdżał się w samym sobie, a każde z tych żądań było w pełni wygenerowaną stroną PrestaShop, a nie lekką odpowiedzią.

Przyczyną nie był błąd robota: był nią plik robots.txt, który w ramach konfiguracji przeznaczonej do przyjmowania „dobrych” robotów AI przyjął także tego, którego powinno się trzymać na zewnątrz, bo trenuje modele zamiast przysyłać ruch. Po poprawieniu konfiguracji ruch tego robota spadł o 95% w ciągu piętnastu godzin. I tu lekcja nie dotyczy robota: „dobry” filtr zapisany w jednym miejscu może zostać zaprzeczony przez regułę zapisaną gdzie indziej, a jedynym sposobem, żeby to wiedzieć, jest faktyczne czytanie logów, a nie ufanie konfiguracji na papierze.

Co należy sprawdzić, zanim zaufają Państwo swoim statystykom

• Nie należy patrzeć na liczbę „wizyt” w oderwaniu: trzeba ją porównać z niezależnym źródłem (na przykład z narzędziem analitycznym działającym w przeglądarce) z tego samego dnia. Jeśli różnica sięga rzędu wielkości, filtr botów nie wykonuje swojej pracy.
• Jeśli prowadzą Państwo własną listę rozpoznawanych robotów, należy przetestować ją na prawdziwej próbce logów przed wdrożeniem na produkcję, a nie tylko na kilku ręcznie wpisanych user agentach: marka telefonu, biblioteka, legalny klient HTTP mogą przypadkiem zawierać słowo identyfikujące robota.
• Należy sprawdzić, czy filtr zasilający statystyki jest tym samym, który decyduje, czy klient może kupić. Jeśli tak, zbyt surowy filtr nie zafałszowuje tylko liczby: po cichu blokuje zamówienie.
• Należy czytać logi serwera, a nie tylko konfigurację: reguła mająca otworzyć drzwi jednemu robotowi może otworzyć je innemu, a dowodzi tego dopiero rzeczywisty ruch.
• Warto pamiętać, że lista robotów do rozpoznawania nigdy nie jest skończona: stale pojawiają się nowe roboty, zwłaszcza do trenowania AI, a lista napisana raz i nigdy nie poprawiana staje się przestarzała w ciągu kilku miesięcy, a nie kilku lat.

W skrócie

Liczba „wizyt”, którą sklep internetowy wyświetla w panelu administracyjnym, nie jest daną neutralną: zależy od filtra, który trzeba utrzymywać, a źle utrzymywany filtr może się mylić w dwóch przeciwnych kierunkach, wpuszczając do statystyk zbyt wiele robotów albo uniemożliwiając zbyt wielu prawdziwym klientom korzystanie z koszyka. W naszym sklepie, w dniu, w którym spojrzeliśmy po raz pierwszy, stosunek wynosił 145 fałszywych wizyt na jedną prawdziwą osobę. Czyszczenie nie wymagało skomplikowanego projektu, ale wymagało prawdziwego czytania logów, poprawienia najpierw błędu, który popełniliśmy sami, i sprawdzenia wszystkiego na prawdziwych danych, zanim zaczęliśmy im ufać.