Du öffnest GA4 und da ist: nichts. Keine Berichte, Echtzeit bei null, dabei hat die Website nachweislich Besucher. Hinter diesem Symptom stecken fast immer dieselben fünf Ursachen, nur sehr ungleich verteilt. Die üblichen Listen nennen sie ungeordnet, also prüfst du in zufälliger Reihenfolge. Hier steht die Kette so, wie sie sortiert gehört: von der häufigsten zur seltensten Ursache, mit dem Handgriff zum Prüfen und dem Fix dazu. Wie überall in der Fehler-Serie gilt: an der Quelle prüfen, nicht im Bericht raten.
Drei Stellen sagen die Wahrheit
Für alles Folgende brauchst du drei Prüfstellen. Der Netzwerk-Tab des Browsers (F12, Filter „collect“) zeigt, ob überhaupt ein Request an Google rausgeht. Die GTM-Vorschau zeigt, warum ein Tag feuert oder nicht feuert. Und DebugView in GA4 zeigt, ob das Event in deiner Property ankommt. Alle drei, nicht eins davon. Ein Tag kann in der Vorschau grün leuchten, während der Request unterwegs versandet; das siehst du nur im Netzwerk-Tab. Und ein Request kann sauber rausgehen und in einer fremden Property landen; das siehst du nur auf der Empfangsseite.
Ursache 1: Der Consent-Banner blockt das Tag
Der häufigste Fall hierzulande, und genau der, den amerikanische Ursachenlisten ignorieren, weil es dort kaum Banner gibt. Erkennungszeichen: GA4 ist leer oder zählt nur einen Bruchteil der Besucher, die dein Server sieht. Prüfen: Inkognito-Fenster, Seite laden, dem Banner ausdrücklich zustimmen, dann im Netzwerk-Tab nach „collect“ filtern. Kommt selbst nach der Zustimmung kein Request, blockt der Banner. Tückisch sind vor allem CMPs mit Auto-Blocking: Sie scannen Skripte und blockieren eigenmächtig, und bei falscher Kategorisierung erwischen sie GTM oder GA4 auch bei erteilter Einwilligung. Der Fix: das Tag in der CMP sauber der Statistik-Kategorie zuordnen oder das Auto-Blocking für den Tag Manager abschalten und die Freigabe über den Consent Mode steuern, nicht doppelt.
Dazu die ehrliche Einordnung: Wer ablehnt, fehlt zu Recht. Diese Lücke ist Datenschutz, kein Defekt, und kein Setup der Welt holt sie zurück.
Ursache 2: Falsche oder doppelte Measurement-ID
Erkennungszeichen: Der Netzwerk-Tab zeigt Requests, deine Property bleibt trotzdem leer. Die Daten laufen dann meist woandershin, in die alte Property des Vorgängers, eine vergessene Test-Property oder das parallele Setup eines Plugins. Prüfen: Im collect-Request steht der Parameter tid mit der Measurement-ID (G-XXXXXXX). Vergleich sie mit der ID unter Verwaltung, Datenstreams, und zwar in der Property, in die du gerade schaust. Kleiner Trick: Tipp die ID aus dem Request in die GA4-Suchleiste, du springst direkt in die Property, die die Daten wirklich bekommt. Der Fix: ID im GA4-Tag korrigieren, und wenn zwei Einbauten parallel laufen (Theme oder Plugin plus GTM), fliegt einer raus.
Ursache 3: Der GTM-Container ist nicht veröffentlicht
Klingt zu banal? Ist aber Dauergast. Tag gebaut, getestet, gespeichert, und auf „Senden“ vergessen. Erkennungszeichen: In der GTM-Vorschau funktioniert alles, live passiert nichts. Denn die Vorschau zeigt deinen Arbeitsstand, die Website bekommt nur die zuletzt veröffentlichte Version. Prüfen: in GTM unter „Versionen“ nachsehen, ob nach deiner letzten Änderung eine Veröffentlichung steht. Der Fix dauert dreißig Sekunden: Senden, veröffentlichen, fertig.
Ursache 4: Interne Filter und Thresholding
Ab hier kommen die GA4-eigenen Fallen: Daten kommen an, DebugView zeigt Events, aber die Berichte bleiben löchrig. Zwei getrennte Täter. Erstens interne Datenfilter: Ein Filter im Status „aktiv“ mit zu breiter IP-Definition löscht Traffic unwiederbringlich. Prüfen unter Verwaltung, Datenfilter; im Zweifel gehört ein Filter in den Testmodus, nicht auf aktiv. Zweitens Thresholding: Mit aktiviertem Google Signals blendet GA4 aus Datenschutzgründen Zeilen mit wenigen Nutzern aus, grob unter 50. Bei einem kleinen Konto kann das den halben Bericht kosten. Prüfen: Reporting Identity testweise auf „gerätebasiert“ stellen (nicht destruktiv, jederzeit zurückstellbar); tauchen die Zeilen auf, war es die Schwelle. Der Fix für kleine Konten ohne Remarketing: Google Signals deaktivieren. Es kostet dort nur Zeilen und bringt nichts.
Ursache 5: Es ist gar nichts kaputt
Standardberichte laufen bis zu 24 Stunden nach, bei einer frisch angelegten Property wirkt der erste Tag deshalb fast immer wie ein Totalausfall. Darum gehören Echtzeit und DebugView an den Anfang jeder Diagnose: Besuch die Seite selbst, stimm dem Banner zu und schau, ob dein Besuch im Echtzeitbericht auftaucht. Tut er das, ist die Sammlung intakt, und die Berichte füllen sich von allein. Dann ist Warten die richtige Reaktion. Wer bei intakter Sammlung am Setup dreht, baut sich den Fehler erst ein.
Die Prüfliste zum Abarbeiten
Alles zusammen, in genau dieser Reihenfolge:
- Wenn im Netzwerk-Tab auch nach Zustimmung kein collect-Request auftaucht, dann Consent-Banner und Auto-Blocking prüfen (Ursache 1).
- Wenn Requests feuern, aber die tid nicht zur Property passt, dann Measurement-ID korrigieren (Ursache 2).
- Wenn die Vorschau funktioniert und live nichts feuert, dann GTM-Container veröffentlichen (Ursache 3).
- Wenn DebugView Events zeigt, aber Berichte Zeilen verschlucken, dann Datenfilter kontrollieren und Google Signals abschalten (Ursache 4).
- Wenn Echtzeit deinen Testbesuch zeigt und nur die Standardberichte leer sind, dann bis zu 24 Stunden warten (Ursache 5).
Und wenn die Daten wieder laufen?
Dann ist das Symptom weg, aber noch nicht die Frage beantwortet, ob der Rest stimmt. Wer eine falsche ID oder einen scharf geschalteten Filter findet, findet beim zweiten Hinsehen meist mehr. Die gründliche Variante, einmal komplett durch Sammlung, Konfiguration und Conversions, steht im GA4-Audit. Diese Seite bleibt bewusst bei dem einen Symptom: leeres GA4, geordnete Kette, schnelle Diagnose.