Muss ich in GA4 die IP-Anonymisierung noch aktivieren?

Nein, einen Schalter wie anonymize_ip gibt es in GA4 nicht mehr. GA4 nutzt die IP-Adresse zur groben Standortbestimmung und verwirft sie, bevor die Daten gespeichert werden.

Erhält Google die IP-Adresse auch, wenn ein Besucher Analytics ablehnt?

Im erweiterten Consent Mode ja: Die cookielosen Pings enthalten zwar keine Analytics-Cookies, aber wie jede Anfrage die IP-Adresse. Google verarbeitet sie, bevor sie verworfen wird.

Wie verhindere ich, dass Google die echte IP ablehnender Besucher sieht?

Mit einem Server-Container, über den alle Anfragen laufen. Er reicht die echte IP nur bei erteilter Analytics-Einwilligung durch und ersetzt sie sonst über ip_override durch eine Ersatzadresse.

GA4 und IP-Anonymisierung: Wann die Voreinstellung nicht reicht

GA4 speichert keine IP-Adressen – bekommt sie aber trotzdem. Wann das für Shops in Deutschland, Österreich und der Schweiz zum Problem wird und wie ein Server-Container die IP vorher austauscht.

Wer von Universal Analytics kommt, kennt den Schalter noch: anonymize_ip setzen, fertig. In GA4 gibt es diesen Schalter nicht mehr. Google anonymisiert selbst – und viele schließen daraus, dass das Thema erledigt ist.

Für die meisten Websites stimmt das auch. Für einen Teil der Händler im DACH-Raum aber nicht, und der Grund liegt in einem Detail: GA4 speichert keine IP-Adressen. Google empfängt sie aber.

Was GA4 mit der IP-Adresse macht

Jede Anfrage aus dem Browser an Google Analytics trägt die IP-Adresse des Besuchers mit, schlicht weil das Internet so funktioniert. GA4 nutzt sie im Moment der Erfassung, um grob den Standort abzuleiten – Land, Region, Stadt. Danach wird die Adresse verworfen, bevor die Daten gespeichert oder in Berichten ausgewertet werden.

Konfigurieren müssen Sie dafür nichts. In der Vorschau eines Server-Containers sieht man es gut: Der Parameter mit der Nutzer-IP taucht in der Anfrage auf und ist im weitergeleiteten Ereignis nicht mehr enthalten.

Das ist ein vernünftiger Standard. Er beantwortet aber nur die Frage, was Google aufbewahrt – nicht, was Google erhält.

Die Lücke: Anfragen ohne Einwilligung

Spannend wird es mit dem Consent Mode v2. Seit März 2024 verlangt Google für bestimmte Werbe- und Messfunktionen im EWR, im Vereinigten Königreich und in der Schweiz Einwilligungssignale. Im erweiterten Modus („Advanced“) senden die Google-Tags auch dann Daten, wenn ein Besucher Analytics ablehnt – als sogenannte cookielose Pings. Google nutzt sie, um fehlende Daten statistisch zu modellieren.

Diese Pings enthalten keine Analytics-Cookies. Sie enthalten aber, was jede Anfrage enthält – darunter die IP-Adresse. Google verarbeitet sie, bevor sie verworfen wird.

Genau hier liegt der Knackpunkt: Ein Besucher hat Nein gesagt, und trotzdem landet seine IP-Adresse bei einem Drittanbieter. Nach der DSGVO kann eine IP-Adresse personenbezogen sein, je nach Zusammenhang sogar dann, wenn sie gekürzt ist. Ob das im Einzelfall ein Problem ist, ist eine rechtliche Bewertung, die wir nicht ersetzen – aber es ist eine Frage, die Datenschutzbeauftragte zunehmend stellen. (Mehr zum Hintergrund: Server-Side Tracking und DSGVO.)

Wer genauer hinsehen sollte

Für viele Shops ist das Standardverhalten von Google ausreichend. Strengere Anforderungen haben typischerweise Unternehmen, die

eigene Datenschutzrichtlinien haben, nach denen personenbezogene Daten vor der Weitergabe an Dritte anonymisiert werden müssen,
an Konzerne oder öffentliche Auftraggeber liefern, die im Einkauf Datenschutzfragebögen verschicken,
sensible Themen bedienen – Gesundheit, Medizinprodukte, Apotheken, Finanzen, Versicherungen, Bildung,
in Ländern mit strengen Aufsichtsbehörden tätig sind. Deutschland und Österreich gehören ausdrücklich dazu; beide Länder haben in der Vergangenheit Analytics-Implementierungen kritischer bewertet als andere.

Wer sich in dieser Liste wiederfindet, will in der Regel eine Architektur, bei der Google die echte IP-Adresse eines ablehnenden Besuchers gar nicht erst sieht.

