Er ist wieder da😭: Spam-Traffic in GA4 – und wie du ihn effizient vermeidest24 min Lesezeit

Michaela Linhart & Matthias Hausdorf 5 Comments

Die Freude war groß zum Start von GA4 (damals 2020), denn im Google Support Center steht, dass “in Google Analytics 4-Properties Traffic von bekannten Bots und Spider automatisch ausgeschlossen werden”.

Das ist sehr beruhigend, denn Spam-Traffic ist KEIN echter Traffic.

Meist ist es Ghost- oder Fake-Traffic, d.h. Zugriffe, welche direkt in die Google Analytics Berichte geschleust werden – ohne dass jemand jemals auf deiner Website war.

Das Ziel der Spammer: Aufmerksamkeit generieren!

Aufmerksamkeit, damit du deren Website besuchst und bspw. Werbung konsumierst. Bei Milliarden Zugriffen weltweit sind das ganz gute Werbeeinnahmen…

Wichtig: Spam-Zugriffe wollen wir jedoch nicht in Google Analytics erfassen, denn sie verfÀlschen die Zugriffszahlen und Metriken wie bspw. die Conversion Rate und verwÀssern somit die Analysen.

Gut, dass sich Google also selbst um die Erkennung und Entfernen von bekannten Bots und Spidern kĂŒmmert – oder etwa nicht?

Bot-Traffic in GA4 identifizieren

Leider erkennt Google nicht jeden Bot.

Fast die HĂ€lfte (47,4% lt. Imperva) des gesamten Internet-Traffics kommt von Bots und nicht von Menschen.

Das sind bspw. Crawler von Suchmaschinen wie Google, die zuerst den Inhalt erfassen mĂŒssen, um deine Website in den Suchergebnissen anzeigen zu können.

Bots, die nicht fĂŒr Spam missbraucht werden, geben sich allerdings meist anhand des User Agents zu erkennen. Der User Agent des Bots, der die Suchergebnisse fĂŒr die Google Suche erfasst, heißt zum Beispiel “Googlebot” und wird von Google automatisch gefiltert.

Hinweis: Google hĂ€lt sich beim Ausschluss bekannter Bots und Spider an die Liste „International Spiders and Bots“ des Interactive Advertising Bureau (IAB).

Allerdings gibt es noch weitere Bots wie bspw. von SEO-Tools und Consent Management Systemen wie Cookiebot, welche deine Website regelmĂ€ĂŸig ĂŒberprĂŒfen. Cookiebot bspw. sucht monatlich auf der Website nach neuen Cookies, um diese automatisch in die DatenschutzerklĂ€rung aufzunehmen.

Dieser Bot-Traffic wird allerdings nicht automatisch von Google erkannt und verursacht deswegen unerwĂŒnschten Traffic in Google Analytics.

Wenn dein GA4 also ĂŒber einen lĂ€ngeren Zeitraum an immer denselben Tagen Traffic-AusschlĂ€ge verzeichnet, dann ist das mit hoher Wahrscheinlichkeit Bot-Traffic von deiner CMP, deinem SEO-Tool oder Ähnlichem:

Bot Traffic in Google Analytics 4

Screenshot: Bot Traffic in Google Analytics 4

Allerdings sollten diese Zugriffe nicht in Google Analytics erfasst werden, da sie deine Zugriffszahlen und somit deine Analysen verfÀlschen.

Was also tun gegen bekannten Bot-Traffic in GA4?

Hier die Lösung:

IP-Filter gegen Bot-Traffic am Beispiel Cookiebot

Herausfiltern.

Hinweis: Leider gibt es (noch) nicht sooo mega viele Filtermöglichkeiten in GA4 (Stand November 2023).

Es ist jedoch möglich, IP-Adressen zu filtern – in dem Fall die beste und einfachste Lösung. Denn bewusst eingesetzte Bots wie bspw. von CMPs (Cookiebot), SEO-Tools, etc. nutzen immer dieselbe IP-Adresse.

IP-Adressen können ganz einfach aus GA4 ausgeschlossen werden.

Im folgenden Beispiel zeigen wir, wie Zugriffe des monatlichen Cookiebot-Crawlers aus GA4 ausgeschlossen werden können. Cookiebot stellt dazu eine Anleitung zur VerfĂŒgung.

Cookiebot Banner

Du nutzt Usercentrics statt Cookiebot? 

▶ Eine Anleitung zum Ausschluss von Usercentrics Bot-Traffic findest du weiter unten im Blogbeitrag.

Wichtig: Wenn du eine andere Consent Management Plattform nutzt oder SEO-Tools im Einsatz hast, schau dich kurz auf deren Website nach den IP-Adressen um oder schreibe dem Support. In der Regel stellen diese Tools ihre IP-Adresse fĂŒr den Ausschluss im Analyse-Tool zur VerfĂŒgung.

