Welk deel van het verkeer van uw webwinkel is niet menselijk

Het cijfer dat niet klopte

De statistieken van PrestaShop registreren elk verzoek dat de webwinkel bereikt als een “bezoek”, tenzij een intern filter het eerst herkent als een automatisch programma en terzijde schuift. Op de eerste dag dat we de cijfers van onze eigen webwinkel echt controleerden, gaf de statistiektabel 43.478 bezoeken aan. De echte mensen waren diezelfde dag ongeveer 300. Honderdvijfenveertig valse bezoekers op één echte.

Dat is geen zeldzaam geval: zo gaat het wanneer het in PrestaShop ingebouwde botfilter nooit wordt bijgewerkt. En de tabel die zich met die cijfers vult, is niet gratis: in onze webwinkel was ze gegroeid tot meer dan 1,3 GB, nutteloze regel na nutteloze regel. Na de opschoning was ze teruggebracht tot 24 MB.

Waarom het ingebouwde filter niet meer volstaat

PrestaShop heeft al een methode om robots te herkennen, Connection::isBot(), die werkt door de user agent van het verzoek te vergelijken met een lijst die in de code is geschreven. Het probleem is dat die lijst nooit is ververst: ze bevat namen als Scooter (de robot van AltaVista) en andere zoekmachines die al jaren zijn opgeheven, maar geen enkele van de recentere robots die zijn gebouwd om modellen voor kunstmatige intelligentie te trainen, en ook niet de actuele versies van de robots van de zoekmachines die nog bestaan. Een filter dat is ontworpen voor het web van vijftien jaar geleden, laat juist de programma’s die tegenwoordig het meeste automatische verkeer genereren ongemerkt door.

Het praktische gevolg is dat het “aantal bezoeken” van een niet onderhouden PrestaShop-webwinkel geen mensen meet: het meet mensen plus een vaak overheersend deel programma’s die het filter niet kan herkennen. Beslissingen die op dat cijfer worden gebaseerd, van het advertentiebudget tot het oordeel over een pagina die “werkt” of “niet converteert”, vertrekken vanuit een onjuist gegeven.

De fout die we zelf als eerste hebben gemaakt

Die lijst bijwerken lijkt onschuldig: een generieke regel toevoegen die het woord “bot” in de user agent herkent, plus de eigennamen van de robots die de webwinkel echt bezoeken (zoekmachines, Meta, de verschillende AI-robots). De eerste versie die we schreven, zei grofweg: “als de user agent bot bevat, is het een robot”. Ze werkte perfect, op één detail na: ze herkende ook het einde van het woord CUBOT, een merk Android-telefoons.

PrestaShop gebruikt dezelfde isBot() niet alleen voor de statistieken, maar ook in de controller die producten aan de winkelwagen toevoegt: als een verzoek van een robot lijkt te komen, wordt het toevoegen aan de winkelwagen stilzwijgend genegeerd en antwoordt de webwinkel toch “gelukt”, zonder zichtbare fout. Gevolg: een echte klant met een CUBOT-telefoon klikte op “in winkelwagen”, zag de bevestiging en de winkelwagen bleef leeg. Geen fout in de logs, geen waarschuwing: alleen een klant die niets kon kopen en waarschijnlijk niet wist waarom.

We ontdekten het door de nieuwe regel los te laten op 153.113 echte logregels van vijf dagen verkeer van de webwinkel, en te vergelijken hoeveel robots de oude regel ving ten opzichte van de nieuwe: het verschil kwam precies overeen met de 31 verzoeken van één CUBOT-telefoon. We hebben het verholpen met een expliciete uitzondering voor dit merk en dezelfde vergelijking opnieuw uitgevoerd voordat de regel in productie ging. Het is het soort bug dat alleen opduikt als u ernaar zoekt: een te streng filter geeft geen fout, het levert een klant op die weggaat zonder u te zeggen waarom.

Een filter dat werkt, lost niet alles op

Robots herkennen die binnenkomen, is niet genoeg als iets anders ze daarna uitdrukkelijk zegt binnen te komen. In dezelfde periode toonde ons Apache-log op één dag 38.144 verzoeken van één enkele robot, die welke Meta gebruikt om zijn modellen te trainen: 78% van al het verkeer van die dag. Het waren geen verspreide toegangen: de robot was in een lus beland door een parameter voor terugkeer na het inloggen te volgen die bij elke ronde in zichzelf werd genest, en elk van die verzoeken was een volledig gegenereerde PrestaShop-pagina, geen lichte respons.

De oorzaak was geen bug van de robot: het was een bestand robots.txt dat, binnen een configuratie bedoeld om de “goede” AI-robots te verwelkomen, ook deze had binnengelaten, een robot die buiten zou moeten blijven omdat hij modellen traint in plaats van verkeer terug te sturen. Nadat de configuratie was gecorrigeerd, daalde het verkeer van deze robot in vijftien uur met 95%. Ook hier gaat de les niet over de robot: een “goed” filter dat op de ene plek is geschreven, kan worden tegengesproken door een regel die elders staat, en de enige manier om dat te weten is de logs echt te lezen en niet te vertrouwen op de configuratie op papier.

Wat u moet controleren voordat u uw statistieken vertrouwt

• Kijk niet naar het aantal “bezoeken” op zichzelf: vergelijk het voor dezelfde dag met een onafhankelijke bron (bijvoorbeeld een analysetool aan de kant van de browser). Is het verschil een orde van grootte, dan doet het botfilter zijn werk niet.
• Als u een eigen lijst van herkende robots bijhoudt, test die dan op een echte steekproef van logs voordat u haar in productie neemt, en niet alleen op een paar met de hand getypte user agents: een telefoonmerk, een softwarebibliotheek of een legitieme HTTP-client kan bij toeval het woord bevatten dat een robot identificeert.
• Controleer of het filter dat uw statistieken voedt hetzelfde is als het filter dat beslist of een klant kan kopen. Is dat zo, dan vervuilt een te streng filter niet alleen een cijfer: het blokkeert stilzwijgend een bestelling.
• Lees de logs van de server, niet alleen de configuratie: een regel die bedoeld is om de deur voor de ene robot open te zetten, kan hem uiteindelijk voor een andere openen, en alleen het echte verkeer bewijst dat.
• Houd in gedachten dat de lijst van te herkennen robots nooit af is: er verschijnen voortdurend nieuwe robots, vooral voor het trainen van AI, en een lijst die eenmaal is geschreven en daarna nooit meer wordt aangepast, is in enkele maanden verouderd, niet in enkele jaren.

Kort samengevat

Het aantal “bezoeken” dat een webwinkel in zijn back-office toont, is geen neutraal gegeven: het hangt af van een filter dat onderhouden moet worden, en een slecht onderhouden filter kan zich in twee tegengestelde richtingen vergissen, door te veel robots in de statistieken toe te laten of door te veel echte klanten te beletten de winkelwagen te gebruiken. In onze webwinkel was de verhouding op de dag dat we voor het eerst keken 145 valse bezoeken op één echt persoon. De opschoning vergde geen ingewikkeld project, maar wel dat we de logs echt lazen, eerst een fout verhielpen die we zelf hadden gemaakt en alles opnieuw controleerden op echte gegevens voordat we erop vertrouwden.