Warum Ihr GA4-Traffic nach dem Cookie-Banner als Unassigned erscheint

Alle Beiträge

Unassigned ist kein fehlender Traffic. Es ist Traffic, den GA4 erhalten hat, aber keinem Channel zuordnen konnte. Nach dem Livegang eines Banners hat das meist einen von drei Gründen: Die Einwilligung kommt mitten im Besuch, sodass die ursprüngliche Quelle schon verloren ist, die Sitzung hat nie ein session_start erfasst, oder ein Server-side-Setup gibt Pings wieder eine Identität, die anonym bleiben sollten.

Unassigned heißt erfasst, nicht verloren

Ein Besucher, der nie zustimmt, erzeugt auf einer Website mit korrekt abgesicherten Tags überhaupt keine Events. Das zeigt sich als niedrigere Gesamtzahl an Sitzungen, nicht als Zeile im Unassigned-Topf. Unassigned entsteht, wenn GA4 für eine Sitzung durchaus Events hat, sie aber keiner Channel-Definition zuordnen kann: keine Kampagnenparameter, kein brauchbarer Referrer oder kein Sitzungsstart, an den sich eine Quelle hängen ließe.

Die Beruhigung auf den meisten Hilfeseiten der Consent-Anbieter, Unassigned beweise, dass das Banner funktioniert, gilt also für die erste Form unten, aber nicht für die anderen beiden. Dort wird etwas in einer Form erfasst, mit der GA4 nichts anfangen kann. Das sollten Sie beheben, statt es hinzunehmen.

Form eins: Die Einwilligung kommt mitten im Besuch

Jemand kommt über eine Anzeige oder ein Suchergebnis, das Banner erscheint, und analytics_storage bleibt abgelehnt, während er liest. Nichts, was die Quelle tragen könnte, wird irgendwo gespeichert. Auf der dritten Seite stimmt er zu. Ab diesem Moment erfasst GA4 korrekt, aber die Seite, auf der die Erfassung beginnt, ist eine interne: Der Referrer ist Ihre eigene Domain, und die Kampagnenparameter liegen zwei Seitenaufrufe zurück. Die Channel-Regeln haben nichts zum Auslesen, also landet die Sitzung in Unassigned.

Diese Form ist echt und teilweise unvermeidbar. Sie ist aber auch die, die Sie verkleinern können. Mit aktiviertem URL-Passthrough wandern Googles Klick-IDs aus Anzeigen über den Query-String von Seite zu Seite, solange Cookies abgelehnt sind. Ein Besucher, der spät zustimmt, bringt dann trotzdem etwas Zuordenbares mit. Ob Ihnen diese Option überhaupt zur Verfügung steht, hängt davon ab, welcher Consent Mode auf Ihrer Website tatsächlich läuft.

Form zwei: Die Sitzung hat ihren Start nie erfasst

Die Channel-Zuordnung hängt am ersten Event einer Sitzung. Werden das Konfigurations-Tag und die Event-Tags unterschiedlich freigegeben oder wird der Consent-Standardwert erst gesetzt, nachdem das Google-Tag schon gefeuert hat, entstehen Sitzungen, deren erstes erfasstes Event etwas ganz anderes ist: ein Formularversand, ein Scroll, ein Kauf.

Das Erkennungszeichen sind Unassigned-Sitzungen, die Conversions enthalten. Echte Aktivität, keine Herkunft. Das ist ein Anbindungsfehler, kein Datenschutzergebnis, und er gehört zur selben Familie wie die plötzlichen Einbrüche, über die wir in Warum Ihre GA4-Conversions über Nacht eingebrochen sind geschrieben haben.

Form drei: Die abgelehnten Pings bekommen eine Identität

Über diesen Fall schreibt niemand, und er flutet eine Property am schnellsten. In einem Server-side-Setup von Google Tag Manager kann der GA4-Client seine eigenen Cookies verwalten. Bleibt er auf der Einstellung Server Managed, schreibt der Container eine First-Party-Kennung und stempelt sie auf eingehende Anfragen, auch auf die cookielosen Pings, die gerade deshalb gesendet wurden, weil die Einwilligung abgelehnt wurde.

Diese Pings kommen jetzt mit einer stabilen Kennung an. Statt in die Modellierung einzufließen, für die abgelehnter Traffic gedacht ist, werden sie als Sitzungen gezählt. Sie enthalten keine Kampagnendaten, weil nichts welche speichern durfte, also landen sie alle in Unassigned. Ihr Anteil folgt Ihrer Ablehnungsrate und taucht wenige Tage nach dem Livegang des Banners auf. Genau deshalb bekommt das Banner die Schuld.