Folgende Anleitung gilt fĂŒr alle Tools – nur die IP-Adresse ist immer unterschiedlich:

Gehe in das GA4 Administrations Interface und klicke in den Property-Einstellungen –> Datenstreams auf deinen Web-Datenstrom:

GA4 IP-Filter im Web-Datastream

Screenshot: GA4 IP-Filter im Web-Datastream

Navigiere im Web-Datenstrom zu den Google-Tag-Einstellungen und klicke auf „Tag-Einstellungen bearbeiten“:

Google Tag Einstellungen im GA4 Web-Datastream

Screenshot: Google Tag Einstellungen im GA4 Web-Datastream

In den Google-Tag-Einstellungen klicke zuerst auf „Mehr anzeigen“ und anschließend auf die Einstellungen „Internen Traffic definieren“, um IP-Adressen zu definieren, welche als „Bot-Traffic“ gekennzeichnet werden sollen:

Google Tag Einstellungen - Mehr anzeigen

Screenshot: Google Tag Einstellungen – Mehr anzeigen

Um eine Regel fĂŒr „internen Traffic“ zu definieren, klicke rechts oben auf den blauen „Erstellen“-Button und hinterlege folgende Konfiguration:

  • Regelname: Cookiebot-Traffic
  • traffic_type-Wert: cookiebot
  • IP-Adressen
    • 13.74.44.241
    • 40.91.211.73
    • 52.232.29.198
    • 23.100.63.22
    • 40.118.23.197
GA4 - Regel fĂŒr internen Traffic definieren

Screenshot: GA4 – Regel fĂŒr internen Traffic definieren

Speichern.

Damit sind schon mal die IP-Adressen fĂŒr den Ausschluss definiert – jedoch noch kein Filter aktiv. Diesen mĂŒssen wir im nĂ€chsten Schritt erstellen.

Um einen Datenfilter zu erstellen, klicke gefĂŒhlt 100x auf „X“ um zurĂŒck in den Admin-Bereich zu kommen. In den Property-Einstellungen –> Datenerhebung und -Ă€nderung wĂ€hle den Punkt „Datenfilter“:

Datenfilter in GA4 erstellen

Screenshot: Datenfilter in GA4 erstellen

Erstelle einen neuen Datenfilter via blauen „Filter erstellen“-Button und wĂ€hle als Filter-Typ „Interner Traffic“:

  • Name des Datenfilters: Cookiebot-Traffic ausschließen
  • Filtervorgang: Ausschließen
  • traffic_type-Prameterwert: cookiebot
  • Filterstatus: Aktiv
GA4 Datenfilter um Bot-Traffic auszuschließen

Screenshot: GA4 Datenfilter um Bot-Traffic auszuschließen

Wichtig: Filter sollten VOR der Aktivierung IMMER getestet werden, um sicherzustellen, dass sie auch tatsÀchlich das Richtige tun.

Herzlichen GlĂŒckwunschđŸ„ł: Bot-Traffic landet nun NIE wieder in deiner GA4-Property. 🎊

Bot-Traffic ist aber leider nicht der einzige unerwĂŒnschte Traffic in GA4.

Echter, bösartiger Spam-Traffic ist das eigentliche Problem:

Spam-Traffic in GA4 identifizieren

TatsĂ€chlich ist seit dem Start von Google Analytics 4 (2020) der Traffic in GA4-Properties weitgehend stabil geblieben. Niemand hat sich groß die MĂŒhe gemacht zu spammen, denn produktiv in Verwendung war weiterhin Universal Analytics – bis zum Shutdown im Juli 2023.

Seit dem Shutdown von UA ist die Welt gezwungen GA4 zu nutzen.

Und plötzlich, siehe da – er ist wieder da, der echte, bösartige Spam-Traffic:

Echter Spam-Traffic in Google Analytics 4

Screenshot: Echter Spam-Traffic in Google Analytics 4

Am 9. August 2023 hatten wir den ersten Spam-Traffic-Peak in der ANALYTICSkiste.

Warum Spam-Traffic und nicht echter Traffic?

Weil ein plötzlicher, unerklĂ€rbarer Traffic-Peak „eher seltsam“ ist…

Auch GA4 hat den Peak als „Anomalie“ erkannt, mit dem Ziel das wir tiefer nachforschen:

GA4 Anomalie-Detection fĂŒr Spam-Traffic

Screenshot: GA4 Anomalie-Detection fĂŒr Spam-Traffic

Also lass uns forschen:

Akquisitions-Kanal prĂŒfen: Von wo kommt der Traffic-Peak?