Die Lösung: austauschen, bevor es rausgeht

Ohne eigenen Server geht das nicht, denn der Browser schickt seine Anfragen direkt an Google. Mit einem Server-Container läuft jede Anfrage zuerst über Ihre eigene Subdomain. Dort können Sie bestimmen, was weitergegeben wird – auch die IP-Adresse.

Wer die echte IP-Adresse sieht

Ohne Server-Container

Browser sendet direkt an Google
Echte IP auch bei Ablehnung

Mit Server-Container

Anfragen über eigene Subdomain
Echte IP nur bei Einwilligung
Sonst eine Ersatzadresse

Die Logik ist einfach:

Analytics-Einwilligung	Was GA4 als IP-Adresse erhält
erteilt	die echte IP-Adresse; GA4 verarbeitet sie wie gewohnt und verwirft sie
abgelehnt oder unbekannt	eine Ersatzadresse, die nur noch den ungefähren Standort trägt

Wichtig ist die Richtung der Regel: Die echte IP wird nur bei einer ausdrücklichen Einwilligung durchgereicht. Alles andere – Ablehnung, fehlendes Signal, unbekannter Zustand – bekommt die Ersatzadresse. So führt ein Fehler in der Konfiguration im Zweifel zu weniger statt zu mehr Daten.

So sieht das im Server-Container aus

Die Umsetzung mit Stape braucht keinen kostenpflichtigen Tarif. Drei Bausteine:

1. Eine Ersatzadresse. Stape bietet die Erweiterung „GEO Headers“. Sie ermittelt aus der echten IP den Standort des Besuchers und hängt ihn als zusätzliche Header an die Anfrage – darunter eine Adresse, die für die Standortbestimmung genügt. Sie wird im Stape-Konto beim Container unter den Power-ups aktiviert.

2. Das Einwilligungssignal. Google-Tags übertragen den Consent-Status im Parameter gcs. Der Wert hat die Form G1 plus zwei Ziffern: die erste für Werbung (ad_storage), die zweite für Analytics (analytics_storage), jeweils 1 für erteilt und 0 für abgelehnt. Analytics ist also bei G101 und G111 erteilt. Im Server-Container liest eine Variable vom Typ „Event Data“ diesen Wert aus.

3. Eine Entscheidungsvariable. Eine Lookup-Tabelle verbindet beides: Steht in gcs einer der beiden Werte mit erteilter Analytics-Einwilligung, gibt sie die echte IP aus dem Request-Header zurück (bei Stape meist x-real-ip – ein Blick in die eingehende Anfrage in der Vorschau zeigt, wie der Header bei Ihnen heißt). In allen anderen Fällen gibt sie die Ersatzadresse aus dem GEO-Header zurück.

Diese Variable tragen Sie im GA4-Tag des Server-Containers unter den Ereignisparametern ein: Parameter ip_override, Wert die Lookup-Tabelle. Damit überschreibt sie die ursprüngliche Adresse, bevor die Anfrage an Google geht.

Testen, bevor es live geht

Prüfen Sie beide Fälle in der Vorschau von Web- und Server-Container:

Einwilligung ablehnen, ein Ereignis auslösen. In der Server-Vorschau unter „Request“ die ausgehende Anfrage an Google Analytics öffnen und den Parameter _uip prüfen: Er darf nicht Ihre echte IP enthalten. Leicht abweichend von der Ersatzadresse ist er trotzdem – GA4 kürzt auch sie noch einmal.
Einwilligung erteilen, erneut auslösen: Jetzt kommt die echte Adresse an, die GA4 wie gewohnt verarbeitet.
In den GA4-Echtzeitberichten nachsehen, ob Land und Stadt weiterhin plausibel ankommen.

Der dritte Punkt zeigt den Preis: Die Standortdaten werden bei ablehnenden Besuchern etwas gröber. Für die meisten Auswertungen im Shop ist das unerheblich; wer Kampagnen auf Stadtebene steuert, sollte es wissen.

Fazit

GA4 anonymisiert zuverlässig, was es speichert. Was es empfängt, liegt außerhalb Ihrer Kontrolle – solange die Anfragen direkt aus dem Browser kommen. Ein Server-Container holt diese Kontrolle zurück: Die echte IP-Adresse erreicht Google nur noch, wenn der Besucher eingewilligt hat.

Das ist kein Ersatz für eine rechtliche Prüfung und kein Freifahrtschein, aber eine saubere technische Antwort auf eine Frage, die im DACH-Raum immer häufiger gestellt wird. Mehr dazu, wie Server-Side Tracking Datenflüsse kontrollierbar macht, auf unserer Seite zu Datenschutz; Begriffe wie Consent Mode oder sGTM erklärt das Glossar. Für Ihr Setup: Erstgespräch anfragen.