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

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:

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.

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:

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

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:

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
  • 23.100.63.22
  • 34.111.104.227
  • 34.111.239.10
  • 34.149.178.113
  • 40.91.211.73
  • 40.118.23.197
  • 52.232.29.198

Achtung: Die IP Adressen können sich jederzeit ändern. Die immer aktuelle Liste gibt es bei Cookiebot. Mit Variante 2 ist man unabhängig von IP Adressen.

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“:

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

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:

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:

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:

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:

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%

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:

Platz 1: urlumbrella.com

Eindeutig: Referral-Spam.

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

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:

• 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:

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:

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

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.

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:

Wähle den Typ “Interner Traffic”:

Füge nun folgende Filterdetails hinzu:

• Name des Datenfilters: Include Nospam-Traffic
• Filtervorgang: Nur Einschließen
• traffic_type: nospam
• Filterstatus: Test

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:

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:

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:

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

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

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:

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:

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:

• 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.

Traffic-Type an GA4 übergeben

Im nächsten Schritt wird diese Variable als traffic_type an GA4 übergeben. Dazu muss in allen GA4 Tags im Server GTM der Parameter „traffic_type“ hinzugefügt werden und auf den Wert der neuen Variable gesetzt werden:

Done. ✔️

Trigger anpassen

Damit Spam-Traffic gar nicht erst an GA4 gesendet wird, kann im letzten Schritt noch eine Exception im Trigger des GA4-Tags hinzugefügt werden.

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:

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

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 

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. Somit sehen wir auch nichts in GA4.

Eine Testing-Möglichkeit ist in der GTM-Preview – allerdings müsste dazu der User-Agent deines Browser auf „Bot“ geändert werden.

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. ✔️

Damit auch Spam-Traffic gefiltert wird, der gar nicht erst über die Website kommt (Ghost Traffic), sollte auch für die Serverside-Variante ein Include-Filter erstellt werden:

Einschließen-Filter in GA4

Dazu benötigst du 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:

Wähle den Typ “Interner Traffic”:

Füge nun folgende Filterdetails hinzu:

• Name des Datenfilters: Include Nospam-Traffic
• Filtervorgang: Nur Einschließen
• traffic_type: nospam
• Filterstatus: Test

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:

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:

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:

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:

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