Um zu ĂŒberprĂŒfen welcher Kanal zu dem Traffic-Peak gefĂŒhrt hat, gehe in GA4 → Berichte → Lebenszyklus → Akquisition → Neu generierte Zugriffe (Analyse auf Session-Basis) und such dir im ersten Schritt den Tag, an dem der Peak stattfand:

GA4 Bericht Neu generierte Zugriffe - Datumselektor

Screenshot: GA4 Bericht Neu generierte Zugriffe – Datumselektor

Nimm im nĂ€chsten Schritt einen Datums-Vergleich vor, um herauszufinden welcher Kanal fĂŒr den Peak verantwortlich ist. Am Besten wĂ€hlst du den selben Tag der Vorwoche oder des Vormonats:

GA4 Datumsvergleich

Screenshot: GA4 Datumsvergleich

Analysiere anschließend deine KanĂ€le – wo hat der Peak stattgefunden?

Referral-Spam in Google Analytics 4

In unserem Fall ist der Unassigend-Kanal am stÀrksten gestiegen: +2.500%

GA4 Kanal-Analyse zur Spam-Detection

Screenshot: GA4 Kanal-Analyse zur Spam-Detection

Besonders spannend ist, dass 78 User KEINE einzige Sitzung erzeugt haben und auch alle Engagement-Messwerte bei NULL liegen.

Das können also keine „normalen“ Zugriffe sein.

Über die Bibliothek kannst du dir die Dimension „Seitenverweis“ in die Analyse dazu holen und anschließend als primĂ€re Dimension auswĂ€hlen, um zu analysieren von welcher Seite die „78 Nutzer“ gekommen sind:

GA4 Seitenverweis-Analyse zur Spam-Detection

Screenshot: GA4 Seitenverweis-Analyse zur Spam-Detection

Platz 1: urlumbrella.com

Eindeutig: Referral-Spam.

Das Ziel: Deren Website besuchen – und aus Neugier machen wir das auch:

urlumbrella

Screenshot: urlumbrella

Kurz umgeschaut ist klar: urlumbrella ist ein Service, um ganz gezielt und gewĂŒnscht Bot-Traffic auf Websites zu erzeugen um Statistiken in bspw. Google Analytics aufzuhĂŒbschen.

Wtf… 😂

Somit ist klar💡: Der ungewöhnliche Traffic-Peak ist tatsĂ€chlich Spam-Traffic – nĂ€mlich Referral-Spam von urlumbrella.com

HĂ€ufig ist Spam-Traffic jedoch nicht so eindeutig identifizierbar:

Direct-Traffic-Spam

Spam-Traffic wird auch hĂ€ufig ĂŒber den direkten Kanal erzeugt.

In dem Fall ist es schwerer nachvollziehbar, ob es sich um echten Traffic oder Spam-Traffic handelt – man muss noch tiefer forschen.

Ein Indiz fĂŒr Spam-Traffic ist bspw. wenn eine bestimmte Anzahl Nutzer nur sehr wenige Sitzungen erzeugen und / oder Engagement-Messwerte wie die durchschnittliche Interaktionsdauer pro Sitzung utopisch hoch sind:

Utopische Werte in GA4

Screenshot: Utopische Werte in GA4

  • 79 Nutzer erzeugen nur 2 (!) Sitzungen??!!
  • Die avg. Sitzungsdauer fĂŒr 2 Sitzungen betrĂ€gt ĂŒber 5 Stunden??!!
  • Die avg. Sitzungsdauer ist im Vergleich zum Vorzeitraum um +60.950% gestiegen??!!

Diese Werte sind nicht normal.

Es handelt sich um Spam-Traffic. 

Ein weiteres Indiz fĂŒr Spam-Traffic ist, wenn die Anzahl der Nutzer annĂ€hernd gleich geblieben oder sogar geringer geworden ist, jedoch der Anteil der Ereignisse extrem gestiegen ist.

Wenige Nutzer fĂŒr utopisch viele Ereignisse? –> Spam-Traffic

Merksatz📙: Immer dann, wenn du abnormale Peaks und / oder abnormale Zahlen an nur einem einzigen Tag in GA4 verzeichnest, handelt es sich mit sehr hoher Wahrscheinlichkeit um Spam-Traffic.

Zusammengefasst

Traffic ist Spam-Traffic, wenn du

  • einen ungewöhnlich hohen Anteil an direct-Traffic verzeichnet.
  • extrem viele Events fĂŒr sehr wenige Nutzer entdeckst.
  • viele Nutzer mit null Sitzungen und Engagement hast.
  • Pageviews mit leeren Seitentiteln erfasst.
  • ungewöhnlich hoher Referral-Traffic von unbekannten Seiten wie urlumbrella.com

Leider ist echter, bösartiger Spam-Traffic auch fĂŒr Google schwer zu erkennen und landet somit gelegentlich in den Berichten von Google Analytics 4.

