Markus Baersch

Analytics · Beratung · Lösungen

Start » Blog » Analytics / Google Tag Manager / Serverside Tracking

11.04.2021

„Bekennende Bots“ wie der GoogleBot und andere sind nichts Neues. SEO-Tools, Crawler von Consent-Anbietern, Preisvergleichstools und zahlreiche Suchmaschinen (nicht nur Google und Bing) besuchen mehr oder weniger häufig die eigene Website. Zum Teil werden rendernde Bots zusätzlich in Form von SEO-Tools, Google Pagespeed oder anderen auf die eigene Website losgelassen. Das war vor 3 Jahren noch kein großes Problem, aber heute kommt dadurch ggf. ein nennenswertes Rauschen in den Webanalyse-Daten zustande. Während es für clientseitige Bot-Erkennung zahlreiche Merkmale gibt, die man zur Verifikation realer Besucher nutzen kann, ist man auf dem Server i. d. R. auf den User Agent angewiesen. Dieser Beitrag zeigt den Umfang des evtl. Problems, die Rahmenbedingungen und Lösungsansätze zur Behandlung dieser Bots – mit Fokus auf serverseitiges Tracking mit dem Google Tag Manager.

Generell „besser“ durch Consent-Management

Eigentlich ist das Spam-Problem für viele Websites kleiner geworden, seitdem vor dem Tracking ein Consent Dialog bestätigt werden muss. Dieser "Filter" hat in einigen Analytics-Properties dafür gesorgt, dass nicht nur Daten realer Besucher in der Webanalyse fehlen, weil diese keine Zustimmung erteilt haben (was schade ist), sondern rendernde Crawler finden seither in Google Analytics meist nicht mehr statt (was gut ist).

Insofern sollte man meinen, dass eine Erkennung von Bots nicht mehr so dringend ist wie vor Einführung von Consent Management. Das stimmt auch – zumindest zum Teil. Auf der einen Seite hat die Anzahl von Bots, die es in die „vollständige“ Webanalyse schaffen, dadurch tatsächlich abgenommen. Dem gegenüber steht eine neue Klasse von Bots und ein zusätzliches Problemfeld, die beide mit der Einführung von Consent Managern hinzugekommen sind.

Neues Problem: Consent-Crawler

Consent-Tools haben die nützliche Eigenschaft, mittels eines eigenen Crawlers regelmäßig zu prüfen, ob neue Dienste / Cookies auf der Website auftauchen. Die meisten davon sind in der Lage, die entsprechenden Zustimmungen zu allen Diensten zu simulieren. Zum Glück werden diese zwar nur selten auf eine Website losgelassen, aber es gibt Ausnahmen. Je nachdem, auf welchem normalen Niveau der Traffic auf einer Website ausfällt, mögen diese sporadischen oder ggf. täglichen Besuche nicht ins Gewicht fallen. In die Webanalyse schaffen sie es aber in diesem Fall dennoch, wenn man nichts dagegen unternimmt.

Problemfeld: Ersatzdatensammlung

Wesentlicher ist das „Bot-Problem“ für eine i. d. R. auf die eine oder andere Weise stattfindende Ersatzdatensammlung. Sei es in einer „abgespeckten“ Google Analytics Property mit kurzlebigen Identitäten, im cookielosen Betrieb in Matomo oder sonstwo: Werden hier unabhängig von Zustimmung alle eingehenden Hits in Daten verwandelt, ist das Bot-Problem aller rendernden Tools, die die Website jeden Tag besuchen, durchaus nennenswert. So schön es also ist, in einem Alternativtool „alle Daten“ zu sehen: Gerade hier sind die steigenden Anteile rendernder Bots dann besonders störend.

Findet die Datensammlung und Weitergabe direkt im Browser statt, muss man nach wie vor mit clientseitiger Bot Erkennung arbeiten und das Ausspielen des Tags ggf. verhindern oder die Sitzungen in einer eigenen Dimension markieren o. Ä. Bei Einsatz serverseitigen Taggings hingegen sollte der die Daten der Website empfangende und an Trackingdienste weiterleitende Endpunkt zumindest diejenigen Bots, die sich als solche zu erkennen geben, entsprechend behandeln.

Bot Erkennung über den User Agent

Bereits ein guter Teil des o. a. Bot Markers für Google Analytics basiert auf der Erkennung von bekannten Bots anhand des User Agent. Minimal diesen Teil kann und sollte man bei fehlender Erkennung im Browser ersatzweise auch auf dem Server nutzen. Während das Verfahren i. d. R. in jedem Serverside-Tagging-Szenario anwendbar sein sollte, wo Daten empfangen und verteilt werden könne, soll die Nutzung hier anhand des serverseitigen Google Tag Managers gezeigt werden. Bei Github findet sich dazu ein Template für eine Benutzerdefinierte Variable, die man im GTM unter „Vorlagen“ importieren kann. Mit etwas Glück schafft es die Vorlage auch in die Template Gallery; bis dahin ist die manuelle Installation leider unumgänglich. Zum Import bei den Variablen-Vorlagen eine neue Vorlage anlegen, über das Menü (oben rechts) "Import" auswählen und dann das von GitHub gespeicherte Template (tpl-Datei) einlesen.

