Nutzer stimmt Analytics zu, aber der Adblocker blockiert GA4 trotzdem. Was tun?

Ein Besucher akzeptiert die Analyse-Cookies im Cookie-Banner. Die Consent-Management-Plattform erfasst seine Einwilligung korrekt. Google Analytics 4 (GA4) darf jetzt geladen werden. Trotzdem verhindert der Adblocker des Besuchers, dass die Daten bei Google ankommen.

Das ist kein ungewöhnlicher Fall. Consent-Management-Systeme und Adblocker erfüllen unterschiedliche Aufgaben und kommunizieren normalerweise nicht miteinander. Deine Consent-Management-Plattform weiß, dass der Besucher der Webanalyse zugestimmt hat. Der Adblocker erkennt dagegen lediglich eine Anfrage an eine bekannte Tracking-Domain von Google und blockiert sie anhand seiner Filterlisten.

Ein Besucher kann der Webanalyse also ausdrücklich zustimmen und trotzdem nie in GA4 auftauchen.

Wenn diese fehlenden Daten für dein Unternehmen relevant sind, gibt es eine technische Möglichkeit: Du kannst die Analytics-Anfragen über deine eigene Domain leiten, statt sie direkt an Google zu senden. Das klingt zunächst unkompliziert. Allerdings gibt es dabei einen entscheidenden Punkt: Es reicht nicht aus, nur das GA4-Skript über einen Proxy bereitzustellen.

Warum eine Einwilligung den Adblocker nicht deaktiviert

Ein Consent-Management-System steuert, welche Dienste deine Website entsprechend der Einwilligung des Besuchers laden darf. Ein Adblocker trifft eine davon unabhängige Entscheidung auf Browserebene. Er kann Anfragen an bekannte Domains von Google Analytics oder Google Tag Manager blockieren, unabhängig davon, welche Auswahl der Besucher im Cookie-Banner getroffen hat.

Der Ablauf kann deshalb so aussehen:

Besucher akzeptiert Analytics-Cookies
↓
Consent-Management gibt GA4 frei
↓
Website versucht, GA4 zu laden
↓
Adblocker blockiert die Anfrage
↓
Besucher erscheint nicht in GA4

Aus Sicht deiner Website liegt eine gültige Einwilligung vor. Für den Adblocker entspricht die Anfrage trotzdem einer seiner Filterregeln. Die beiden Systeme gleichen diese Entscheidungen normalerweise nicht miteinander ab.

Lässt sich verhindern, dass GA4 blockiert wird?

Eine Möglichkeit ist das sogenannte First-Party-Proxying. Dabei ruft der Browser die Analytics-Ressourcen nicht mehr direkt von Google ab, sondern über eine URL deiner eigenen Website. Vereinfacht sieht das so aus:

example.de/analytics/...
↓
Eigener Server
↓
Google Analytics

Für den Browser beginnt die Anfrage auf derselben Domain wie die Website. Dadurch lässt sich die Wahrscheinlichkeit verringern, dass ein Adblocker die Anfrage aufgrund einer bekannten Drittanbieter-Domain blockiert.

Eine Garantie ist das allerdings nicht. Moderne Adblocker können auch First-Party-Tracking erkennen und entsprechende Anfragen blockieren. First-Party-Proxying macht GA4 nicht immun gegen Adblocker. Es kann aber helfen, die Zuverlässigkeit der Datenerfassung zu verbessern.

Ein häufiger Fehler: Nur gtag.js über den Proxy laden

An dieser Stelle hören viele Implementierungen zu früh auf. GA4 besteht nicht nur aus einer JavaScript-Datei. Der Browser lädt zunächst den Tracking-Code von Google. Anschließend sendet dieser Code Seitenaufrufe und Ereignisse an die Messinfrastruktur von Google. Das sind voneinander getrennte Anfragen. Vereinfacht:

GA4-Skript laden
↓
GA4 ausführen
↓
Seitenaufruf oder Ereignis senden

Wenn du nur den ersten Schritt über einen Proxy leitest, lässt sich gtag.js möglicherweise erfolgreich über deine eigene Domain laden. Die eigentlichen Ereignisse werden aber weiterhin direkt an Google gesendet und können dort vom Adblocker blockiert werden.

Das macht die Fehlersuche schwierig: Das Tracking-Skript wird scheinbar problemlos geladen, in der Browserkonsole erscheint möglicherweise kein offensichtlicher JavaScript-Fehler und trotzdem kommen keine Daten in GA4 an. Wer die Datenerfassung verbessern möchte, muss deshalb beide Teile berücksichtigen:

• Das Laden des Tracking-Codes
• Die Übertragung der erfassten Ereignisse

Nur das Skript über die eigene Domain bereitzustellen, löst das eigentliche Problem nicht unbedingt.

Warum das mit Umami einfacher ist

