Ausschluss des internen Traffics in Google Analytics 4 mit dem Google Tag-Manager

Durch die vielen Mitarbeiter können die Daten verzerren, da jeder Besuch eines Mitarbeiters mit getrackt wird. Erfreulicherweise lässt sich dieses Problem beheben, da du den internen Traffic in Google Analytics 4 ausschließen kannst.

Allerdings gibt es hier mehrere Haken. Wenn du deine Interaktionen selbst ausschließen möchtest, kannst du deine Ereignisse oder Interaktionen nicht mehr in der DebugView sehen, wenn du mit GTM testest. In der GA4-Dokumentation heißt es, dass es mit dem Entwickler-Filter gut funktionieren würde, aber das stimmt nicht so ganz. Wenn du darüber hinaus mehrere Personen ausschließen möchtest, ist es vielleicht nicht die beste Option, sich nur auf die IP-Adresse zu verlassen.

In diesem Artikel werden dir Methoden aufgezeigt, wie du den internen Traffic in Google Analytics 4 ausschließen sowie die beiden oben genannten Probleme beheben kannst. Zudem wird auch die IP-bezogene Option als Lösungsansatz beschrieben.

Wie schließe ich internen Traffic in Google Analytics 4 aus?

Wenn du schon einmal versucht hast, den internen Traffic in Google Analytics 4 auszuschließen, hast du wahrscheinlich schon Webseiten gefunden, auf denen ausführlich erklärt wird, wie man den internen Traffic-Filter verwendet. Du gehst einfach auf Verwaltung > Datenströme > X Datenstrom > Tag-Einstellungen konfigurieren > Alle anzeigen > Interner Traffic definieren und gibst dann deine IP-Adressen ein.

Dann gehst du auf Verwaltung > Dateneinstellungen > Datenfilter > Interner Traffic und setzt ihn auf „aktiv“. Somit hast du deinen internen Traffic auf der Grundlage von IP-Adressen ausgeschlossen, aber es gibt einen Nachteil. Mit der derzeitigen Systemeinstellung in Google Analytics 4 kannst du deine Ereignisse bzw. Interaktionen nicht in der DebugView sehen.

Eine Lösung für das Problem wäre, eine separate GA4-Property zum Testen zu erstellen. Du müsstest eine Suchtabelle-Variable erstellen, welche die richtige Property auswählt. Wenn du dich im Vorschaumodus befindest, sendest du die Daten in die Test-Umgebung. Wenn du nicht debuggst, fließen die Daten in die Live-Umgebung.

Es gibt noch eine weitere Lösungsoption für das Problem, die in diesem Artikel ausführlicher beschrieben wird. Dabei handelt es sich um eine einzige aktive GA4-Property. Wenn du nicht debuggst, werden deine Daten ausgeschlossen. Wenn du mit dem Vorschaumodus von GTM aber  debuggst, werden deine Daten in der DebugView sichtbar.

So funktioniert der interne Traffic-Filter

Wenn du den internen Traffic in den Tagging-Einstellungen eines Datenstroms definierst, fügt der Tracking-Code von Google Analytics 4 den Parameter tt=internal zu jeder Anfrage hinzu. Dieser Parameter steht für „Traffic-Type“.

Der interne Traffic-Filter (zu finden unter Verwaltung > Dateneinstellungen > Datenfilter) ist so vorkonfiguriert, dass er alle Treffer ausschließt, die den Parameter traffic_type= internal (tt= internal) enthalten. Dies geschieht, sobald du den Filter auf „aktiv“ setzt.

Warnung an Benutzer von GTM-Serverseitigem Tagging

Das in GA4 eingebaute Ausschlussverfahren von internem Traffic funktioniert nicht richtig mit dem GTM-serverseitigem Tagging. Der Parameter traffic_type=internal wird nicht zu GA4-Anfragen hinzugefügt, wenn die Anfragen zuerst an die serverseitige Einstellung gesendet werden.

Das bedeutet, dass du die Ausschlusslogik selbst im GTM-Server erstellen musst. Zum Beispiel musst du die Tags so einstellen, dass sie nicht ausgelöst werden, wenn die IP-Adresse des Benutzers mit einem bestimmten Wert übereinstimmt.

Methode 1: Ausschluss des internen Traffics nach IP-Adresse

