Möchten wir in Google Analytics Rückschlüsse auf das Verhalten unserer Nutzer ziehen, so setzen wir (stillschweigend) voraus, dass die Daten, mit denen wir arbeiten, sauber und qualitativ hochwertig sind. Allerdings werden ohne weiteres Zutun in Google Analytics die Daten externer und interner Benutzer zusammengeworfen. Das Verhalten dieser beiden Nutzergruppen dürfte sich aber grundsätzlich voneinander unterscheiden.
Wenn in Unternehmen die Startseite eines Browser standardmäßig mit der Corporate Website belegt ist, diese nach Aufruf aber in den meisten Fällen wieder verlassen wird, stehen am Ende viele Sitzungen mit erhöhten Absprungraten.
So ist es also ratsam, externe und interne Benutzer getrennt zu betrachten.
Wir sollten also eine separate Datenansicht anlegen, in der interne Benutzer ausgeschlossen werden. Im folgenden beleuchten wir zwei Möglichkeiten, interne Nutzer auszuschließen. Erste Erfahrungen im Umgang mit Google Analytics und dem Google Tag Manager sind sicherlich von Vorteil.
![](https://blog.comspace.de/wp-content/uploads/2018/09/kaffeefilter.jpg)
Möglichkeit eins: Ausschluss über einen IP-Filter
Zunächst legen wir in Google Analytics eine neue Datenansicht an, benennen diese und wählen die passende Zeitzone aus.
![Google Analytics - Datenansicht erstellen](https://blog.comspace.de/wp-content/uploads/2018/08/google_analytics_-_datenansicht_erstellen.jpg)
Anschließend legen wir einen Filter an (Verwaltung ▹ Datenansicht ▹ Filter ▹ Filter hinzufügen).
Die View-basierten Filter in Google Analytics bieten die Möglichkeit, Nutzer anhand ihrer IP-Adresse ein- oder auszuschließen. Unternehmen haben in der Regel eine oder mehrere feste IP-Adressen.
Zunächst sollte klar sein, welche IP-Adresse ausgeschlossen werden soll. Ein Besuch von https://www.wieistmeineip.de liefert einen ersten Hinweis – vergewissert Euch sicherheitshalber bei Eurer IT, ob es ggf. mehrere feste IP-Adressen oder IP-Ranges gibt, die später im Filter berücksichtigt werden sollen. Unter Umständen hat Euer Unternehmen auch verschiedene Niederlassungen in unterschiedlichen Ländern. Das macht es natürlich etwas komplizierter. Das Prinzip bleibt aber dasselbe.
Vorsicht: Ist Google Analytics datenschutzkonform eingesetzt, so werden die IP-Adressen maskiert, d. h. das letzte Oktett der IP-Adressen wird vor der Verarbeitung der Daten auf „0“ gesetzt. Aus 194.145.124.105 wird 194.145.124.0. Wird das letzte Oktett in dem IP-Filter nicht genullt, so funktioniert dieser Filter leider nicht, da es ja keine Übereinstimmung gibt.
Wie lässt sich ermitteln, ob anonymizeIP verwendet wird?
Sofern Google Analytics über den Google Tag Manager konfiguriert wurde – und Ihr Zugriff auf den GTM habt – könnt ihr dort prüfen, ob die Funktion „anonymizeIp“ auch wirklich aktiv ist. Normalerweise wird die Funktion innerhalb des Variablentyps „Google Analytics-Einstellungen“ gesetzt.
Unter „Festzulegende Felder“ findet Ihr den Eintrag „anonymizeIp“, dem ein boolescher Wert zugewiesen wird. Ist dieser Wert „true“, ist alles fein.
Verwendet ihr keinen Google Tag Manager, oder habt keinen Zugriff darauf, könnt Ihr Euch mit dem Browser-AddOn „WASP“ (Web Analytics Solution Profiler) behelfen, welches in den Entwicklertools ausgeführt wird.
In folgendem Screenshot wird skizziert, wie und wo Ihr in WASP die Information abruft (Zur Erinnerung: Der Wert, den die Funktion anonymizeIp zurückgibt, ist ein boolescher Wert. Dieser ist also wahr (=1) oder falsch (=0).
Kurzer Exkurs: IP-Adressen pseudonymisieren
Leider verarbeitet Google Analytics die IP-Adressen standardmäßig nicht pseudonymisiert, d. h. hier müsst Ihr etwas nachhelfen (den Unterschied zwischen Pseudonymiserung und Anonymisierung erläutert Rechtsanwalt Dr. Thomas Schwenke).
Variante A: Google Tag Manager
Am einfachsten könnt Ihr die Funktion über den GTM-Variablentyp „Google Analytics-Einstellungen“ ausspielen. In dieser Variable wird u. a. die Tracking-ID von Google Analytics gespeichert, aber auch andere Funktionen können hinzugefügt werden.
Die Tracking-ID kann natürlich auch innerhalb der Tags definiert werden, aber das Zurückgreifen auf eine Variable ist etwas einfacher, da Ihr nicht bei Erstellung neuer Tags jedesmal die UA-ID raussuchen müsst.
Im GTM klickt Ihr zunächst auf „Variablen“ und anschließend auf „Neu“ unter „Benutzerdefinierte Variablen“. Ihr gebt eurer Variablen zunächst einen Namen mit Wiedererkennungswert, z. B. „Google Analytics ID“ und wählt dann unter „Variable konfigurieren“ den Variablentyp „Google Analytics-Einstellungen“ aus.
Jetzt tragt Ihr Eure Tracking-ID ein, klickt anschließend auf „Weitere Einstellungen“, „Festzulegende Felder“ und die Schaltfläche „Feld hinzufügen“. Unter Feldname tragt Ihr „anonymizeIp“ (in der „CamelCase“-Notation) ein und weist den Wert „true“ zu. Speichern nicht vergessen.
Nun müsst Ihr nur noch in jedem Tag des Typs „Universal Analytics“ unter „Google Analytics-Einstellungen“ die eben angelegte und gespeicherte Variable auswählen und zuweisen.
Danach speichert Ihr die Einstellungen und veröffentlicht den Container.
Variante B: Ergänzung des Trackingcodes
Habt Ihr den Trackingcode (Universal Analytics / analytics.js) direkt und ohne Umweg über den Google Tag Manager in den Quellcode Eurer Webseiten eingefügt, so müsst Ihr diesen lediglich um eine Funktion ergänzen:
[pastacode lang=“javascript“ manual=“ga(’set’%2C%20’anonymizeIp’%2C%20true)%3B“ message=““ highlight=““ provider=“manual“/]
Wichtig ist, dass Ihr diese Zeile vor dem Aufruf zum Senden des Pageviews einfügt. Insgesamt sollte der Trackingcode dann in etwa so aussehen:
[pastacode lang=“markup“ manual=“%3Cscript%3E%0A(function(i%2Cs%2Co%2Cg%2Cr%2Ca%2Cm)%7Bi%5B’GoogleAnalyticsObject’%5D%3Dr%3Bi%5Br%5D%3Di%5Br%5D%7C%7Cfunction()%7B%0A(i%5Br%5D.q%3Di%5Br%5D.q%7C%7C%5B%5D).push(arguments)%7D%2Ci%5Br%5D.l%3D1*new%20Date()%3Ba%3Ds.createElement(o)%2C%0Am%3Ds.getElementsByTagName(o)%5B0%5D%3Ba.async%3D1%3Ba.src%3Dg%3Bm.parentNode.insertBefore(a%2Cm)%0A%7D)(window%2Cdocument%2C’script’%2C’https%3A%2F%2Fwww.google-analytics.com%2Fanalytics.js’%2C’ga‘)%3B%0A%0Aga(‚create’%2C%20’UA-12345678-X’%2C%20’auto‘)%3B%0Aga(’set’%2C%20’anonymizeIp’%2C%20true)%3B%0Aga(’send’%2C%20’pageview‘)%3B%0A%3C%2Fscript%3E“ message=““ highlight=““ provider=“manual“/]
Seit kurzem empfiehlt Google die Verwendung des sog. Allgemeinen Website Tags, kurz gtag.js. Der gtag.js Tracking-Code sieht in etwa so aus:
[pastacode lang=“markup“ manual=“%3C!–%20Global%20site%20tag%20(gtag.js)%20-%20Google%20Analytics%20–%3E%0A%3Cscript%20async%20src%3D%22https%3A%2F%2Fwww.googletagmanager.com%2Fgtag%2Fjs%3Fid%3DUA-12345678-X%22%3E%3C%2Fscript%3E%0A%3Cscript%3E%0A%20%20window.dataLayer%20%3D%20window.dataLayer%20%7C%7C%20%5B%5D%3B%0A%20%20function%20gtag()%7BdataLayer.push(arguments)%3B%7D%0A%20%20gtag(‚js’%2C%20new%20Date())%3B%0A%0A%20%20gtag(‚config’%2C%20’UA-12345678-X‘)%3B%0A%3C%2Fscript%3E“ message=““ highlight=““ provider=“manual“/]
Die Zeile vor dem schließenden </script> muss wie folgt ergänzt werden:
[pastacode lang=“javascript“ manual=“gtag(‚config’%2C%20’UA-12345678-X’%2C%20%7B%20’anonymize_ip’%3A%20true%20%7D)%3B“ message=““ highlight=““ provider=“manual“/]
Die IP-Adressen werden nun pseudonymisiert von Google Analytics gespeichert und verarbeitet, und unser IP-Filter schließt internen Traffic aus. So weit so gut. Aber…
Nachteil des IP-Filters
Die Kombination von anonymizeIp und der Filterung einer IP-Adresse bewirkt, dass ich eben nicht nur eine IP-Adresse ausschließe, sondern alle IP-Adressen, die das letzte Oktett „maskiert“.
Der Filter ist so eingestellt, dass die Adresse 194.145.124.0 gefiltert wird. Dahinter befindet sich sowohl „unsere“ 194.145.124.105 als auch
194.145.124.0
194.145.124.1
194.145.124.2
194.145.124.3
…
194.145.124.255
Wir nehmen also das gesamte letzte Oktett in Sippenhaft und verteilen hier eine Kollektivstrafe. Der negative Effekt verstärkt sich, sobald mehrere, unterschiedliche IP-Adressen (keine IP-Ranges, die sich nur im letzten Oktett unterscheiden) gefiltert werden.
Möglichkeit zwei: Zeig‘ mir Deine IP-Adresse und ich sage Dir, wer Du bist!
Um diesen Weg nachbilden zu können, benötigt Ihr den Google Tag Manager. Habt Ihr? Gut.
Kurz zusammengefasst: Im folgenden zeige ich, wie Ihr die IP-Adresse eurer Benutzer feststellt, noch bevor diese im Nebel der Pseudonymisierung verblasst. Das passiert, ohne dass diese Daten an die Google Analytics-Server gesendet werden. Dazu wird über den GTM ein Dienst (ipify.org) angesprochen, der Euch die IP-Adresse der Nutzer zurückgibt, die wiederum einem Abgleich (interner oder externe Benutzer?) unterzogen wird. Diese Information wiederum schreibt Ihr in eine benutzerdefinierte Dimension, anhand derer im letzten Step ein Filter erstellt wird.
Über den Webservice ipify.org lasst Ihr euch die IP-Adresse des Nutzer ausgeben. Diese wird anschließend in den dataLayer gepusht (dadurch lässt sich die IP-Adresse an anderer Stelle wiederverwenden).
Zunächst legt Ihr einen Tag des Typs „Benutzerdefiniertes HTML“ an. Als Trigger wählen Ihr „All Pages“ (Seitenaufrufe).
[pastacode lang=“markup“ manual=“%3Cscript%20type%3D%22application%2Fjavascript%22%3E%0A%20%20function%20getIP(json)%20%7B%0A%20%20%20%20dataLayer.push(%7B%22event%22%3A%22getIp%22%2C%22ipAddress%22%20%3A%20json.ip%7D)%3B%09%0A%20%20%7D%0A%3C%2Fscript%3E%0A%0A%3Cscript%20type%3D%22application%2Fjavascript%22%20src%3D%22https%3A%2F%2Fapi.ipify.org%3Fformat%3Djsonp%26callback%3DgetIP%22%3E%3C%2Fscript%3E“ message=““ highlight=““ provider=“manual“/]
Die IP-Adresse wird also über das benutzerdefinierte HTML-Tag in den dataLayer geschrieben. Diese Variable werdet Ihr gleich noch verwenden, daher leget Ihr als nächstes eine benutzerdefinierte Variable des Typs „Datenschichtvariable“ an (Name der Datenschichtvariable: „ipAddress“, den Ihr bereits oben im dataLayer.push definiert habt):
Die Einstellungen könnt Ihr nun kontrollieren, indem Ihr nach dem Speichern in den Vorschaumodus (Schaltfläche oben rechts) wechselt und Eure Website anschließend ladet. Im unteren Teil des Fensters sollte sich der Debug-Mode des GTM öffnen. In der linken Spalte sollte das Event „getIp“ auftauchen. Klickt dies an und wechselt auf die Data Layer-Ansicht. Jetzt wird, wenn alles geklappt hat, Eure IP-Adresse angezeigt (jetzt können die ersten Sektkorken knallen):
So weit, so gut. Der nächste Schritt besteht darin, dem Google Tag Manager mitzuteilen, welche IP-Adresse(n) den internen Benutzern zugewiesen wird. Das erledigt die benutzerdefinierte Variable „Suchtabelle“ für Euch. Wie immer, müssen Variablen genauso wie Tags und Trigger benannt werden. Als nächstes wählt Ihr die Eingabevariable aus: Das ist in diesem Fall die Datenschichtvariable „DSV – IP address“, die Ihr vorhin angelegt habt.
Der Wert dieser Variable wird nun ausgelesen. In das Feld „Eingabe“ gebt Ihr eure interne(n) IP-Adresse(n) ein, die später gefiltert werden soll(en) und gebt einen gängigen Namen als Ausgabewert ein, z. B. „internal“. Das Häkchen bei „Standardwert festlegen“ solltet Ihr setzen, denn hier könnt Ihr der Suchtabelle mitteilen, dass alles, was nicht einer internen IP-Adresse entspricht, als „extern“ ausgegeben werden soll.
Die Werte „internal“ bzw. „external“ sollen als nächstes als Eigenschaften einer benutzerdefinierten Dimension ausgegeben werden. Bevor Ihr die notwendigen Einstellungen im Google Tag Manager erledigt, müsst Ihr den sog. Indexwert in Google Analytics ermitteln. Dazu werft einen Blick in die zugehörige GA-Property (Verwaltung ▹ Property ▹ Benutzerdefinierte Definitionen ▹ Benutzerdefinierte Dimensionen).
Dort klickt Ihr auf die rote Schaltfläche „+ Neue Benutzerdefinierte Dimension“.
Im nächsten Fenster könnt Ihr Eure benutzerdefinierte Dimension benennen. Ich habe diese „Traffic Type“ genannt. Als nächstes entscheidet Ihr, auf welcher Ebene die benutzerdefinierte Dimension angelegt werden soll. Ich habe mich hier für die Nutzer-Ebene entschieden.
Das Merkmal, ob der Websitebesucher als interner oder externer Benutzer eingeordnet wird, wird im Besucher-Cookie gespeichert und ändert sich nicht, solange der Cookie nicht gelöscht wird. Das heißt: Werdet Ihr bei Eurem ersten Besuch als interner Besucher einsortiert, so ändert sich dieser Status bei weiteren Besuchen nicht (wie erwähnt: es sei denn, der Cookie wird gelöscht oder Ihr besucht die Website mit einem anderen Gerät oder Browser).
Das Häkchen bei „Aktiv“ setzt Ihr bitte ebenso. Nachdem Ihr die Einstellungen gespeichert habt, generiert Google Analytics Code-Schnipsel, damit die Benutzerdefinierte Dimension später passend in den Tracking Code integriert werden kann. Für Euch ist an dieser Stelle aber nur eine Zahl relevant, in diesem Fall (siehe Bildschirmfoto) die „2“ hinter dimension.
Dies ist der Indexwert, den Ihr als Nächstes im Google Tag Manager verwenden dürft. Die Benutzerdefinierte Dimension legt Ihr in der Variable „Google Analytics-Einstellungen“ an. Zur Erinnerung: Das ist die Variable, in der Ihr die Funktion „anonymizeIp“ angelegt habt (siehe oben).
Unter „Weitere Einstellungen“ klickt Ihr auf „Benutzerdefinierte Dimensionen“, dann auf „+ Benutzerdefinierte Dimension hinzufügen“.
In das Feld „Index“ tragt Ihr den eben in Google Analytics ermittelten Indexwert der Benutzerdefinierten Dimension ein. Als Dimensionswert wählt Ihr die vorhin angelegte Variable (Suchtabelle). Der Name der Variable muss zwischen zwei geschweiften Klammern stehen (nachdem Ihr zwei sich öffnende geschweifte Klammern eingetippt habt, öffnet sich wie von magischer Hand ein Auswahlmenü Eurer bereits angelegten Variablen). Oder Ihr könnt genauso gut auf das Legostein-Symbol klicken und anschließend die passende Suchtabellen-Variable auswählen. Speichern, und dann ist auch dieser Schritt erledigt.
Wichtiger Hinweis: Belasst Ihr es bei diesen Tag Manager-Einstellungen, wird der Filter, den Ihr im nächsten Schritt anlegt, vermutlich nicht funktionieren. Wie Ihr in unten dargestelltem Screenshot des GTM Debug-Fensters erkennen könnt (linke Spalte), wird das getIp-Event zeitlich nach dem Page View-Event („gtm.js“) geladen.
Das heißt: In diesem Zustand wird die Unterscheidung zwischen externen und internen Benutzern noch nicht vorgenommen, sodass alle Benutzer zunächst den Standardwert „external“ erhalten. Für den GA-Filter sind diese Benutzer also erstmal externe Besucher und fallen durch das Raster. Ihr solltet die Reihenfolge der abzufeuernden Tags so wählen, dass der HTML-Tag, der für die IP-Abfrage zuständig ist, vor den GA-Tags (Seitenaufruf-Tags etc.) gefeuert wird.
Geht dazu in die Einstellungen des GA-Tags und klickt in den Bereich Erweiterte Einstellungen ▹ Tag-Reihenfolge. Dort aktiviert Ihr das Kästchen „Ein Tag auslösen, bevor das Tag GA – Pageview – All Pages ausgelöst wird“ und wählt als Setup-Tag Euer benutzerdefiniertes HTML-Tag aus. Dies bewirkt, dass die Tags sequenziell gefeuert werden.
Wie immer im Google Tag Manager solltet Ihr unbedingt von der Vorschaufunktion Gebrauch machen. Die liefert gleich die Antwort auf die Frage, ob die Einstellungen korrekt vorgenommen wurden. Nachdem Eure Website geladen wurde, wird (idealerweise) in der linken Spalte des Debug-Fensters das vorhin angelegte Event „getIp“ aufgerufen. Nachdem Ihr auf „getIp“ geklickt habt, prüft im größeren Sichtbereich des Fensters die ausgegebenen Variablen. Sofern Ihr mit einer als „intern“ festgelegten IP-Adresse unterwegs seid, seht Ihr in den Google Analytics-Einstellungen nun die Eigenschaft, die der benutzerdefinierten Dimension „Traffic Type“ zugewiesen wurde.
Zu guter Letzt: Filter in Datenansicht anlegen
Bevor Ihr den internen Traffic kategorisch ausschließt. empfehle ich, dafür eine neue Datenansicht anzulegen. Ihr wählt die gewünschte View (Datenansicht) aus und klickt in der Verwaltung auf „Filter“. Dort legt Ihr einen neuen Filter an und wählt folgende Settings:
- Filtertyp: „Benutzerdefiniert“ und „Ausschließen“
- Filterfeld: „Traffic Type“
- Filtermuster: „internal“
Diese Einstellungen speichert Ihr ab und überprüft diese über die Google Tag Manager Vorschauansicht und – doppelt hält besser – über den Google Analytics-Echtzeitbericht. Befindet Ihr euch im Netzwerk, dessen IP-Adresse Ihr gerade ausgeschlossen habt, sollte der Real Time Report Eure Sitzung nicht protokollieren. Falls auf Eurer Website soviel Traffic aufläuft, sodass Ihr eure Zugriffe im Echtzeitreport denen von „regulären“ Besuchern nicht unterscheiden könnt, empfehle ich die Erstellung einer Datenansicht mit „inversem“ Filter. Beziehungsweise könnt Ihr, falls Ihr bereits eine Testdatenansicht nutzt, den gleichen Filter wie oben aufsetzen, mit dem kleinen Unterschied, dass Ihr den Filtertyp „Nur einschließen“ anstatt „Ausschließen“ wählt. In dieser Datenansicht taucht dann ausschließlich der interne Traffic auf.
Ein kleiner Tipp zum Schluss: Haltet auch immer eine Datenansicht vor, in der sowohl interner als auch externer Traffic auflaufen. Für beide Traffictypen lassen sich wunderbar benutzerdefinierte Segmente erstellen, die nebeneinander angewendet werden können, um so das Benutzerverhalten beider Gruppen miteinander zu vergleichen.
- usercentrics CMP Version 2 – Was Sie erwartet und worauf Sie beim Umstieg achten sollten - 24. November 2020
- Interne Benutzer in Google Analytics-Views filtern - 13. September 2018
- Was Attributionsmodelle und Fußball gemeinsam haben - 2. Februar 2018
Super Anleitung, vielen Dank! Leider scheitert es bei mir an dem letzten Schritt. Das Filterfeld „Traffic Typ“ gibt es bei mir in Analytics so nicht. Meinst du das Filterfeld „Treffer Typ“?
Hi Sascha,
das Filterfeld bezieht sich auf die im Schritt vorher angelegte benutzerdefinierte Dimension. Wenn Du diese angelegt hast (auf Property-Ebene), dann kannst Du im Filterfeld die Suche (Lupe-Symbol) nach Traffic-Type suchen oder nach ganz unten scrollen, wo die benutzerdefinierten Dimensionen aufgeführt sind.
Viele Grüße
Benjamin
Vielen Dank für den Artikel. Die Möglichkeit 2 mit ipify.org ist Datenschutzmäßig in Ordnung (DSGVO und ePrivacy)?
Hallo Markus,
das sollte jemand mit Legal Background entscheiden. Wichtig ist, dass hier die ermittelte IP-Adresse des Nutzers (kann ja auch in einem ganz anderen Kontext verwendet werden) nur zum Abgleich verwendet und nicht an Google Analytics (z. B. in einer benutzerdefinierten Dimension o. ä.) gesendet wird. Grundsätzlich sollte natürlich darauf geachtet werden, dass Google Analytics datenschutzkonform eingesetzt wird. Dazu gibt es mittlerweile einige Consent Management Tools am Markt (usercentrics, OneTrust, Cookiebot oder Borlabs speziell für WordPress-Projekte, um nur einige zu nennen), die genau das leisten.
Viele Grüße
Benjamin