Warum nach der Zustimmung Daten fehlen: die Consent-Lücke

Das Symptom: Zahlen, die nicht zur Wirklichkeit passen

Du hast einen Cookie-Banner, Tag Manager und GA4 sauber eingerichtet, und trotzdem stimmen die Zahlen nicht. Die Anfragen im Kontaktformular sind zahlreicher als die Conversions in GA4. Im Shop fehlt bei manchen Bestellungen der erste Seitenaufruf, und Besucher tauchen in den Berichten erst bei der zweiten Seite auf. Ein Fehler im Tag selbst ist es meist nicht. Hinter solchen Lücken steckt oft die Reihenfolge, in der Banner und Tag Manager ihre Arbeit erledigen.

Der große Überblick: Google Tag Manager – Anleitung, Einrichtung und DSGVO

Der Kern: Ein Tag, der beim Laden der Seite wegen fehlender Einwilligung blockiert war, wird nach der Zustimmung nicht automatisch nachgeholt. Der Tag Manager hat den Auslöser zu diesem Zeitpunkt schon abgearbeitet. Dass der Besucher später auf „Akzeptieren“ klickt, ändert daran nichts, solange du dem Container nicht ausdrücklich sagst, was dann passieren soll.

Welche Daten betroffen sind

Am sichtbarsten ist der erste Seitenaufruf. Weil der Besucher sich erst im Banner entscheidet, nachdem die Seite geladen wurde, fehlt genau dieser Aufruf in GA4 und in den Werbekonten. Das ist keine Kleinigkeit: Der erste Aufruf trägt die Information, woher der Besucher kam, etwa aus einer Anzeige oder einer Suche. Fehlt er, landet die Zuordnung im schlechtesten Fall bei „direkt“.

Dazu kommen Shop-Ereignisse wie view_item oder purchase, die vor der Rückmeldung des Banners eintreffen. Ein Beispiel: Ein kleiner Online-Shop zeigt auf der Produktseite sofort ein Produkt an, und die Seite löst view_item aus, bevor das Banner überhaupt gemeldet hat, was der Besucher gewählt hat. Das Ereignis wird blockiert und kommt nie an.

Und es trifft nicht nur neue Besucher. Auch bei wiederkehrenden Besuchern fehlen Daten, wenn das Banner seine gespeicherte Zustimmung erst nach dem Tag Manager meldet. Diese Besucher haben längst zugestimmt, der Container erfährt es aber zu spät. Die Zustimmung ist da, die Daten fehlen trotzdem. Das ist das Gemeine an der Lücke: Sie ist ein Timing-Problem zwischen Banner und Container und kein Datenschutzproblem.

Passend dazu: Cross-Domain-Tracking in GA4 richtig einrichten

Warum „einmal pro Seite“ nicht hilft

Naheliegend wäre, einen Tag auf „einmal pro Seite“ zu stellen und zu hoffen, dass er eben später feuert. Das funktioniert nicht, weil schon der blockierte Versuch zählt. Der Tag gilt damit als ausgelöst, und der Container startet ihn nach der Zustimmung nicht noch einmal. Der Besucher klickt auf „Akzeptieren“, der Seitenaufruf bleibt trotzdem aus.

So erkennst du das Problem in der Vorschau des Tag Managers:

• Öffne die Seite im Vorschaumodus ohne gespeicherte Zustimmung und beobachte, bei welchem Ereignis der Banner sein Ergebnis meldet.
• Sieh nach, ob der Pageview-Tag beim Seitenaufruf als „nicht ausgelöst“ markiert ist und nach der Zustimmung keine neue Auslösung erscheint.
• Wiederhole den Test als wiederkehrender Besucher mit bereits gespeicherter Wahl und vergleiche, ob das Zustimmungs-Update im dataLayer vor oder nach dem ersten Auslösen der Basis-Tags erscheint.
• Schau im Reiter „Einwilligung“ nach, welcher Status zum jeweiligen Zeitpunkt galt.

Lösung 1: Das Zustimmungs-Ereignis als zusätzlicher Auslöser

Die wichtigste Maßnahme: Dein Banner meldet die Entscheidung des Besuchers an den Tag Manager, meist als Ereignis im dataLayer. Wie dieses Ereignis heißt, hängt vom Banner oder von seiner Vorlage ab, schau dafür in die Dokumentation deines Anbieters oder in die Vorschau. Lege im Tag Manager einen Auslöser an, der genau auf dieses Ereignis reagiert, und hänge ihn zusätzlich an die Basis-Tags, etwa den GA4-Konfigurations-Tag.

Danach hat der Tag zwei Auslöser: den normalen beim Seitenaufruf und den neuen bei der Zustimmung. Ohne Einwilligung bleibt er beim Seitenaufruf blockiert. Sobald der Besucher zustimmt, löst der zweite Auslöser aus, und der Tag startet nach. So holst du den ersten Seitenaufruf nach.