Bei Umami ist die Umsetzung vergleichsweise unkompliziert. Umami ermöglicht es, das Ziel für Tracking-Anfragen zu konfigurieren. Bei einer selbst gehosteten Installation können sowohl das Tracking-Skript als auch der Endpunkt zur Datenerfassung über eine Infrastruktur laufen, die du selbst kontrollierst. Dadurch lässt sich der gesamte Datenfluss relativ einfach über eine eigene Domain abwickeln.

Bei GA4 ist das komplizierter. Das JavaScript und die eigentlichen Messdaten verwenden nicht zwangsläufig dieselben Google-Hosts. Genau diese Unterscheidung ist bei der Proxy-Konfiguration entscheidend.

Auch der Endpunkt für GA4-Ereignisse muss konfiguriert werden

Bei GA4 musst du sicherstellen, dass nicht nur das Skript, sondern auch die Messdaten über den vorgesehenen Endpunkt übertragen werden. Wenn du gtag.js von einer First-Party-URL lädst, bedeutet das nicht automatisch, dass anschließend auch sämtliche Analytics-Ereignisse über diese URL laufen. Viele Anleitungen zum Thema „GA4 über einen Proxy betreiben“ berücksichtigen diesen Unterschied nicht ausreichend. Der vollständige Datenfluss muss ungefähr so aussehen:

example.de/analytics/script
↓
Google-Infrastruktur für das Tracking-Skript


example.de/analytics/collect
↓
Google-Infrastruktur für die Datenerfassung

Die konkrete Umsetzung hängt von deiner technischen Umgebung ab. Je nach Konfiguration kommen beispielsweise ein Reverse Proxy, ein serverseitiger Google Tag Manager oder eine andere First-Party-Tagging-Lösung infrage. Wichtig ist vor allem:

Die URL des Tracking-Skripts und das Ziel der Messdaten sind zwei getrennte Dinge.

Wenn du nur eines davon über den Proxy leitest, kann das Tracking weiterhin blockiert werden.

Lassen sich damit alle fehlenden GA4-Daten wiederherstellen?

Nein. Adblocker sind nur einer von mehreren Gründen, warum Webanalyse-Daten unvollständig sind. Weitere Ursachen können sein:

• Besucher lehnen die Einwilligung zur Webanalyse ab.
• Datenschutzfunktionen des Browsers schränken das Tracking ein.
• JavaScript-Dateien werden nicht korrekt geladen oder ausgeführt.
• Netzwerkprobleme verhindern die Übertragung.
• Ereignisse sind falsch konfiguriert.
• Besucher verlassen die Seite, bevor eine Anfrage abgeschlossen ist.
• Unterschiedliche Attributionsmodelle führen zu abweichenden Zahlen.

First-Party-Proxying kann einen Teil dieser Messlücken reduzieren. Es macht GA4 aber nicht zu einer vollständigen Abbildung aller Vorgänge auf deiner Website. Für tatsächliche Anfragen, Bestellungen oder Buchungen sollten weiterhin dein CRM, dein Shopsystem oder deine Buchungssoftware die maßgebliche Datenquelle sein.

Ich habe mich mit diesem Problem unter anderem deshalb näher beschäftigt, weil ich bei einigen Projekten ein eigenes Consent-Management-Plugin einsetze. Damit habe ich direkten Einfluss darauf, wie die Einwilligung verarbeitet wird, wann Tracking-Skripte geladen werden und wohin die Analytics-Daten übertragen werden. First-Party-Routing lässt sich dadurch direkt in die bestehende Implementierung integrieren, statt nachträglich eine zusätzliche Lösung anzubauen.

Lohnt sich der Aufwand?

Das hängt davon ab, wie relevant die fehlenden Messdaten für dein Unternehmen sind.

Bei einer kleinen Unternehmenswebsite mit überschaubarem Traffic lohnt es sich möglicherweise nicht, zusätzliche Infrastruktur aufzubauen, nur um einen kleinen Teil der Analytics-Ereignisse zu erfassen. Anders kann es aussehen, wenn du regelmäßig in Google Ads investierst, Landingpages optimierst oder wichtige Entscheidungen anhand deiner Conversion-Daten triffst.

Wenn fehlende Ereignisse dazu führen, dass du Kampagnen falsch bewertest oder Werbebudgets auf Grundlage unvollständiger Daten verteilst, kann eine zuverlässigere Datenerfassung durchaus wirtschaftlich sinnvoll sein. Ich würde allerdings nicht sofort mit der Implementierung beginnen.

Zunächst sollte geklärt werden, ob Adblocker überhaupt einen nennenswerten Anteil der fehlenden Messdaten verursachen. Erst danach lässt sich sinnvoll entscheiden, ob sich der zusätzliche technische Aufwand lohnt.

So findest du heraus, ob dein GA4-Tracking betroffen ist

Du kannst das Problem relativ einfach selbst überprüfen.