Diese Methode eignet sich z. B. für kleinere Unternehmen mit wenigen Mitarbeitern, da du die Treffer der Mitarbeiter auf der Grundlage ihrer IP-Adressen leicht ausschließen kannst. Wenn du jedoch viele verschiedene IP-Adressen eingeben musst oder einige IP-Adressen nicht statisch sind, d. h. sich regelmäßig ändern, ist diese Methode nicht zu empfehlen.

Schritt 1 - Definiere die internen IP-Adressen

Du gehst in Google Analytics 4 auf Verwaltung > Datenströme und wählst deinen Website-Stream aus.

Klicke dann auf Tag-Einstellungen bearbeiten:

Anschließend klickst du auf Alle anzeigen und wählst internen Traffic definieren aus. Hier kannst du neue interne Traffic-Regeln aufstellen.

Wenn du mit mehreren IP-Adressen arbeitest, kannst du für jede IP-Adresse separate Regeln aufstellen.

Du kannst auch „internal“ in das traffic_type-Wert Feld eingeben. Dann reicht es aus, nur einen Filter für den internen Traffic in den Dateneinstellungen deiner GA-Property zu haben.

Wenn du deine IP-Adresse nicht kennst, klicke auf den Link auf der rechten Seite.

Schritt 2 - Erstelle einen Entwickler-Filter in GA4

Du fragst dich vielleicht, was der Unterschied zwischen einem Entwickler-Filter und einem internen Traffic-Filter in GA4 ist. Beide schließen Daten aus den regulären Berichten in GA4 aus, indem sie unterschiedliche Parameter überprüfen. Der Entwickler-Filter prüft die Parameter debug_mode oder debug_event, während der interne Traffic-Filter den traffic_type prüft.

Der wesentliche Unterschied besteht darin, dass du den Entwicklerverkehr in der DebugView von GA4 sehen kannst, während der interne Traffic nicht angezeigt wird.

Den Entwickler-Filter musst du erstellen, da der Filter nicht standardmäßig in Google Analytics 4 hinterlegt ist. In GA4 gehst du auf Verwaltung > Dateneinstellungen > Datenfilter > Filter erstellen. Dann wählst du Zugriffe-Entwickler aus und gibst die folgenden Einstellungen ein:

Du kannst einen beliebigen Namen in das Feld „Name des Datenfilters" eingeben. Dann setze diesen Filter vorerst auf Testen und speichere ihn ab.

Schritt 3 - Erstelle eine Suchtabelle-Variable in GTM, um den traffic_type-Parameter außer Kraft zu setzen.

Wie bereits erläutert fügt das GA4 automatisch den Paramater tt=internal zu allen Treffern hinzu, wenn du von einer deiner internen IP-Adressen kommst.

Um den Wert des Parameters zu manipulieren, kannst du eine Suchtabelle-Variable erstellen. Wenn du den GTM-Vorschaumodus aktiviert hast, änderst du den Wert von tt z. B. auf Entwickler. Jedoch, wenn der Debug-Modus deaktiviert ist, nimmst du keine Änderungen vor und überlässt dies dem GA4.

Erstelle zunächst eine Undefinierte-Variable. Gehe in GTM auf Variablen > Neu > undefiniert und speichere die Variable.

Gehe nun auf Variablen > Konfigurieren und aktiviere die Variable Debug-Modus.

Anschließend gehst du auf Variablen > Neu > Suchtabelle und gibst die folgenden Einstellungen ein:

Hier verwendest du die Variable Debug-Modus als Eingabe. Wenn der GTM-Vorschaumodus aktiviert ist, gibt diese Variable den Wert „true“ zurück. Infolgedessen würde die Suchtabelle-Variable das Wort „Entwickler“ zurückgeben. Wenn jedoch der GTM-Vorschaumodus nicht verwendet wird, gibt die Variable Debug Mode den Wert „false“ zurück, d. h. die Variable undefiniert wird zurückgegeben. Aus diesem Grund wurde die Variable undefiniert erstellt.

Es gibt jedoch einen Unterschied zwischen der Einbettung von "undefined" in JavaScript und der Eingabe des Wortes "undefined" in einem Feld. In JavaScript ist "undefined", umgeben von Anführungszeichen, eine Zeichenkette aber hat keinen Wert. Wenn du nur das Wort "undefined" in die Suchtabelle-Variable eingibst, ist das bereits eine Zeichenkette.

Dann speicherst du die Variable. Anschließend gehst du zu deinem Google Analytics und wählst Tag-Konfiguration aus. Du gibst den Parameter traffic_type ein und als Wert die soeben erstellte Suchtabelle-Variable.