Damit können bereits eine ganze Menge an Bots erkannt werden. Das Ergebnis der Bot Marker Variable kann zur Erkennung und dem Ausschluss weiterer Bots dienen, wenn potentielle Bots mit Ihrem User Agent im Ergebnis entsprechend ausgewiesen werden (optional). Schaut man regelmäßig in die Liste der „Potential Bots“ und trägt die Kennungen in die Konfiguration der Variable als zusätzliche Bots ein, werden diese anschließend der Klasse sicher erkannter Bots zugewiesen. Auf diese Weise kann man den Ausschluss anfangs „schärfen“ und danach regelmäßig überprüfen und ggf. nachjustieren.

Nutzung des Bot Markers

Importiert man das Variablen – Template für den „Simple Bot Detector“ in einem serverseitigen Tag Manager Container, kann damit eine Variable angelegt werden, die eine Erkennung von Bots vornimmt und als Variablenwert zurück liefert. Generell ist dabei keinerlei Konfiguration erforderlich… aber möglich.

Einstellungen Simple Bot Detector Variable in Google Tag Manager

Dazu kann in einem Text eine Liste weiterer Zeichenketten definiert werden, anhand derer Bots durch Vergleich mit dem User Agent erkannt werden können. Das Template enthält aber bereits eine recht umfangreiche Liste bekannter Bots von Suchmaschinen und anderen, die ohne Einträge in diesem Feld erkannt werden.

Als weitere Option ist wählbar, dass der User Agent nicht aus dem Request gelesen, sondern einer beliebigen Variable entnommen werden soll. Das ist dann sinnvoll, wenn z. B. die eingehenden Requests nicht direkt aus dem Browser stammen, sondern der User Agent in den Parametern oder der Nutzlast des Requests stecken und daher aus einer Variable ausgelesen werden sollen.

Soll die Auswertung des User Agent genutzt werden, um weitere potentielle Bots direkt anhand des Bot Detector Ergebnisses zu identifizieren, kann zudem angegeben werden, dass der User Agent eines potentiellen Bots (siehe unten) im Ergebnis ausgegeben werden soll.

Ergebnisse des Bot Detectors

  • Bekannte Bots: Findet sich im User Agent eine Zeichenkennte aus der Kennung bekannter Bots, wird als Ergebnis „Bot (Botname)“ ausgegeben . Der Botname stimmt mit der Zeichenkette überein, nach der gesucht wurde. Ein Beispiel wäre „Bot (GoogleBot)
  • Potentielle Bots: Gibt es dazu keine Fundstelle, wird im User Agent nach „bot“, „crawler“ oder „spider“ gesucht und dabei sonst als Fehltreffer ausgewiesene Zeichenketten wie „Cubot“ (Smartphone Marke) berücksichtigt. Findet sich ein Treffer, wird je nach Einstellung nur „Potential Bot“ oder „Potential Bot (User Agent)“ ausgegeben. Der User Agent wird hierbei bei aktiver Option komplett mit angegeben, so dass damit entschieden werden kann, ob man den Eintrag in die o. a. Liste selbst definierter Bot-Marker zu übernehmen, so dass diese bereits im ersten Check sicher als Maschine eingestuft werden können. Alternativ könnte man den User Agent natürlich in einem solchen Fall in einer eigenen Variable aus dem Header oder den Event Daten extrahieren und zusammen mit dem Bot-Marker an Analytics übergeben (z. B. als Benutzerdefinierte Eigenschaft; siehe unten)
  • Alles andere: Schlagen beide obigen Checks fehl, lautet das Ergebnis „OK

Was kann man damit tun?

Wie alle Variablen kann man diese (bzw. ihren Wert) nutzen, um damit das Tracking zu ergänzen oder zu steuern. Beispiele:

  • Ausschließenden Trigger für Bots erstellen: Sollen Bots generell nicht in einem Dienst wie Google Analytics auftauchen, kann im serverseitigen Tag Manager ein ausschließender Trigger erstellt werden. Dabei kann entweder alles als Auslöser dienen, das nicht „OK“ als Wert hat oder z. B. nur Werte, die mit „Bot (“ beginnen und somit klar als Maschine erkannt wurden
  • Bei auslösenden Triggern: Will man Bots in einer eigenen Property sammeln oder z. B. in einer eigenen BigQuery Tabelle, kann ein dazu dienendes Tag mit einem expliziten Auslöser für Bots versehen werden
  • Suchtabelle für abweichende Tracking-Id bei bekennenden Bots: Noch eleganter ist es, für Bots oder Potentielle Bots ggf. eigene Properties für Universal Analytics oder Data Streams für GA4 definieren. Dabei kann ebenso wie bei Triggern anhand der unterschiedlichen Werte beliebig „verteilt“ werden
  • Bot Marker als User Property / Event Property an GA4 übergeben: Während es für Universal Analytics nicht vorgesehen ist, am Server noch Felder zu verändern, kann man zumindest bei GA4 problemlos weitere Benutzerdefinierte Eigenschaften auf Event- oder User-Ebene hinzufügen und so z. B. jeden Hit mit einem Bot Marker versehen. Das kann dazu dienen, statt in verschiedenen Properties zu arbeiten, Menschen von Bots in unterschiedlichen Segmenten zu trennen

Mit dem Bot Detector ist die gesonderte Behandlung bekannter und am User Agent erkennbarer Bots auch ohne clientseitige Maßnahmen möglich. Die zeitweise Auswertung lohnt sich nach meiner Erfahrung auf jeden Fall. Der Einbau ist nicht zeitaufwändig und im „schlimmsten“ Fall sieht man, dass man kein nennenswertes Problem hat. Dann ist wenigstens das Vertrauen in die eigenen Daten gestärkt.

© 2001 - 2021 Markus Baersch