Markus Baersch

Software · Beratung · Lösungen

Start » Blog » Analytics

09.11.2019

Crawler und Tools machen verstärkt Gebrauch von Headless Browsern, um eine Seite vollständig zu erfassen. Dabei wird auch JavaScript ausgeführt, Cookies werden ggf. verarbeitet und auch das sonstige Verhalten entspricht möglichst dem eines "richtigen Browsers" eines echten Besuchers. Mit steigendem Aufkommen wird auch die Frage drängender, wie man die dadurch entstehenden Daten in Google Analytics erkennbar macht und behandelt. Sei es durch Segmentierung, Filter oder anderer Trennung von Daten wie z. B. Unterbinden des Trackings.

Dieser Beitrag zeigt einen möglichen Ansatz von vielen, der auf der Auswertung des User Agents und der Überprüfung bestimmter Eigenschaften von Browsern (Feature Detection) beruht.

Erkennung anhand bestehender Daten

Der erste Ansatz zur Erkennung, ob und in welchem Umfang Störungen durch rendernde Bots in den eigenen Daten zu finden sind, mag in den bereits gesammelten Daten gesucht werden. Unglücklicherweise ist aber der User Agent als komplette Information nicht mehr in Google Analytics zu finden, sondern nur noch in aufgelöster Form als Browser, Betriebssystem und Versionsangaben. Daher bleiben nur wenige Ansatzpunkte zur Erkennung. Man kann z. B. nach dem Internet Explorer 5 als Browser suchen, der in aktuellen Daten ein sicheres Zeichen gegen einen realen Besucher ist. Auch auffällig kleine Auflösungen können ein Hinweis sein.

Beides wird zwar inzwischen im Analytrix Audit berücksichtigt, liefert aber eben kein belastbares Signal. Weder ein Vorhandensein noch Ausbleiben solcher Fundstellen sagt etwas darüber aus, ob alle Besucher echt oder einige potentiell Bots sind.

Boterkennung im Analytrix Audit

Um einen "begründeten Verdacht" zu entwickeln, sind in den üblichen Daten der Webanalyse also zu wenig Anhaltspunkte vorhanden. Es ist in vielen Fällen schlichtweg zu spät, wenn der Hit schon an die Webanalyse versendet wurde. Die Erkennung muss daher schon im Browser geschehen. Das Ergebnis wird dann mit den Messdaten übertragen und gespeichert, um mit diesen gemeinsam ausgewertet werden können.

Das klingt nach Benutzerdefinierten Dimensionen? Genau richtig. Dazu gleich mehr.

Bekannte (und bekennende) Bots

Es gibt viele Dienste, die absichtlich anhand des User Agents klar erkennbar machen, dass es sich um einen Bot handelt. Dazu gehören die rendernden Crawler der Suchmaschinen wie Google und Bing oder Dienste wie der Page Speed Service, der ebenfalls am User Agent erkennbar ist. Auch Pingdom, Hubspot, Rendering- und Vorschaufunktionen vieler SEO Tools und sozialer Netzwerke gehören dazu. Selbst schlecht konfigurierte Headless Browser, die in Analytics z. B. ganz unschuldig als "Chrome" identifiziert werden, sind am User Agent noch erkennbar. Solange man noch "im Browser ist" oder den User Agent als benutzerdefinierte Dimension an Analytics überträgt, können diese Besuche erkannt und  ausgefiltert werden. Übergibt man zu diesem Zweck ausschließlich den User Agent als neues Merkmal, ist ein Filtern oder Segmentieren allerdings recht aufwändig.

Dennoch: der User Agent ist ein hilfreiches Werkzeug im Zweifelsfall, so dass es sich lohnen kann, auch diesen als Dimension zu nutzen. Die Ermittlung ist einfach, denn er kann über die JavaScript Variable window.navigator.userAgent im Google Tag Manager abgefragt und als Benutzerdefinierte Dimension übertragen werden.

Featureerkennung: "Sag mir wer Du bist und ich frage Dich nach einem Beweis"

Deutlich mehr Ausbeute verspricht die in der Einleitung genannte Erkennung bestimmter Eigenschaften einzelner Browser. Wer im User Agent zurecht behautet, ein bestimmter Browser zu sein, wird die von diesem Browser erwartete Funktionalität unterstützen. "Rendernde Software" hingegen besteht ggf. ein Interview mit Testfragen zu bestimmten Eigenschaften nicht ohne Weiteres.