Das wollen wir nicht, deswegen raus damit:

Anleitung: Spam-Traffic in GA4 vermeiden

Die nicht gerade einfachste aber aktuell beste Variante um Spam-Traffic aus Google Analytics 4 auszuschließen ist, ĂŒber den traffic_type-Parameter im Google Tag Manager – in Kombination mit einem Einschließen-Filter in GA4.

Das liegt daran, dass die Filter-Möglichkeiten in GA4 derzeit (Stand: November 2023) noch stark beschrĂ€nkt sind. Es gibt NUR die Möglichkeit Entwickler-Traffic und internen-Traffic in GA4 ein- oder auszuschließen:

Filtermöglichkeiten in Google Analytics 4

Screenshot: Filtermöglichkeiten in Google Analytics 4

Es kann also nicht direkt ein Ausschluss-Filter fĂŒr bspw. Referral-Traffic von urlumbrella.com erstellt werden. Stattdessen muss mit einem Workaround gearbeitet werden.

FĂŒr den Ein- oder Ausschluss von Entwickler- und internen-Traffic nutzt Google den traffic_type-Parameter.

Dieser ist beim Ausschluss der internen IP-Adressen bspw. auf “internal” gesetzt:

GA4 traffic_type Parameter - internal

Screenshot: GA4 traffic_type Parameter – internal

Der Parameterwert “internal” wird automatisch auf Datenstream-Ebene bei der Definition der internen IP-Adressen gesetzt – kann aber auch umbenannt werden:

Interne IP Adressen in GA4 definieren - Datenstream

Screenshot: Interne IP Adressen in GA4 definieren – Datenstream

Löst ein User nun ein Event mit dem Paramter traffic_type = internal aus und ist der Filter in GA4 auf “aktiv” gesetzt, erscheint dieser Traffic NICHT in den Berichten von GA4 – er wird ausgeschlossen. Genau das wollen wir!

Über den traffic_type-Parameter kann also Spam-Traffic aus GA4 ausgeschlossen werden. đŸ„ł

Statt Traffic auszuschließen, drehen wir den Spieß jedoch um und schließen NUR Traffic in deine GA4-Property ein, welcher tatsĂ€chlich von deiner Website stammt. Du benötigst einen Include-Filter.

Dieser Include-Filter “hört” auf alle Ereignisse, die ĂŒber deinen Google Tag Manager ausgelöst werden.

Ereignisse, die NICHT mit dem GTM geschickt werden, wie bspw. jene der Spammer, haben keinen traffic_type-Parameter und werden somit automatisch ausgeschlossen.

Das ist das Ziel📍.

FĂŒr die Umsetzung gibt es allerdings zwei Wege:

  • Clientseitig via WEB-GTM
  • Serverseitig via SERVER-GTM

Der Vorteil der Clientseitigen-Variante (1.) ist eine schnelle und einfache Umsetzung. Du kannst sie jetzt sofort und innerhalb weniger Minuten umsetzen.

Der grĂ¶ĂŸte Nachteil ist jedoch, dass dadurch nur ein Teil der Spammer abgefangen wird und zwar jener, welcher Daten direkt an Google sendet. Deine Website muss dazu niemals aufgerufen werden.

Wird deine Website jedoch automatisiert von Bots aufgerufen, wird der traffic_type-Parameter mitgeschickt und somit der Bot-Traffic nicht gefiltert. Er erscheint weiterhin in GA4 bzw. geht uns durch die Lappen
 😒

Hinweis: In Kombination mit einem IP-Filter gegen Bot-Traffic ist die Lösung wieder okay – aber nicht perfekt.

Ein weiterer Nachteil ist nĂ€mlich, dass der traffic_type-Key im Browser öffentlich sichtbar und somit von Bots auslesbar ist – theoretisch. Ob sich Spammer die Arbeit machen den Parameter tatsĂ€chlich auszulesen ist die Frage. Es ist jedoch kein geheimes Passwort und kann von Spammern verwendet werden, um sich am Filter vorbei zu schummeln. 😒

Deswegen ist die Serverseitige-Lösung (2.) die bessere und empfohlene Lösung, da beide Nachteile behoben werden können. Es ist derzeit die einzige und effektivste Möglichkeit, um sich vor jeglichen Spam-Traffic zu schĂŒtzen.

Nachteil: Die Serverseitige-Lösung setzt ein serverseitiges Tracking voraus.

Hinweis: Serverseitiges-Tracking hat eine Vielzahl an Vorteilen und dient hauptsÀchlich dem datenschutzkonformen Tracking sowie der Sicherstellung der bestmöglichen DatenqualitÀt in GA4. Ein Umstieg auf serverseitiges Tracking ist daher dringend empfohlen.