Schritt 4 - Teste die Filter

Aktiviere den Vorschaumodus von GTM und rufe deine Website auf. Nutze die IP-Adresse, die im Internem Datenverkehr deines Datenstroms konfiguriert ist. Rufe die DebugView von GA4 auf.

Zunächst solltest du noch Treffer von deinem Gerät sehen. Klicke auf ein beliebiges Ereignis im Ereignisstrom und überprüfe den Parameter traffic_type. Sein Wert sollte „Entwickler“ sein. In demselben Ereignis solltest du auch den Parameter Debug-Modus sehen.

Denke daran, dass beide Filter, Entwickler und interner Traffic, noch nicht aktiv sind. Sie befinden sich im Testmodus, was bedeutet, dass die bald ausgeschlossenen Daten noch in den regulären GA-Berichten sichtbar sind.

Wenn sich die Filter im Testmodus befinden, wird zudem eine zusätzliche Dimension namens Testdaten-Filtername hinzugefügt. Du kannst diese als sekundäre Dimension verwenden, um zu überprüfen, wie viele Daten ausgeschlossen worden wären, wenn die Filter aktiv wären.

Wenn die Einstellung mit der Suchtabelle-Variable nicht funktioniert, kannst du erwägen, sie überhaupt nicht zu verwenden. Das Gute daran ist, dass zumindest dein interner Traffic nicht die Standardberichte und -untersuchungen verunreinigt.

Der Nachteil ist, dass die Debug-Ansicht nicht funktionieren wird, bis GA4 dies behebt. Um diesen Nachteil zu vermeiden, kannst du einen VPN-Dienst nutzen, der deine IP-Adresse vorübergehend ändern kann. In diesem Fall ist der interne Traffic deines Unternehmens immer noch ausgeschlossen, und nur du verunreinigst die GA4-Daten.

Alternativ kannst du auch eine separate Property zum Testen verwenden. Wie das geht, wird am Ende dieses Artikels erklärt.

Schritt 5- Aktiviere beide Filter

Der letzte Schritt besteht darin, beide Filter zu aktivieren. Gehe auf Verwaltung (in GA) > Dateneinstellungen > Datenfilter und setze beide Trigger (interner Traffic-Filter und Entwickler-Filter) auf „aktiv“. Du kannst dies tun, indem du jeden Filter öffnest, seinen Filterstatus änderst und die Änderungen dann speicherst. Oder du kannst sie einfach aus der Liste aktivieren:

Führe nun den Test noch einmal durch.

• Surfe von der IP-Adresse, die als intern definiert ist.
• Schalte den GTM-Vorschaumodus aus und durchsuche deine Website (um einige Ereignisse an GA4 zu senden)
• Überprüfe die DebugView. Du solltest nicht in der Lage sein, dein Gerät zu finden und neue Ereignisse zu sehen, die von dem Gerät kommen.
• Aktiviere nun den Vorschaumodus von GTM. Durchsuche die Website noch einmal.
• Überprüfe die DebugView. Du solltest nun in der Lage sein, dein Gerät zu finden und einige Daten zu sehen.

Methode Nr. 2 - Ausschluss des internen Verkehrs mit der Datenschicht

Bei dieser Methode werden keine IP-Adressen verwendet, aber der interne Traffic wird über die Datenschicht ausgeschlossen. Hier solltest du mit einem Entwickler zusammenarbeiten. 

Schritt 1: Übergabe des internen Datenparameters an die Datenschicht

Wenn du mit einem Entwickler zusammenarbeitest, solltest du ihn bitten, den Parameter user_type oder traffic_type in die Datenschicht zu integrieren, damit du feststellen kannst, ob der Besucher bzw. Nutzer z. B. zu deinem eigenen Unternehmen gehört. Wenn ein Besucher zu deinem Unternehmen gehört, sollte der Wert des Parameters „intern“ sein. Wenn ein Benutzer bzw. Besucher nicht zu deinem Unternehmen gehört, sollte kein dataLayer.push erfolgen.

Hier ist ein Beispiel für einen dataLayer.push-Code, den dein Entwickler verwenden könnte, wenn der Benutzer oder Besucher zu deinem Unternehmen gehört:

<script>

  window.dataLayer = window.dataLayer || [];

  window.dataLayer.push({

    'event': 'traffic_type',

    'traffic_type': 'internal'

  });

</script>

Der Event key ist nicht erforderlich, wird aber empfohlen. Dieser Code muss aktiviert werden, bevor das GTM-Container-Snippet geladen wird.