Mit diesem Ansatz kann man "zur Laufzeit" per JavaScript überprüfen, ob es sich um einen echten Browser handelt oder nicht. Auf GitHub finden sich dazu verschiedene Sammlungen; unter anderem den Fingerprint Scanner und Detect Headless, aus denen ich einige, aber nicht alle Tests übernommen habe, um einen Bot Marker für den Google Tag Manager zu erstellen.

Das Bot Marker Script

In den letzten Monaten ist aus der Kombination der Auswertung des User Agents und einem "Interview" zur Überprüfung verschiedener Eigenschaften von Browsern ein Bot Marker Script entstanden und gereift. Unterstützt durch regen Austausch und Tests von Wolfram Bartke (Danke nochmal auch hier!) hat sich das Script durch mehrere Versionen zu einem Stand entwickelt, auf dem mit möglichst geringem Aufwand ein Großteil von Bots erkannt werden.... oder zumindest Signale gesammelt, die in Kombination mit anderen Merkmalen eine Identifizierung von Bots ermöglicht.

Der Bot Marker als Script ist auf GitHub zu finden und zeigt allein durch die Anzahl der Revisionen, dass es noch nicht unbedingt "fertig" ist. Aber es liefert bereits solide Ergebnisse auf verschiedenen Websites im ausgedehnten Probebetrieb; z. T. bereits seit mehreren Monaten.

Ergebniswerte des Bot Markers

Nach Ausführung der Ermittlungsfunktion liefert der Marker ein schlichtes "OK" für den Fall zurück, dass weder der User Agent noch die Featureerkennung einen Hinweis auf einen Bot gegeben hat. Anderenfalls finden sich Angaben dort, die davon abhängen, welcher Bot sich im User Agent zu erkennen gegeben hat oder welcher Feature Test nicht bestanden wurde.

  • Wird die Seite z. B. vom Crawler der Suchmaschine DuckDuckGo besucht, ist das Ergebnis z. B. DUCKDUCKGOBOT_UA. Bei Hubspot HUBSPOT_UA und so weiter. Ist es also ein bekannter und bekennender Bot, endet der Marker mit _UA. Das ist in fast allen Fällen ein so sicheres Signal, dass die Aufrufe komplett ausgeschlossen werden können - sei es als Segment oder per Filter (z. B. zur Beobachtung in einer eigenen Datenansicht).
  • Eine Ausnahme bildet die Gruppe von POTENTIAL_BOT_UA, POTENTIAL_SPIDER_UA und POTENTIAL_CRAWLER_UA, denn hier stand nur "Bot". "Spider" oder "Crawler" im User Agent; dieser war aber nicht explizit in der Liste bekannter Bots enthalten. Diese Gruppe dient also hauptsächlich zur Erkennung weiterer Kandidaten für die Liste und besitzt folgerichtig Potential für Fehltreffer. Ein Ausschluss sollte daher nur dann erfolgen, wenn ganz bestimmte Angaben im User Agent zu finden sind - ein weiterer guter Grund also, diesen ebenfalls als Dimension zu sammeln.
  • Ist am User Agent nichts Auffälliges zu entdecken, findet je nach "angeblichem Browser" ein unterschiedlicher Umfang von Tests statt, welche die Featureerkennung durchführen. Schlägt einer dieser Tests an, wird ein Marker zurückgegeben, der den Test identifiziert, der nicht bestanden wurde. Das können Werte sein wie z. B. HEADCHR_IFRAME, DEVICE_TOO_SMALL oder PHANTOM_PROPERTIES etc. Nicht jeder dieser Tests ist gleich eindeutig... dazu aber weiter unten noch mehr.

Dimensionen in Analytics anlegen

In Analytics sind zur Nutzung des Bot Markers und ggf. auch zur Speicherung des User Agents aus der o. a. JavaScript Variable entsprechende Dimensionen anzulegen. In beiden Fällen gibt es gute Argumente dafür oder dagegen, diese auf Hit- oder Sitzungsebene zu definieren. Schlussendlich ist aber die Sitzungsebene sicher ausreichend und passt auch zur Voreinstellung, dass ein einmal bestandener Test durch den Bot Marker ausreicht (siehe unten).

Einsatz im Google Tag Manager