Alle Vorteile, Details und Lösungen kannst du in diesem Blogartikel nachlesen: >> Serverside Tracking (Teil 1): Die Zukunft der Webanalyse trackt serverseitig – aber wie?

Welche Variante ist die Richtige fĂŒr dich?

Variante 2, wenn du bereits ein serverseitiges Tracking im Einsatz hast.

Variante 1, wenn du aktuell noch kein serverseitiges Tracking im Einsatz hast. In dem Fall ist es am Besten, schon mal einen Teil des Spam-Traffics zu filtern und mit Variante 1 loszustarten. Parallel kannst du auf das serverseitige Tracking umsteigen und anschließend Variante 2 umsetzen.

Los geht’s mit der Umsetzung der ersten Variante:

Variante 1: Web-GTM (client side)

FĂŒr die Umsetzung der schnellen, ersten Variante benötigst du nur zwei Schritte:

  1. Anpassung des Google Tags im (Web) GTM
  2. Einschließen-Filter in GA4

Starten wir mit Punkt 1:

Anpassung des Google Tags im (Web) GTM

Im ersten Schritt muss der Google Tag im (Web) Google Tag Manager Container um den traffic_type-Parameter erweitert werden.

Gehe dazu in den Google Tag Manager in deinen GA4 Konfiguration-Tag (Google Tag) und fĂŒge einen neuen Konfigurations-Parameter hinzu:

  • Parameter Name: traffic_type
  • Value: z.B. nospam

Hinweis: Ich vergebe als Parameterwert den Key “nospam”. Du kannst auch jeglichen anderen Namen vergeben, wie bspw. eine random generierte Zahlen- und Buchstabenreihenfolge um zu verbergen um welchen Traffic es sich handelt.

Web GTM Container - Google Tag - Config Parameter traffic_type

Screenshot: Web GTM Container – Google Tag – Config Parameter traffic_type

Das war’s auch schon:

  • Speichern.
  • Testen.
  • Publishen.

Weiter geht’s mit Punkt 2:

Einschließen-Filter in GA4

Jetzt benötigst du noch einen einschließenden Filter in Google Analytics 4, um zu bestimmen, WELCHE Daten in Google Analytics 4 erfasst werden dĂŒrfen – alles andere wird ausgeschlossen.

Gehe dazu ins GA4 Backend → Property-Einstellungen → Datenerhebung und -Ă€nderung → Dateneinstellungen → Datenfilter und erstelle einen neuen Filter:

Neuen Datenfilter in GA4 erstellen

Screenshot: Neuen Datenfilter in GA4 erstellen

WĂ€hle den Typ “Interner Traffic”:

Neuen internen Filter in GA4 erstellen

Screenshot: Neuen internen Filter in GA4 erstellen

FĂŒge nun folgende Filterdetails hinzu:

  • Name des Datenfilters: Include Nospam-Traffic
  • Filtervorgang: Nur Einschließen
  • traffic_type: nospam
  • Filterstatus: Test
Include Nospam-Traffic Filter in Google Analytics 4

Screenshot: Include Nospam-Traffic Filter in Google Analytics 4

Achtung: Ein falsch konfigurierter “Einschließen”-Filter kann den kompletten Traffic aus GA4 ausschließen. Deswegen unbedingt vorab immer gut testen!

Wie testen?

Setze den Filterstatus auf „Test“.

Damit wird zwar Spam-Traffic weiterhin in GA4 erfasst, jedoch mit „Include Nospam Traffic“ markiert.

Warte nun ein bis zwei Monate ab und erstelle anschließend einen Vergleich: Alle Nutzer vs. Nutzer, welche mit dem Testdatenfilter „Include Nospam Traffic“ ĂŒbereinstimmen:

GA4 Vergleich Alle Nutzer vs. Spammer

Screenshot: GA4 Vergleich Alle Nutzer vs. Spammer

Und tatsĂ€chlich: Am 14. Oktober wurde wieder gespammt (im Screenshot oben in rot markiert). Der Traffic wurde als Spam-Traffic erkannt und wĂ€re gefiltert worden, wenn der Filter auf „Aktiv“ gestellt ist.

Top! Das hat funktioniert!

Jetzt kannst du den Filter auf “Aktiv” stellen:

GA4 Datenfilter aktivieren

Screenshot: GA4 Datenfilter aktivieren

Herzlichen GlĂŒckwunschđŸ„ł: Ein Großteil an Spam-, Bot-, Ghost- und Fake-Traffic landet NIE wieder in deiner GA4-Property. 🎉

Ein Großteil – jedoch nicht der gesamte Spam-Traffic.

Deswegen mach dich im nĂ€chsten Schritt ran an die Umstellung auf serverseitiges Tracking, um anschließend Variante 2 umzusetzen:

Variante 2: Server-GTM (server side)

Der effektivste Weg, Spam- oder Fake-Traffic in Google Analytics 4 zu vermeiden, ist ĂŒber das serverseitige Tracking.

Das setzt allerdings voraus, dass du bereits den SERVER GTM-Container nutzt und die serverseitige Tracking Lösung von Google implementiert hast.

Alternativ benötigst du zuerst ein serverseitiges Tracking Setup:

Hinweis: Einen Überblick ĂŒber gĂ€ngige Anbieter sowie alle weiteren Vorteile findest du in diesem Blogartikel: >> Serverside Tracking Lösung im Überblick

Der schnellste und einfachste Weg fĂŒr ein Setup ist ĂŒber die Google Cloud. Eine Anleitung dazu findest du hier: >> SST Teil 2: Googles Lösung mit dem GTM & Google Cloud Run

Ist die Voraussetzung gegeben, kann es mit dem Setup losgehen.

Das Prinzip ist identisch mit der ersten Variante: Mit jedem GA4 Event wird der traffic_type-Parameter mitgeschickt und auf “nospam” gesetzt.

Anstatt jedoch das Filtern GA4 zu ĂŒberlassen, können ĂŒber das serverseitige Tracking sĂ€mtliche Spam-Events gar nicht zu GA4 geschickt werden. Du ersparst dir dadurch das Setzen des Einschließen-Filters in GA4.

ZusĂ€tzlich können erweiterte Filtermöglichkeiten zur Bot-PrĂŒfung genutzt werden. Das Community Template “Simple Bot Detector” von Markus Baersch bietet dazu eine ausgezeichnete Grundlage. Es erkennt 50+ bekannte Bots anhand des User Agents sowie weitere User Agents mit “bot”, “spider” und “crawler” im Namen und filtert diese raus.

PLUS: Es können sogar weitere Filtertypen fĂŒr bspw. die Client-IP-Adresse oder den Hostname erstellt werden.

Deswegen absolute Empfehlung – und mit diesem starten wir auch los:

Variable „Simple Bot Detector“ erstellen

Um das “Simple Bot Detector” Template von Markus Baersch zu nutzen, gehe in deinen SERVER GTM-Container und navigiere zu Templates –> Variable Templates. Klicke auf „Search Gallery“ um ein neues Template aus der Template-Gallery auszuwĂ€hlen:

Server GTM Container - Template hinzufĂŒgen

Screenshot: Server GTM Container – Template hinzufĂŒgen

Navigiere anschließend zu den Variablen und klicke rechts oben auf “Neu”:

Server GTM Container - Neue Variable erstellen

Screenshot: Server GTM Container – Neue Variable erstellen

Erstelle eine neue Variable vom Typ „Simple Bot Detector“ (Custom Templates):

Simple Bot Detector Variable

Screenshot: Simple Bot Detector Variable

Vergib einen schönen, sprechenden Namen und speichere die Variable ab.

Done. ✔

Usercentrics CMP via Simple Bot Detector ausschließen

Wenn du Usercentrics als Consent Management Plattform nutzt und deren Bot-Zugriffe in Google Analytics 4 ausschließen möchtest, dann am einfachsten ebenfalls ĂŒber die „Simple Bot Detector“-Variable (und nicht via IP-Filter – siehe Anleitung weiter oben).

Das liegt daran, dass Usercentrics keine fixen IP-Adressen vergibt.

Stattdessen schreibt Usercentrics jedoch „Usercentrics“ in den User-Agent.

Dieser User-Agent kann ĂŒber einen zusĂ€tzlichen Ausschluss ganz einfach im „Simple Bot Detector“ hinterlegt werden:

Usercentrics Zugriffe via Simple Bot Detector Template ausschließen

Screenshot: Usercentrics Zugriffe via Simple Bot Detector Template ausschließen

Done. ✔

Mehr ist tatsĂ€chlich nicht notwendig um Usercentrics-Bot-Traffic in GA4 auszuschließen. Danke Markus Baersch fĂŒr das großartige Template. 🧡

Variable „Advanced Lookup Table“ erstellen

Durch ein weiteres Community-Template kann der Server Google Tag Manager Container um eine “Advanced Lookup Table” erweitert werden. Damit ist es möglich, verschiedene Bedingungen nacheinander zu prĂŒfen.

Um das “Advanced Lookup Table”-Template zu nutzen, gehe wieder in deinen SERVER GTM-Container –> Templates und suche in der Gallery nach dem „Advanced Lookup Table“-Template von stape.io:

Advanced Lookup Table Template von stape.io

Screenshot: Advanced Lookup Table Template von stape.io

Navigiere anschließend wieder zu den den Variablen und klicke rechts oben auf „Neu“ um eine neue Variable zu erstellen.