1. Öffne deine Website in einem Browser ohne aktiven Adblocker.
2. Akzeptiere die Einwilligung zur Webanalyse.
3. Prüfe, ob der Seitenaufruf oder das gewünschte Ereignis in GA4 ankommt.
4. Wiederhole den Test mit aktiviertem Adblocker.
5. Erteile erneut deine Einwilligung.
6. Kontrolliere in den Entwicklertools des Browsers, welche Anfragen blockiert werden.

Wichtig: Überprüfe nicht nur, ob gtag.js erfolgreich geladen wird. Öffne in den Entwicklertools den Bereich Netzwerk (Network) und suche nach den Anfragen, mit denen GA4 die eigentlichen Ereignisse überträgt. Werden diese Anfragen blockiert, obwohl das Skript geladen wurde, hast du den entscheidenden Teil des Problems gefunden.

Für einen aussagekräftigen Vergleich solltest du die Tests möglichst unter denselben Bedingungen durchführen und sicherstellen, dass die jeweilige Einwilligung tatsächlich für die aktuelle Sitzung gilt.

Die Einwilligung muss weiterhin maßgeblich bleiben

Dass Analytics-Anfragen über deine eigene Domain laufen, ändert nichts an den datenschutzrechtlichen Anforderungen. Wenn ein Besucher die Einwilligung zur Webanalyse ablehnt, darf der First-Party-Endpunkt nicht dazu verwendet werden, trotzdem personenbezogene Tracking-Daten zu erfassen.

Gerade für Websites, die sich an Besucher in Deutschland oder anderen EU-Ländern richten, ist diese Trennung wichtig. Für nicht notwendige Analyse-Technologien sind insbesondere die Anforderungen der DSGVO und in Deutschland des § 25 TDDDG zu berücksichtigen. Technisch solltest du deshalb zwei Fragen getrennt betrachten:

Darf die Webanalyse ausgeführt werden?

Das wird durch die Einwilligung des Besuchers und die rechtlichen Voraussetzungen bestimmt.

Wie gelangen die Analytics-Ereignisse zuverlässig zur Analyseplattform, wenn die Verarbeitung erlaubt ist?

Das ist eine Frage der technischen Implementierung. Diese klare Trennung hilft sowohl bei der Entwicklung als auch bei der späteren Wartung und Fehlersuche.

Warum die technische Umsetzung aufwendiger ist, als sie klingt

Sobald du dich mit der konkreten Proxy-Konfiguration beschäftigst, tauchen einige Details auf, die leicht übersehen werden. Unterschiedliche Komponenten von Google Analytics können verschiedene Hosts verwenden. URL-Parameter müssen unverändert und korrekt weitergegeben werden. Komprimierte Antworten müssen richtig verarbeitet werden.

Außerdem solltest du sicherstellen, dass dein Proxy ausschließlich mit ausdrücklich zugelassenen Analytics-Endpunkten kommunizieren kann. Andernfalls riskierst du, unbeabsichtigt einen allgemein nutzbaren offenen Proxy bereitzustellen. Dazu kommen Fragen der Wartung: Wenn Google seine Tracking-Infrastruktur oder einzelne Endpunkte verändert, muss deine Implementierung weiterhin zuverlässig funktionieren. All das erklärt, warum eine vermeintlich einfache Anforderung wie

„Wir leiten GA4 einfach über unsere eigene Domain.“

in der Praxis mehr Entwicklungsarbeit verursachen kann als erwartet. Die grundsätzliche Idee ist schnell erklärt. Entscheidend ist, dass die gesamte Datenübertragung anschließend zuverlässig funktioniert.

Fazit: Was tun, wenn ein Adblocker GA4 trotz Einwilligung blockiert?

Wenn ein Besucher der Webanalyse zustimmt, sein Adblocker aber trotzdem GA4 blockiert, hast du im Wesentlichen drei Möglichkeiten:

1. Die Messlücken akzeptieren. Nicht jeder Besuch muss zwangsläufig in GA4 erfasst werden. Entscheidend ist, ob die fehlenden Daten deine Auswertungen tatsächlich beeinträchtigen.
2. Besucher bitten, ihren Adblocker zu deaktivieren. Technisch ist das eine Möglichkeit, aus Sicht der Nutzerfreundlichkeit aber selten eine besonders gute Lösung.
3. Erlaubte Analytics-Anfragen über einen First-Party-Endpunkt übertragen. Dadurch lassen sich bestimmte Blockierungsregeln umgehen und die Datenerfassung kann zuverlässiger werden.

Die dritte Möglichkeit kann sinnvoll sein. Voraussetzung ist allerdings, dass der gesamte relevante Datenfluss berücksichtigt wird und nicht nur die JavaScript-Datei. Wer GA4 zuverlässiger betreiben möchte, sollte Analytics als technische Integration betrachten – und nicht bloß als ein Skript, das irgendwo im Quellcode eingebunden wird. Das gilt besonders dann, wenn Consent Management, Google Tag Manager, GA4 und weitere Tracking-Dienste zusammenspielen müssen.