Wie viel vom Traffic Ihres Onlineshops stammt nicht von Menschen
Die Zahl, die nicht stimmte
Die Statistiken von PrestaShop erfassen jede Anfrage, die den Shop erreicht, als „Besuch“, es sei denn, ein interner Filter erkennt sie zuvor als automatisches Programm und sortiert sie aus. Am ersten Tag, an dem wir die Zahlen unseres eigenen Shops wirklich überprüft haben, zeigte die Statistiktabelle 43.478 Besuche. Die echten Menschen waren an diesem Tag etwa 300. Hundertfünfundvierzig falsche Besucher auf einen echten.
Das ist kein seltener Fall: Es passiert, wenn der in PrestaShop eingebaute Bot-Filter nie aktualisiert wird. Und die Tabelle, die sich mit diesen Zahlen füllt, ist nicht umsonst: In unserem Shop hatte sie 1,3 GB überschritten, eine nutzlose Zeile nach der anderen. Nach der Bereinigung war sie auf 24 MB geschrumpft.
Warum der eingebaute Filter nicht mehr genügt
PrestaShop bringt bereits eine Methode zur Erkennung von Bots mit, Connection::isBot(), die den User-Agent der Anfrage mit einer im Code hinterlegten Liste vergleicht. Das Problem ist, dass diese Liste nie aufgefrischt wurde: Sie enthält Namen wie Scooter (den Bot von AltaVista) und andere Suchmaschinen, die seit Jahren eingestellt sind, aber keinen der Bots, die in jüngerer Zeit zum Training von KI-Modellen gebaut wurden, und auch nicht die aktuellen Versionen der Bots der Suchmaschinen, die es heute noch gibt. Ein Filter, der für das Web von vor fünfzehn Jahren gebaut wurde, lässt genau die Programme ungeprüft durch, die heute den meisten automatischen Traffic erzeugen.
Praktisch heißt das: Die „Besucherzahl“ eines nicht gepflegten PrestaShop-Shops misst keine Menschen, sondern Menschen plus einen oft überwiegenden Anteil an Programmen, die der Filter nicht erkennt. Entscheidungen, die auf dieser Zahl beruhen, vom Werbebudget bis zum Urteil über eine Seite, die „läuft“ oder „nicht konvertiert“, gehen von falschen Daten aus.
Der Fehler, den wir zuerst selbst gemacht haben
Diese Liste zu aktualisieren scheint harmlos: eine generische Regel hinzufügen, die das Wort „bot“ im User-Agent erkennt, dazu die Eigennamen der Bots, die den Shop tatsächlich besuchen (Suchmaschinen, Meta, die verschiedenen KI-Bots). Die erste Version, die wir geschrieben haben, besagte im Grunde: „Enthält der User-Agent bot, ist es ein Bot.“ Sie funktionierte einwandfrei, bis auf ein Detail: Sie erkannte auch das Ende des Wortes CUBOT, einer Marke von Android-Telefonen.
PrestaShop verwendet dasselbe isBot() nicht nur für die Statistiken, sondern auch im Controller, der Produkte in den Warenkorb legt: Sieht eine Anfrage nach einem Bot aus, wird das Hinzufügen zum Warenkorb stillschweigend ignoriert, und der Shop antwortet trotzdem „erledigt“, ohne sichtbaren Fehler. Ergebnis: Ein echter Kunde mit einem CUBOT-Telefon klickte auf „In den Warenkorb“, sah die Bestätigungsmeldung, und der Warenkorb blieb leer. Kein Fehler in den Logs, keine Warnung: nur ein Kunde, der nichts kaufen konnte und wahrscheinlich nicht wusste, warum.
Entdeckt haben wir es, als wir die neue Regel über 153.113 echte Logzeilen aus fünf Tagen Traffic des Shops laufen ließen und verglichen, wie viele Bots die alte Regel im Vergleich zur neuen erfasste: Der Unterschied entsprach genau den 31 Anfragen eines CUBOT-Telefons. Wir haben es mit einer ausdrücklichen Ausnahme für diese Marke behoben und denselben Vergleich noch einmal laufen lassen, bevor wir die Regel in Produktion genommen haben. Das ist die Art von Fehler, die nur auftaucht, wenn man nach ihr sucht: Ein zu strenger Filter erzeugt keinen Fehler, er erzeugt einen Kunden, der geht, ohne Ihnen zu sagen, warum.
Ein funktionierender Filter regelt nicht alles
Die ankommenden Bots zu erkennen genügt nicht, wenn etwas anderes ihnen danach ausdrücklich sagt, dass sie eintreten dürfen. Im selben Zeitraum zeigte unser Apache-Log an einem einzigen Tag 38.144 Anfragen von einem einzigen Bot, dem, den Meta zum Training seiner Modelle verwendet: 78 % des gesamten Traffics des Tages. Das waren keine verstreuten Zugriffe: Der Bot war in eine Schleife geraten, weil er einem Rücksprungparameter nach dem Login folgte, der sich bei jedem Durchlauf in sich selbst verschachtelte, und jede dieser Anfragen war eine vollständig generierte PrestaShop-Seite, keine leichte Antwort.
Die Ursache war kein Fehler des Bots: Es war eine robots.txt-Datei, die im Rahmen einer Konfiguration, die die „guten“ KI-Bots willkommen heißen sollte, am Ende auch diesen einen eingelassen hatte, der draußen bleiben sollte, weil er Modelle trainiert, statt Traffic zurückzubringen. Nachdem die Konfiguration korrigiert war, ging der Traffic dieses Bots in fünfzehn Stunden um 95 % zurück. Auch hier betrifft die Lehre nicht den Bot: Ein „guter“ Filter, an einer Stelle geschrieben, kann durch eine an anderer Stelle geschriebene Regel widerlegt werden, und das erfährt man nur, indem man die Logs wirklich liest, statt der Konfiguration auf dem Papier zu vertrauen.
Was Sie prüfen sollten, bevor Sie Ihren Statistiken vertrauen
- Betrachten Sie die Zahl der „Besuche“ nicht isoliert: Vergleichen Sie sie für denselben Tag mit einer unabhängigen Quelle (zum Beispiel einem Analysetool, das im Browser läuft). Beträgt der Abstand eine Größenordnung, macht der Bot-Filter seine Arbeit nicht.
- Wenn Sie eine eigene Liste erkannter Bots pflegen, testen Sie sie vor dem Produktivbetrieb an einer echten Stichprobe von Logs und nicht nur an ein paar von Hand getippten User-Agents: Eine Telefonmarke, eine Bibliothek, ein legitimer HTTP-Client können zufällig das Wort enthalten, das einen Bot kennzeichnet.
- Prüfen Sie, ob der Filter, der Ihre Statistiken speist, derselbe ist, der entscheidet, ob ein Kunde kaufen kann. Falls ja, verfälscht ein zu strenger Filter nicht nur eine Zahl: Er blockiert stillschweigend eine Bestellung.
- Lesen Sie die Server-Logs, nicht nur die Konfiguration: Eine Regel, die einem Bot die Tür öffnen soll, kann sie am Ende einem anderen öffnen, und nur der echte Traffic beweist es.
- Bedenken Sie, dass die Liste der zu erkennenden Bots nie fertig ist: Ständig tauchen neue Bots auf, vor allem für das Training von KI, und eine einmal geschriebene und nie angefasste Liste ist in wenigen Monaten veraltet, nicht erst in Jahren.
Kurz gesagt
Die Zahl der „Besuche“, die ein Onlineshop in seinem Back Office anzeigt, ist keine neutrale Angabe: Sie hängt von einem Filter ab, der gepflegt werden muss, und ein schlecht gepflegter Filter kann sich in zwei entgegengesetzte Richtungen irren, indem er zu viele Bots in die Statistiken lässt oder zu viele echte Kunden daran hindert, den Warenkorb zu nutzen. In unserem Shop lag das Verhältnis an dem Tag, an dem wir zum ersten Mal hingesehen haben, bei 145 falschen Besuchen auf einen echten Menschen. Die Bereinigung erforderte kein kompliziertes Projekt, aber sie erforderte, die Logs wirklich zu lesen, zuerst einen Fehler zu korrigieren, den wir selbst gemacht hatten, und alles an echten Daten erneut zu prüfen, bevor man sich darauf verlässt.