Achte dabei auf Doppelzählungen. Hat der Tag vor der Zustimmung schon gefeuert, weil ein wiederkehrender Besucher längst zugestimmt hatte, darf er nach dem Banner-Ereignis nicht ein zweites Mal laufen. Prüfe deshalb in der Vorschau beide Fälle: Pro Seitenaufruf soll genau ein page_view ankommen, nicht keiner und nicht zwei.

Lösung 2: Blockierte Ereignisse gezielt nachreichen

Mit dem Basis-Tag allein ist es nicht getan. Auch Ereignisse, die früh beim Laden eintreten, gehen verloren. Dazu zählen view_item, view_item_list oder bei einer Danke-Seite das purchase-Ereignis. Auch diese Tags brauchen einen zweiten Auslöser auf das Zustimmungs-Ereignis, und zwar so, dass sie mit den richtigen Werten starten. Die Daten stehen dann bereits im dataLayer. Du musst sicherstellen, dass der Tag sie auch beim späteren Auslösen noch lesen kann.

Das erfordert je Ereignis eine eigene Konfiguration. Ein Beispiel aus der Praxis: Ein Handwerksbetrieb misst die Anfrage über ein Kontaktformular. Das Ereignis entsteht erst nach dem Absenden. Zu diesem Zeitpunkt hat der Besucher fast immer längst im Banner entschieden, hier ist die Lücke klein. Beim Shop mit Bestellbestätigung sieht es anders aus: Wer über einen Link direkt auf die Bestätigungsseite zurückkehrt, etwa nach einer externen Zahlung, hat den Banner womöglich nie gesehen oder eine alte Wahl gespeichert.

• Liste alle Ereignisse auf, die vor der Interaktion mit dem Banner eintreten können.
• Lege für sie zusätzliche Auslöser auf das Zustimmungs-Ereignis an.
• Kontrolliere, dass alle Parameter wie Produkt, Wert und Währung beim Nachreichen vollständig ankommen.
• Teste jedes Ereignis einzeln, mit Zustimmung beim Laden und mit Zustimmung erst danach.

Lösung 3: Die Banner-Vorlage richtig einbinden

Die dritte Stellschraube liegt beim Banner. Die Vorlage muss die gespeicherte Wahl beim Start melden, ohne auf eine Nutzerinteraktion zu warten. Wiederkehrende Besucher musst du nicht erneut fragen. Der Banner kennt ihre Entscheidung und kann sie dem Container sofort mitteilen, wenn er früh genug geladen wird.

Lade das Banner-Skript deshalb möglichst früh, vor den übrigen Tags, und binde es so ein, dass der Standardwert und das Update im Container ankommen, bevor die Basis-Tags auswerten. Wenn dein Banner dafür eine Vorlage im Tag Manager anbietet, nutze sie, statt eigenen Code zu bauen. Läuft die Meldung der gespeicherten Wahl erst nach den Basis-Tags, hilft dir Lösung 1 als Ergänzung.

So prüfst du, ob die Lücke geschlossen ist

Teste jeden Pfad einzeln, denn jeder hat eine eigene Fehlerquelle. Öffne ein privates Fenster und spiele durch: neuer Besucher mit Zustimmung, neuer Besucher mit Ablehnung, wiederkehrender Besucher mit gespeicherter Zustimmung, wiederkehrender Besucher mit gespeicherter Ablehnung. Bei Ablehnung dürfen keine Analyse- und Werbe-Tags ausgelöst werden. Bei Zustimmung muss der erste Seitenaufruf genau einmal ankommen.

Prüfe zusätzlich in GA4 mit der DebugView, ob die Ereignisse mit den erwarteten Parametern eintreffen, und im Netzwerk-Tab des Browsers, ob bei Ablehnung tatsächlich keine Anfragen an Google oder Meta gehen. Vergleiche nach einigen Tagen die Zahlen: Stimmen die Anfragen aus dem Formular grob mit den Conversions überein? Eine kleine Abweichung ist normal, denn nicht jeder Besucher stimmt zu. Eine Lücke, die mit der Zeit wächst oder nur bei bestimmten Seiten auftritt, ist ein Hinweis auf ein Timing-Problem.

Wenn du es nicht selbst machen willst

Kleine Fehler in der Reihenfolge von Banner und Tag Manager führen zu Datenverlust, und der ist hinterher nicht nachholbar. Trackum richtet Tracking ein, auch mit Consent Mode v2, mit festen Preisen vorab. Getestet wird mit und ohne Einwilligung, live geht es innerhalb eines Werktags. Der Zugriff läuft über die Nutzerverwaltung statt über ein Passwort.