Vorweg: Wenngleich hier der "Einbau" nur via Tag Manager gezeigt wird, kann man die Funktion, die den Bot Marker zurückliefert, auch bei einer direkten Implementierung von Analytics nutzen. Die Verwendung ist auch nicht auf Google Analytics allein geschränkt. In anderen Webanalysesystemen gibt es i. d. R. ebenfalls eine Option zum Anreichern von Daten durch benutzerdefinierte Ergänzungen, also ist auch dort ein Einsatz des Bot Markers denkbar.

Im GTM ist zur Nutzung nur eine "Benutzerdefinierte JavaScript Variable" erforderlich. Diese wird mit dem Code versehen, der unter dem o. a. Link auf GitHub zu finden ist.

Bot Marker in Google Tag Manager

Ganz oben im Script findet sich ein sehr kurzer Block zur Konfiguration - er besteht derzeit nur aus einer Option. Diese steuert, ob ein einmal bestandener Test für die Dauer der Sitzung gespeichert und wiederverwendet werden soll. Das ist sinnvoll, wenn man den geringstmöglichen Einfluss auf die Ladezeit nehmen will. Mit der gespeicherten Information beschränkt sich dieser ab dem zweiten Seitenaufruf faktisch auf Null. Auch mehrere Hits auf einer Seite führen - unabhängig von der Einstellung dieser Option - nicht zur mehrfachen Auswertung, sondern ein bereits ermittelter Wert wird stets wiederverwendet.

Sollte es bei der Ausführung der Funktion zu einem Fehler kommen - was ebenso ein starkes Signal dafür ist, dass es sich nicht um einen echten Besucher handeln könnte -, ist es empfehlenswert, einen konkreten Rückgabewert zu definieren. So wird verhindert, dass aufgrund des Fehlers "undefined" statt eines Bot Marker Werts als Ergebnis entsteht (welches nicht an Analytics übergeben werden könnte). Im Beispiel wird daher die Zeichenkette "UNBESTIMMT" in den Optionen zum Formatwert als Ersatz für undefined angegeben, damit das Ergebnis über die Dimension in Analytics auswertbar wird.

Diese Benutzerdefinierte Javascript Variable wird dann - idealerweise zusammen mit dem User Agent - als Benutzerdefinierte Dimension übergeben.

Bot Marker als Dimension übergeben

Ergebnisse in Google Analytics

Die gesammelten Daten kann man in vielen Reports direkt als sekundäre Dimension nutzen. Oder man legt einen Bericht an, der den Bot Marker als primäre Dimension nutzt, so dass ein Überblick entsteht, wie sich die Ergebnisse verteilen. Hier im Beispiel sieht man z. B., dass mehr als 20% der Besucher nicht "über jeden Zweifel erhaben" sind, soweit es die durchgeführten Checks angeht und daher nicht mit "OK" aus der Prüfung kamen.

Bot Marker Bericht

Bei allen anderen muss man nun entscheiden, wie mit den Daten verfahren werden soll. Hier empfiehlt sich eine differenzierte Vorgehensweise:

  1. Alles, was anhand des User Agents erkannt wurde (siehe Hinweise dazu oben) kann als Bot angesehen werden
  2. Wer den Test nicht bestanden hat, ist ggf. ein Bot, muss es aber nicht sein. Daher muss man das Ergebnis mit anderen Daten kombinieren.

Kombination mit anderen Signalen

Ein weiteres Merkmal kann z. B. die Herkunft (Land, Sprache), das Verhalten (nur eine Seite) oder auch der Internetanbieter sein. In der Abbildung sind die markierten Positionen sowohl durch den Test gefallen als auch offenbar in der Amazon Cloud betrieben worden. Erst die Kombination beider Merkmale deutet "sicher genug" für einen Ausschluss auf einen Bot hin.

Bot Marker Bericht

In anderen Fällen ist die Kombination von zwei Merkmalen nicht sicher genug. Aber ein paar Klicks liefern i. d. R. Sicherheit und zeigen auf, wie ein entsprechendes Segment oder ein Filter gestaltet werden kann.

Die folgende Abbildung zeigt als Beispiel alle Nutzer, die eine Website mit dem Internet Explorer 9 besucht haben. An erster Stelle steht ein Löwenanteil von über 99%, der den Test nicht bestanden hat (UNBESTIMMT sagt aus, dass ein Fehler aufgetreten ist; siehe oben).

Bot Marker Bericht