WĂ€hle als Variablen-Typ die “Advanced Lookup Table” von stape.io und ergĂ€nze folgende Inhalte:

Advanced Lookup Table Variable im SGTM

Screenshot: Advanced Lookup Table Variable im SGTM

  • Variablenname: LU – Traffic Type
  • If {{Event Data – ip_override}} equals 40.118.23.197 return spam
  • If {{Event Data – Traffic Type}} equals internal return internal
  • If {{Bot Detector}} equals OK return nospam 
  • Set Default Value: spam

Löst ein User nun ein Event aus, werden die verschiedene Bedingungen nacheinander geprĂŒft. Trifft eine der Bedingungen zu, wird der Wert in der rechten Spalte verwendet und alle weiteren PrĂŒfungen darunter ignoriert.

In der ersten Zeile werden Zugriffe von einer bestimmten IP-Adresse als “spam” markiert bspw. die IP-Adresse von Cookiebot, um unerwĂŒnschte Cookiebot-Peaks in GA4 zu vermeiden.

In der zweiten Zeile wird geprĂŒft, ob der traffic_type-Parameter bereits auf “internal” gesetzt ist. Wenn ja, wird dieser Wert an GA4 weitergegeben. Es handelt sich um internen Traffic, der in GA4 ausgeschlossen werden soll.

Erst in der dritten Zeile, wenn die ersten zwei Bedingungen nicht erfĂŒllt wurden, wird geprĂŒft, ob der User Agent ein Bot ist. Ist das Ergebnis der PrĂŒfung “OK” wird “nospam” als traffic_type-Parameter an GA4 ĂŒbergeben.

Trifft keine der Bedingungen zu, wird als Standardwert angenommen, dass es sich um Spam-Traffic handelt und “spam” als traffic_type-Parameter an GA4 ĂŒbergeben.

Speichere die Variable ab.

Done. ✔

Trigger anpassen

Damit Spam-Traffic gar nicht erst an GA4 gesendet wird, benötigt es im letzten Schritt noch eine Exception im Trigger des GA4-Tags.

Die Exception prĂŒft, ob die vorhin erstellte Lookup-Variable “spam” enthĂ€lt. Wenn ja, handelt es sich tatsĂ€chlich um Spam-Traffic und der Tag wird blockiert. Somit wird das Event nicht zu GA4 geschickt.

Um die Exception hinzuzufĂŒgen, gehe in deinen SERVER GTM-Container und navigiere zu Tags. 

WĂ€hle anschließend deinen GA4-Tag aus:

GA4 Tag im Server Google Tag Manager Container

Screenshot: GA4 Tag im Server Google Tag Manager Container

Navigiere im GA4-Tag weiter hinunter zu den Triggern und fĂŒge hier mit „+“ eine Exception hinzu:

Exception im SERVER GTM-Trigger hinzufĂŒgen

Screenshot: Exception im SERVER GTM-Trigger hinzufĂŒgen

Konfiguriere die Exception wie folgt:

  • Trigger Name: Exception – Block Bot Traffic
  • Trigger Type: Custom Event
  • Event Name: .*
  • This trigger fires on: Some Custom Events
  • Condition: LU – Traffic Type equals spam 
Exception Trigger im SERVER GTM

Screenshot: Exception Trigger im SERVER GTM

Trigger speichern.

Tag speichern.

Setup testen.

Hinweis: Das Testing ist mit diesem Setup sehr schwierig, da Spam-Traffic gar nicht erst an GA4 gesendet wird. Es benötigt keinen weiteren Filter in GA4. Somit sehen wir auch nichts in GA4.

Eine Testing-Möglichkeit ist in der GTM-Preview – allerdings mĂŒsste genau zu diesem Zeitpunkt Spam-Traffic auf deiner Website sein.

Deswegen kann nur getestet werden, wenn kĂŒnstlich Spam-Traffic erzeugt wird.

Schlechter Tipp: Spam-Traffic bei urlumbrella kaufen und prĂŒfen, ob dieser NICHT ankommt. 😂

Alternativ: RegelmĂ€ĂŸig in GA4 ĂŒberprĂŒfen, ob seltsame Traffic-AusschlĂ€ge ausbleiben.

SERVER GTM-Container publishen.

Done. ✔

Herzlichen GlĂŒckwunschđŸ„ł: Spam-, Bot-, Ghost- und Fake-Traffic landet NIE wieder in deiner GA4-Property. 🎉

Der VollstÀndigkeit halber: Spam-Traffic UA vs. GA4

Spam-Traffic war ein GIGANTISCHES Problem im alten Universal Analytics (2011 – Juni 2023). Es gab unzĂ€hlige Arten von Spam-Traffic:

  • Event-Spam
  • Landingpage Spam
  • Referrer Spam
  • Organic Search Traffic Spam
  • Keyword Spam
  • Language Spam
  • 