Erstelle dann eine Datenschichtvariable mit den folgenden Einstellungen:

Schritt 2: Erstelle einen Entwickler-Filter in GA4

Gehe in GA4 auf Verwaltung > Dateneinstellungen > Datenfilter > Filter erstellen. Wähle „Zugriffe – Entwickler“ und gebe die folgenden Einstellungen ein:

Setze diesen Filter vorläufig auf Testen und speichere ihn ab.  

Schritt 3: Erstelle eine Suchtabelle-Variable in GTM, um den Parameter traffic_type außer Kraft zu setzen

Gehe auf Variablen > Neu > Suchtabelle und gebe die folgenden Einstellungen ein:

Hier wird die Variable Debug-Modus als Eingabe verwendet. Wenn der GTM-Vorschaumodus aktiviert ist, gibt diese Variable den Wert „true“ zurück. Infolgedessen wird die Suchtabelle-Variable das Wort "Entwickler" zurückgeben.

Wenn der GTM-Vorschaumodus nicht verwendet wird, gibt die Variable "Debug Mode" den Wert „false" zurück. Folglich wird der Wert der Datenschichtvariable zurückgegeben, die du im ersten Schritt erstellt hast.

Wenn die Datenschicht den Parameter traffic_type enthält, wird ihr Wert an GA gesendet. Wenn der Parameter nicht vorhanden ist, wird er auf undefiniert gesetzt, was bedeutet, dass GA4 den Parameter traffic_type nicht sendet.

Dann speicherst du die Variable. Anschließend gehst du zu deinem Google Analytics und wählst Tag-Konfiguration. Du gibst den Parameter traffic_type ein und als Wert die soeben erstellte Suchtabelle-Variable.

Schritt 4: Teste die Filter

Du testest die Filter auf der Grundlage von Schritt 4 der ersten Methode.

Schritt 5: Aktiviere beide Filter

Der letzte Schritt besteht darin, beide Filter zu aktivieren. Gehe auf Verwaltung (in GA) > Dateneinstellungen > Datenfilter und setze beide Trigger (interner Traffic-Filter und Entwickler-Filter) auf „aktiv“. Du kannst dies tun, indem du jeden Filter öffnest, seinen Filterstatus änderst und die Änderungen dann speicherst. Oder du kannst sie einfach aus der Liste aktivieren:

Du testest alles noch einmal auf der Grundlage von Schritt 5 der ersten Methode.

Methode 3:  Ausschluss des internen Traffics auf der Grundlage eines Cookies

Eine andere Möglichkeit, den internen Traffic in Google Analytics 4 auszuschließen, ist die Verwendung eines Cookies. Du forderst deine Mitarbeiter auf eine bestimmte eindeutige URL zu besuchen, dann erstellst du ein Cookie im GTM und verwendest dessen Wert in der Suchtabelle-Variable.

Schritt 1 - Setze ein Cookie für interne Benutzer

Jedoch hat diese Methode auch ihre Schwächen. Wenn die meisten deiner Mitarbeiter Safari verwenden oder mit iOS surfen, kann die intelligente Tracking-Verhinderung die Lebensdauer eines Cookies begrenzen, und deine Mitarbeiter müssen dann diesen eindeutigen Link häufiger aufrufen.

Zum Beispiel lautet die URL deiner Website www.mybusiness.com. Dann kannst du deine Mitarbeiter auffordern, die folgende URL zu besuchen: www.mybusiness.com?internal_user=true

Gehe dann zum Google Tag Manager und erstelle ein benutzerdefiniertes HTML-Tag. Dann musst du den folgenden Code einfügen:

 

<script>

var cookieName = "gtm_internal_user"; // Name of your cookie

var cookieValue = "internal"; // Value of your cookie

var expirationTime = 31104000; // One year in seconds

expirationTime = expirationTime * 1000; // Converts expirationtime to milliseconds

var date = new Date();

var dateTimeNow = date.getTime();

date.setTime(dateTimeNow + expirationTime); // Sets expiration time (Time now + one month)

var date = date.toUTCString(); // Converts milliseconds to UTC time string

document.cookie = cookieName+"="+cookieValue+"; SameSite=None; Secure; expires="+date+"; path=/; domain=." + location.hostname.replace(/^www\./i, ""); // Sets cookie for all subdomains

</script>

 