Erkennt man zusätzlich, dass der Internetanbieter "microsoft corporation" war und bestätigt mit ein paar Klicks, dass alle Aufrufe aus USA (in diesem Fall Chicago) kamen, ist das nicht immer, aber zumindest bei dieser Website ein klares Indiz. Denn die Herkunft und der Zugang sprechen für ein Tool, das in der Azure Cloud von Microsoft betrieben wird und das große Interesse an den deutschsprachigen Inhalten dieser Website ist kaum anders als durch Bots zu erklären.

Informationen nutzen

Die Nutzung der Bot Signale kann unterschiedlich ausfallen. Sichere Bots kann man z. B. zu einem Segment kombinieren - oder wie hier gezeigt in einer eigenen Datenansicht sogar eine Kanalgruppierung anlegen.

Bot Marker Bericht

Ebenso kann eine Aufteilung per Filter in unterschiedliche Datenansichten erfolgen oder man unterbindet die Ausspielung des Trackingcodes bzw. sendet den sicheren Bot-Traffic in eine eigene Property. Natürlich bleibt immer ein Rest an Unsicherheit auf beiden Seiten. "OK" muss nicht sicher "kein Bot" bedeuten und kein "OK" spricht nicht in allen Fällen gleich sicher für einen Bot. Aber davon ausgehend, dass man wie gezeigt einen großen Anteil der Daten klassifizieren kann, sollte man dies auch bei Auswertungen berücksichtigen, um sauberere Kennzahlen zu generieren. Das gilt nicht nur für Auswertungen in Google Analytics; die Dimensionen sind auch in Rohdaten oder im Google Data Studio verfügbar.

Weitere Kombinationsmöglichkeiten

Wem die Kombination mit bereits bestehenden anderen Metriken oder Dimensionen nicht genug sein sollte, kann über den Bot Marker hinaus weitere Signale sammeln. Ein paar Optionen wären:

  • Cookies
  • Honeypot-URLs
  • Mausbewegungen
  • Abfolgen / Timings
  • reCAPTCHA V3

Ich habe einige davon getestet, habe aber über die Bestätigung der Ergebnisse des Bot Markers hinaus kaum neue Erkenntnisse gewonnen. Eine Ausnahme ist reCAPTCHA. Wenn man den Einsatz eines weiteren Google Dienstes mit der IT und den Datenschutzhinweisen vereinbaren kann, ist dies eine interessante Ergänzung, die ich aktuell testweise parallel zum Bot Marker betreibe. Wer es selbst probieren mag, findet bei Simo Ahava im Blog einen Gastbeitrag mit einer ausführlichen Anleitung von Sebastian Pospischil und Philipp Schneider. Ein erster Vergleich zeigt erfreulicherweise, dass sich beide Tools in den meisten Fällen sehr einig sind. Besonders unsicher (wenn man die reCAPTCHA Ergebnisse als Maß verwendet) sind nach akt. Stand (November 2019) diese Tests:

  • NO_OUTER_DIMENSION
  • HEADCHR_IFRAME

Daher sollte man diese Marker allein nie zur Identifizierung von Bots nutzen, sondern wie gezeigt mit anderen Dingen kombinieren. Ebenso ist ein "UNBESTIMMT" allein kein Merkmal, da es viele Möglichkeiten gibt, warum die Funktion nicht ganz fertig geworden ist (installierte Plugins o. Ä.). Die Funktionalität der Website ist dadurch aber nicht in Gefahr - und wie man oben sehen kann, ist auch UNBESTIMMT in Kombination mit anderen Dingen durchaus hilfreich.

Wer auf den Geschmack gekommen ist, kann und sollte den Marker selbst einsetzen und im ersten Schritt Bot Marker Ergebnisse und ggf. User Agents in Dimensionen sammeln. Nach einer Auswertung der ersten Daten stehen dann alle Optionen zur Segmentierung, Filterung etc. offen. Es loht sich zudem in den nächsten Monaten, gelegentlich nach Updates des Scripts bei GitHub zu schauen. Wenn es wesentliche Änderungen gibt, findet sich unter dem Script ein passender Kommentar. Alle Hinweise zum Einsatz, zu denkbaren Ergänzungen und sonstiges Feedback sind willkommen.

Damit: Viel Spaß auf der Jagd nach irreführenden Daten in Analytics!

 

© 2001 - 2019 Markus Baersch