Wir haben das bei einem laufenden Consent-Umbau gefunden, nachdem der Unassigned-Anteil des Kunden wochenlang ohne Erklärung gestiegen war. Die Lösung war eine einzige Einstellung: die Cookie-Verwaltung des GA4-Clients auf JavaScript Managed umstellen, damit ein abgelehnter Ping auf dem ganzen Weg anonym bleibt. Das ist auch der Grund, warum Sie mit dem Umzug auf einen Server nicht auf das Banner verzichten können. Mehr dazu in Brauchen Sie mit Server-side Tagging noch ein Cookie-Banner?

So erkennen Sie, welche Form Sie haben

1. Vergleichen Sie die Form, nicht die Summe

   Prüfen Sie, ob Unassigned gewachsen ist oder ob nur Ihre Gesamtzahlen gesunken sind, während der Channel-Mix gleich blieb. Eine kleinere Zahl mit demselben Mix ist Einwilligung, die wie vorgesehen funktioniert. Ein neuer Topf, den es letzten Monat noch nicht gab, ist eine Frage der Anbindung.

2. Suchen Sie nach Conversions in Unassigned

   Erstellen Sie eine explorative Datenanalyse mit Sitzungsquelle und -medium und stellen Sie Ihre Schlüsselereignisse daneben. Eine späte Zustimmung erzeugt ruhige Sitzungen. Vollständige Conversions ohne Herkunft deuten dagegen auf Form zwei und drei.

3. Lesen Sie den Consent-Status in einem Live-Hit ab

   Lehnen Sie alles ab, öffnen Sie den Netzwerk-Tab und suchen Sie die Anfrage an den Collection-Endpunkt. Der Parameter gcs benennt den Status, und G100 bedeutet, dass beide Speicherarten abgelehnt sind. Prüfen Sie jetzt, ob dieselbe Anfrage eine Client-ID enthält. Ein abgelehnter Ping mit angehängter ID ist Form drei.

4. Öffnen Sie den GA4-Client in Ihrem Server-Container

   Wenn Sie Server-side Tagging nutzen, sehen Sie sich die Cookie-Verwaltung des Clients an. Server Managed heißt: Der Container erzeugt eigene Kennungen, egal welcher Consent-Status mit der Anfrage ankam.

5. Prüfen Sie, wann der Consent-Standardwert greift

   Der Standardstatus muss gesetzt sein, bevor das Google-Tag läuft, und zwar auf jeder Seite, auch auf der ersten des Besuchs. Kommt er später, geht der erste Hit der Sitzung in einem Status hinaus, den niemand gewählt hat.

Kann die Modellierung die Lücke füllen?

Ein Teil davon ist der ehrliche Preis der Einwilligung und verschwindet nicht. Ein Besucher, der auf einer korrekt abgesicherten Website ablehnt, hinterlässt keine Sitzung. Wie viele das tun, hängt von Ihren Regionen, Ihrer Zielgruppe und Ihrem Banner-Design ab. Um die Größe für Ihre eigene Property einzuschätzen, lesen Sie die Zustimmungsrate in Ihrer CMP ab oder vergleichen Sie die GA4-Sitzungen mit den Request-Logs Ihres Servers oder CDN. Google kann einen Teil dieser Lücke modellieren, aber erst, wenn die Property die Datenschwellen aus Googles Dokumentation zum Consent Mode erreicht. Das Ergebnis ist eine Schätzung, kein Traffic, den jemand beobachtet hat.

Eines muss man klar sagen, weil die Seiten der Anbieter etwas anderes andeuten: Die Modellierung leert den Unassigned-Topf nicht. Sie füllt in den Standardberichten Lücken für Traffic, den Sie nie erfasst haben. Einer Sitzung, die ohne Quelle angekommen ist, gibt sie keine Quelle. Was nach einer Ablehnung insgesamt übrig bleibt, beschreiben wir in Was mit Ihren GA4-Daten passiert, wenn Nutzer Cookies ablehnen.

Kurz gesagt

Unassigned nach einem Banner sind drei verschiedene Probleme unter einem Etikett. Das erste ist der echte Preis einer späten Zustimmung und schrumpft mit URL-Passthrough. Das zweite ist ein Fehler in der Tag-Reihenfolge und zeigt sich an Conversions ohne Herkunft. Das dritte ist eine Server-side-Einstellung, die unbemerkt genau die Ablehnung aushebelt, die sie respektieren sollte. Prüfen Sie die Anbindung, bevor Sie sich beruhigen lassen.

Velo sendet das Consent-Signal in der Form, die Google erwartet, und zeigt Ihnen, was jeder Status tatsächlich überträgt. Ein Fehler wie der dritte ist so schon am ersten Tag sichtbar und nicht erst nach einem Monat Unassigned. Wie das funktioniert, steht auf der Produktseite.

Wenn Ihr Unassigned-Problem nichts mit Consent zu tun hat: Das Team hinter Velo pflegt im Blog von Amplio Data die vollständige Liste der Ursachen, inklusive Link-Tagging und Channel-Regeln, unter Warum GA4-Traffic als Unassigned erscheint.