Die Spammer waren super kreativ – und Spamming leider super einfach möglich.

Der Grund: Das Measurement Protocol.

Mit dem Measurement Protocol können Daten aus jedem erdenklichen System direkt an Google Analytics gesendet werden. Das einzige, was dazu benötigt wird, ist die Universal Analytics Tracking-ID z.B. UA-41395255-1.

Die Idee des Measurement Protocols: Datenanreicherung in Google Analytics wie bspw. offline Daten, um ein realistischeres Bild seiner finanziellen Situation zu erhalten und ggfs. sogar fĂŒr Targetings in Google Ads zu nutzen.

Lese-Tipp📖:  >> Praxishandbuch Measurement Protocol: Offline-KĂ€ufe fĂŒr Analysen (GA4) und Targeting (Google Ads) nutzen

Leider kann mit dem Measurement Protocol viel Unfug vorgenommen werden – wie bspw. Spam-, Fake- oder Ghost-Traffic erzeugen. Diesen Nachteil haben sich Spammer ordentlich zu Nutzen gemacht.

Das Ziel der Spammer: Aufmerksamkeit generieren damit du deren Website besuchst und bspw. Werbung konsumierst. Bei Milliarden Zugriffen weltweit sind das ganz gute Werbeeinnahmen…

Zum GlĂŒck ist sich Google diesem Problem bewusst geworden und hat im neuen Google Analytics 4 einen Sicherheitsmechanismus fĂŒr das Measurement Protocol eingefĂŒhrt: Es benötigt ein API-Secret, um Events ĂŒber das Measurement Protocol an GA4 zu senden.

Das API-Secret muss im GA4 Backend → Datenstreams → Webdatenstrom → Ereignisse: Measurement Protocol – API-Secrets erstellt werden:

Measurement Protocol API Secret in GA4 erstellen

Screenshot: Measurement Protocol API Secret in GA4 erstellen

Nur mit diesem Secret-Key werden Events ĂŒber das Measurement Protocol in GA4 erfasst.

Spam-Traffic soll damit besiegt sein. 🩾

Ist er aber leider nicht


Denn Traffic kann auch ganz ohne der Nutzung des Measurement Protocols erzeugt werden – durch einen simplen HTTP-Request, wie es jeder Browser macht.

Beispiel: https://www.analytics.google.com/g/collect?v=2&tid=G-123ABC
.

Wird dieser Link vervollstĂ€ndigt und anschließend aufgerufen, wird an die tid (Google Analytics 4 Mess-ID) ein Event gesendet und somit Spam-Traffic erzeugt


Fazit: Das API-Secret des GA4 Measurement Protocols ist KEIN wirksamer Schutz vor Spam und kann sehr leicht umgangen werden.

Aus diesem Grund sind zusĂ€tzliche Maßnahmen zur Verhinderung von Spam-Traffic in GA4 erforderlich. Die aktuell beste und effektivste Maßnahmen ist, Spam-Traffic ĂŒber den Google Tag Manager zu vermeiden – siehe Anleitung: Spam-Traffic in GA4 vermeiden.

Alles klar?

Dann freuen wir uns ĂŒber ein Like, ein Share und ein Kommentar von dir. 😀

Abonniere gerne unseren Newsletter und lass dich automatisch ĂŒber neue BeitrĂ€ge informieren:

Mehr ĂŒber Google Analytics 4 erfahren?

Komm in meine exklusive Analytics Community:

Noch nicht ganz?

Schreib uns gerne deine Fragen in die Kommentare.

Wir helfen, wo wir können. 👍

Zu viel Text?

Wir helfen auch gerne direkt bei der Umsetzung.

Schick uns gerne deine Anfrage via Kontaktformular.

💡 Happy Analyzing,
Michaela & Matthias

  • Tom sagt:

    Hey Michaela. Super zusammengefasst. Was macht ihr denn aktuell bei Traffic der nur ĂŒber eine gewisse Stadt kommt?
    LG

  • Gerald sagt:

    GibtŽs auch eine Lösung ohne Einsatz des GTM?
    Danke vorab

    • Hi Gerald,

      das ist leider aktuell das Problem in GA4 – es gibt keine Möglichkeit, Traffic _nur_ ĂŒber Datenfilter auszuschließen. Du musst (aktuell) immer ĂŒber den traffic_type-Parameter gehen.

      Den traffic_type-Parameter kannst du auch ĂŒber den Quellcode setzen – dafĂŒr brauchst du nicht zwingend den GTM. Über den GTM geht’s allerdings einfacher und in der Regel schneller…

      Ganz liebe GrĂŒĂŸe
      Michaela