Digital Analytics: GA4 - Internen Traffic mit IPv6 Adressen via CIDR-Notation ausschließen… oder besser nicht?

Die Digitalisierung schreitet unaufhörlich voran und mit ihr die Weiterentwicklung von Netzwerktechnologien. IPv6-Adressen gewinnen immer mehr an Bedeutung, da der Adressraum von IPv4 langsam erschöpft ist. Doch wie passt dies in die Welt von Google Analytics 4, das primär für IPv4 konzipiert wurde? Die Verwendung von IPv6 in GA4 birgt sowohl Chancen als auch Herausforderungen. In diesem Blogbeitrag beleuchten wir, wie man IPv6-Adressen in GA4 nutzt, um internen Traffic zu filtern und gehen auf die Hürden ein, die sich durch die Fokussierung von GA4 auf IPv4 ergeben.

IPv6 ist längst der neue Standard zum Thema IP-Adressen. Trotzdem wird er oft noch in zahlreichen Firmen stiefmütterlich behandelt. Zahlreiche Unternehmen müssen sich der Anforderung stellen die IPv6 Adressen als internen Traffic bei Google Analytics 4 herauszufiltern. Dabei dreht sich die komplette Dokumentation hauptsächlich um IPv4 Adressen und auch das Interface von GA4 behandelt IPv6 Adressen als Randerscheinung. Wenn du dennoch IPv6 Adressen als internen Traffic herausfiltern musst, dann haben wir hier für dich im Folgenden ein paar wissenswerte Informationen zusammengestellt:

Grundsätzlich können aktuell alle Operatoren zur Eingrenzung internen Traffics mit IPv6-Adressen in GA4 durchgeführt werden. Von Google selbst wurde in der Dokumentation bezüglich der IPv6-Adressen-Filterung allerdings bisher nur ein Beispiel zur CIDR-Notation bereitgestellt.

Quote: „Wenn Sie IPv6-Adressen verwenden und einen Bereich ausdrücken möchten, geben Sie mit demselben „Schrägstrich“-Suffix an, wie viele Bits des Bereichs fest sind. Wenn der Bereich beispielsweise 0:0:0:0:0:ffff:c080:ff00 – 0:0:0:0:0:ffff:c080:ffff ist, geben Sie ihn als 0:0:0:0:0:ffff:c080:ff00/120 an (die ersten 120 Bits sind fest).“

Quelle: https://support.google.com/analytics/answer/10104470?sjid=12656966587956890926-EU#zippy=%2Ccidr-notation-verwenden
 

Mit dem anschließenden Beispiel erkläre ich dir das nun noch einmal genauer. Folgende IPv6-Adressen sollen zukünftig als interner Traffic herausgefiltert werden:

• 2001:9e8:c048:1d00:286c:6432:85af:efc3
• 2001:9e8:c048:1d00:286c:6432:85af:efcf
• 2001:9e8:c048:1d00:286c:6432:85af:efe8
• 2001:9e8:c048:1d00:286c:6432:85af:effa

Zuerst muss ermittelt werden, welcher Bereich diese IPs vollständig umfasst. In diesem Beispiel wäre das der Bereich von

2001:9e8:c048:1d00:286c:6432:85af:efc0 bis 2001:9e8:c048:1d00:286c:6432:85af:efff

Für die Umrechnung in die CIDR-Notation nutzen wir entsprechende Online-Tools, sogenannte IPv6 Subnet Calculator. Darüber kann ich dann mit wenigen Subnetzvorkenntnissen schnell herausfinden, dass die CIDR-Notation diese ist:

2001:09e8:c048:1d00:286c:6432:85af:efc0/122

122 Bits der IP sind als Mask Bits definiert und somit wären 64 Adressen in diesem Bereich dann zukünftig für internen Traffic herausgefiltert.

Doch wird dies in der neuen Welt von Google Analytics 4 passend berücksichtigt?

Während für Universal Analytics noch ein entsprechender Eintrag in der Google Analytics-Hilfe zu finden ist, fehlt bisher jegliche Dokumentation dazu für GA4. Allseits bekannt ist, dass die IP-Anonymisierung bei GA4 nun automatisch vorgenommen wird und nicht mehr konfiguriert werden muss. Beim Herausfiltern von internem Traffic muss diese Anonymisierung jedoch nicht mehr berücksichtigt werden. Hier können die vollständigen IP-Adressen oder IP-Bereiche angegeben werden und auch nur dieser Traffic wird dann gefiltert.

Das ist eine Verbesserung zu der Logik von Universal Analytics, wo dann maximal bis zum Anonymisierungsgrad die IPs herausgefiltert werden konnten. Das machte dort mit IPv6-Adressen Filtern zu einem unverhältnismäßigen Impact bei einer Maskierung der letzten 80 Bits und damit einem viel zu großen Adressraum, der dadurch ausgeschlossen wurde. Hier hat Google bei GA4 nun offensichtlich einen deutlich besseren Weg der IP-Anonymisierung gefunden.

Ein wichtiger Hinweis zum Thema Testing noch zum Schluss

Google weist daraufhin, dass die Filter bis zu 24 oder sogar 48h Zeit benötigen können, bis sie greifen. Ab und zu greift der Filter allerdings auch sofort. Das verführt zu früherem Testing. Da die Filter allerdings nicht zuverlässig sofort greifen, sollten die Testfälle mit Bedacht geplant und mit ausreichend Zeit durchgeführt werden. Ein guter Best Practise Tipp dazu ist: Positive & negative Testcases sollte man abwechseln. So merkt man zuverlässig anhand der Testing-Daten (im „Test data filter name“) im Real-Time-Traffic in GA4, ob der neu konfigurierte Filter schon greift.

✔️kostenlos ✔️jede Woche News ✔️Expertenwissen