Lege diesen Tag so fest, dass er bei einem Seitenaufruf-Trigger ausgelöst wird, wenn die Seiten-URL internal_user=true enthält.

Schritt 2. Cookie-Variable

Gehe auf GTM > Variablen > First Party Cookie und gebe die folgenden Einstellungen ein:

Dann speicherst du die Variable.

Schritt 3:  Erstelle einen Entwickler-Filter in GA4

Erstelle einen Entwickler-Filter in GA4 auf der Grundlage von Schritt 2 der ersten Methode.

Schritt 4:  Erstelle eine Suchtabelle-Variable in GTM, um den traffic_type Parameter zu überschreiben

Gehe auf Variablen > Neu > Suchtabelle und gebe die folgenden Einstellungen ein:

Hier wird die Variable Debug-Modus als Eingabe verwendet. Wenn der GTM-Vorschaumodus aktiviert ist, gibt diese Variable den Wert „true“ zurück. Infolgedessen wird die Suchtabelle-Variable das Wort „Entwickler" zurückgeben.

Wenn der GTM-Vorschaumodus nicht verwendet wird, gibt die Variable „Debug Mode" den Wert „false" zurück. Daraufhin wird der Wert der First-Party-Cookie-Variable zurückgegeben, die du im ersten Schritt erstellt hast.

Wenn das Cookie existiert, wird sein Wert an GA gesendet. Wenn das Cookie nicht existiert, wird er auf undefiniert gesetzt, was bedeutet, dass GA4 den Parameter traffic_type nicht sendet.

Dann speicherst du die Variable. Anschließend gehst du zu deinem Google Analytics und wählst Tag-Konfiguration aus. Du gibst den Parameter traffic_type ein und als Wert die soeben erstellte Suchtabelle-Variable

Schritt 5:  Teste die Filter

Du testest die Filter auf der Grundlage von Schritt 4 der ersten Methode.

Schritt 6:  Aktiviere beide Filter

Der letzte Schritt besteht darin, beide Filter zu aktivieren. Gehe auf Verwaltung (in GA) > Dateneinstellungen > Datenfilter und setze beide Trigger (interner Traffic-Filter und Entwickler-Filter) auf „aktiv“. Du kannst dies tun, indem du jeden Filter öffnest, seinen Filterstatus änderst und die Änderungen dann speicherst.

Du testest dann alles noch einmal auf der Grundlage von Schritt 5 der ersten Methode.

Interne Daten an eine separate GA4-Property senden

Dies ist optional, aber wenn du möchtest, kannst du die internen Daten an eine separate Property senden, anstatt mit dem traffic_type-Parameter zu arbeiten.

Grundsätzlich kannst du eine Suchtabelle-Variable erstellen, die die korrekte GA4-Messungs-ID auf der Grundlage einer Variablen auswählt, die den internen Traffic angibt. Zum Beispiel hast du eine Cookie-Variable, die Cookie-internal Traffic heißt, und ihr Wert ist „true“, wenn der Besucher einer deiner Mitarbeiter ist.

In diesem Fall gehst du auf GTM > Variablen > Neu > Suchtabelle und gibst die folgenden Einstellungen ein:

Wenn der Wert der Cookie-Variable „true“ ist, gibt sie die Messungs-ID eines Test-Propertys zurück. Hierfür solltest du eine separate GA4-Property erstellen. In allen anderen Fällen gibt die Variable die Messungs-ID Ihrer „LIVE“-Property zurück.

Der letzte Schritt besteht darin, die Suchtabelle-Variable in deinen GA4-Konfigurationstag einzufügen.

Zusammenfassung

Basierend auf den genannten Methoden kannst du den internen Datenverkehr ausschließen, aber dennoch die Debugview verwenden. Denke daran, dass keine der oben genannten Lösungen perfekt ist:

• IP-basierte Filter werden nicht funktionieren, wenn deine Mitarbeiter dynamische IP-Adressen haben.
• Die dataLayer.push-basierte Filterung erfordert den Input des Entwicklers und kann immer noch einige Mitarbeiter übersehen, die anonym surfen und sich nirgendwo angemeldet haben.
• Die Cookie-basierte Lösung basiert auf Cookies. Cookies können nicht über mehrere Geräte desselben Besuchers verteilt werden. Cookies können geleert werden. Cookies laufen aufgrund von ITP auf iOS oder Safari schneller ab. Daher müssen deine Mitarbeiter möglicherweise regelmäßig die eindeutige URL, die das Cookie setzt, erneut aufrufen.