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).“
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.
Vertiefe dein Wissen mit uns
Wie Kölner Stadtanzeiger Medien 80% CTR Boost mit KI erzielt
Intergastro: E-Commerce und Kundenzentrierung für B2B-Erfolg
Internen Traffic mit IPv6 Adressen ausschließen
Die Innovationskraft hinter modernem E-Commerce
Digital Operation Platform für deine E-Commerce-Optimierung
ROI-Optimierung im Commerce: KI, B2H & Omnichannel-Strategy
Erfolg im E-Commerce: UNGER setzt auf digitale Innovation
Ein Public Cloud Cheat Sheet der führenden Cloud Provider
Die bevorstehende Let's Encrypt Aktualisierung
D2C: Kundenorientierung und Personalisierung im E-Commerce
MarTech Boom, KI, Echtzeit-Datenvernetzung – Buzzword Bingo?
OVHcloud: Das Schutzschild gegen DDoS-Angriffe
Mit exzellentem Kundenservice die Kundenloyalität steigern
Die Bedrohung im Internet und wie du dich schützen kannst
So meisterst du die Herausforderungen der Kundenerwartungen
Digitale Sichtbarkeit: Ein MUSS für den Erfolg
Warum sollte eine Multi Cloud mit der OVHcloud ergänzt werde
Ist eingeschränkte Bekanntheit die Hauptbarriere?
Mit Digital Nudging die Conversion Rate im Commerce steigen
Digitalisierung beginnt mit veränderter Denkweise
Jetzt Blog abonnieren und keine News mehr verpassen
✔️kostenlos ✔️jede Woche News ✔️Expertenwissen