Warum Tags mit functionality_storage nie ausgelöst werden
Das Tag wird nur ausgelöst, wenn jedes erforderliche Signal beim Auslösen des Triggers erteilt ist. Eine Consent-Einrichtung kann functionality_storage und personalization_storage standardmäßig ablehnen und danach nur die vier Signale aktualisieren, die Googles Werbe- und Analyse-Tags lesen. Die beiden bleiben auch nach einer Zustimmung abgelehnt. Ordnen Sie sie in Ihrem Banner zu oder verlangen Sie ein Signal, das aktualisiert wird.
Starten Sie mit einer Analyse.
Die kostenlose Analyse liest das HTML Ihrer Startseite und Ihren öffentlichen Tag-Manager-Container und listet die gefundenen Tracking-Tags auf.
Kostenlos · Ohne Registrierung · Prüft HTML und öffentlichen GTM-Container
Wofür sind functionality_storage und personalization_storage da?
Die Consent-Mode-Übersicht von Google nennt sieben Einwilligungstypen. Sie beschreibt, wie Tags auf vier davon reagieren: ad_storage, analytics_storage, ad_user_data und ad_personalization. Die anderen drei sind über ihren Zweck definiert. functionality_storage deckt etwa Spracheinstellungen ab, personalization_storage etwa Videoempfehlungen und security_storage Authentifizierung und Betrugsprävention.
Diese beiden zählen also meist aus einem Grund: Jemand hat sie an einem Tag eingetragen. In Tag Manager kann ein Chat-Widget oder ein Empfehlungsskript unter Consent Settings eine zusätzliche Einwilligungsprüfung tragen. Googles Regel für diese Prüfung ist streng. Das Tag wird nur ausgelöst, wenn jeder Typ auf seiner Liste beim Auslösen erteilt ist.
Warum bleibt das Tag nach einer Zustimmung blockiert?
Weil das Akzeptieren des Banners und das Aktualisieren des Signals zwei getrennte Vorgänge sind. Bei einer Consent-Sanierung, die wir im August 2026 geprüft haben, setzte die Seite sechs Signale standardmäßig auf abgelehnt und ließ security_storage erteilt, was normal ist. Die Konfiguration der Consent-Plattform aktualisierte danach die Werbe- und Analysesignale von Google und sonst nichts. Ein Chat-Listener mit der Bedingung functionality_storage lief nie, auch nicht bei Besuchern, die akzeptiert hatten. Nichts meldete einen Fehler, denn ein blockiertes Tag ist genau das, was eine Consent-Einrichtung erzeugen soll.
Die Prüfung liest den Status in diesem Moment.
Welche Einrichtungen verursachen das?
- Die Aktualisierung nennt nur die Google-Signale. Das ist der Fall von oben und der erste, den Sie ausschließen sollten.
- Der Name ist in der Aktualisierung falsch geschrieben. In einer von Hand geschriebenen Aktualisierung erzeugt ein Tippfehler einen anderen Einwilligungstyp, und der echte bleibt auf seinem Standardwert.
- Das Banner hat keine passende Kategorie. Ohne funktionale oder Personalisierungsoption hat eine Plattform für dieses Signal nichts zu senden, es sei denn, sie ordnet ihm eine andere Kategorie zu.
- Der Besucher hat diese Kategorie nicht gewählt. Wer nur Analyse akzeptiert, sollte das Tag blockiert lassen. Dann funktioniert die Einrichtung.
- Der Trigger lief nur vor der Entscheidung. Wir haben im November 2026 den Laufzeitcode von Tag Manager gelesen: Eine fehlgeschlagene Prüfung beendet diesen Versuch, und nichts wiederholt ihn, wenn sich die Einwilligung ändert. Das Tag braucht einen Trigger, der nach der Aktualisierung läuft. Das behandelt der Beitrag zum Consent-Update-Event. Wenn es außerdem einmal pro Seite ausgelöst wird, lesen Sie zuerst den Hinweis zu blockierten Versuchen.
Prüfen Sie dabei auch den umgekehrten Fehler. Die Dokumentation der Vorlagen-API von Google behandelt einen nie gesetzten Einwilligungstyp als erteilt, und der Laufzeitcode wendet dieselbe Logik auf zusätzliche Einwilligungsprüfungen an. Lässt Ihr Standardbefehl diese beiden Signale aus, kann ein davon abhängiges Tag ausgelöst werden, bevor der Besucher überhaupt entschieden hat.
Wie finden Sie heraus, welcher Fall vorliegt?
Akzeptieren Sie in Tag Assistant alles
Öffnen Sie Ihre Website in Tag Assistant mit einem frischen Browserprofil und klicken Sie auf „Alle akzeptieren“. So scheidet die Entscheidung des Besuchers als Ursache aus.
Lesen Sie das Signal nach der Entscheidung
Wählen Sie unter Summary das letzte Consent-Ereignis aus und öffnen Sie den Tab Consent. Vergleichen Sie die Spalten für Standardwert und Aktualisierung bei dem Signal, das Ihr Tag verlangt. Zeigt der Tab es nicht an, führen Sie
google_tag_data.ics.entriesin der Konsole aus. Das ist ein internes Objekt und kann sich ändern, zeigt aber den Standardwert und die Aktualisierung, die Google für jeden Typ gespeichert hat.Benennen Sie die Ursache
Standardmäßig abgelehnt und ohne Aktualisierung nach „Alle akzeptieren“ bedeutet, dass Ihre Plattform dieses Signal nicht sendet. Eine Aktualisierung auf erteilt bedeutet, dass das Signal in Ordnung ist, gehen Sie also zum Tag. Gar kein Status bedeutet, dass das Tag seine Prüfung besteht, statt darauf zu warten.
Prüfen Sie das Tag und seinen Trigger
Öffnen Sie die Consent Settings des Tags und vergleichen Sie jeden erforderlichen Typ Zeichen für Zeichen mit der Schreibweise von Google. Ein falsch geschriebener Typ hat keinen Status, die Prüfung besteht also, obwohl sie das Tag zurückhalten sollte. Sehen Sie dann nach, wann es blockiert wurde. Ein Tag, das nur bei einem Seitenaufruf-Trigger vor der Entscheidung blockiert wurde, braucht einen Trigger, der nach dem Consent-Update läuft.
Beheben Sie es an der richtigen Stelle
Wird das Signal nie aktualisiert, ordnen Sie ihm die Banner-Kategorie in Ihrer Consent-Plattform oder in der Aktualisierung Ihres eigenen Codes zu. Kann Ihre Plattform es nicht senden, verlangen Sie ein Signal, das sie sendet und das zu dem passt, was der Besucher akzeptiert hat.
Testen Sie Zustimmung, Ablehnung und den erneuten Besuch
Wiederholen Sie die Prüfung auf drei Arten. Das Tag sollte nach „Alle akzeptieren“ ausgelöst werden, nach einer Ablehnung oder wenn nur andere Kategorien gewählt sind blockiert bleiben und beim erneuten Besuch derselben Person wieder ausgelöst werden.
Der Tag-Assistant-Leitfaden von Google erklärt den Tab Consent genauer. Wenn Sie noch entscheiden, worauf ein Skript warten soll, hilft die Einordnung von Skripten in Einwilligungskategorien.
Sollte eine Banner-Kategorie beide Signale steuern?
Das geht. Manche Plattformen senden beide aus einer einzigen funktionalen Kategorie, andere halten sie getrennt. Beides funktioniert, wenn der Text im Banner beschreibt, was die Tags tun. Entscheidend ist, dass hinter jedem Signal, das Ihr Container verlangt, eine Kategorie steht.
Velo hält beide getrennt. Bei aktiviertem Consent Mode sendet jede Entscheidung alle sieben Typen: Die Kategorie Funktional setzt functionality_storage, Personalisierung setzt personalization_storage, und security_storage bleibt erteilt. Eine Einstellung sollten Sie im Blick behalten: Wo Velo vor dem Speichern fragt, kann eine im Banner ausgeblendete Kategorie nicht erteilt werden, ihr Signal bleibt also auch nach „Alle akzeptieren“ abgelehnt. Prüfen Sie Ihren Container, bevor Sie eine Kategorie entfernen. Der Consent-Mode-Leitfaden beschreibt die Einrichtung.
Häufige Fragen
Was Leser zu diesem Thema fragen.
Warum wird mein Tag, das auf functionality_storage wartet, nie ausgelöst?
Eine häufige Ursache ist ein Signal, das abgelehnt beginnt und von Ihrer Consent-Plattform nie aktualisiert wird. Das Tag wird nur ausgelöst, wenn alle erforderlichen Typen beim Auslösen des Triggers erteilt sind, und bleibt deshalb auch nach einer Zustimmung blockiert. Akzeptieren Sie in Tag Assistant alles, öffnen Sie das letzte Consent-Ereignis und prüfen Sie, ob sich das Signal geändert hat.
Verwenden Google-Tags functionality_storage oder personalization_storage?
Die Consent-Mode-Übersicht von Google definiert beide, beschreibt aber nur, wie Tags auf ad_storage, analytics_storage, ad_user_data und ad_personalization reagieren. Die beiden Signale zählen, wenn ein Tag in Ihrem Container sie als erforderlichen Einwilligungstyp nennt.
Was passiert, wenn functionality_storage keinen Standardstatus hat?
Sie besteht. Die Vorlagen-Dokumentation von Google behandelt einen nie gesetzten Einwilligungstyp als erteilt, und der Laufzeitcode von Tag Manager, den wir im November 2026 gelesen haben, macht das bei zusätzlichen Einwilligungsprüfungen genauso. Ein Tag mit einem Signal ohne Status kann ausgelöst werden, bevor der Besucher entschieden hat.
Wird ein blockiertes Tag von selbst ausgelöst, sobald der Besucher akzeptiert?
Nein. Die Prüfung wird beim Auslösen des Triggers gelesen, und im Laufzeitcode von Tag Manager, den wir im November 2026 gelesen haben, wird ein blockiertes Tag nicht wiederholt, wenn sich die Einwilligung ändert. Es braucht einen Trigger, der nach dem Consent-Update läuft, etwa das Consent-Ereignis Ihrer Plattform.
Sollte functionality_storage standardmäßig erteilt sein?
Nur wenn die Speicherung für etwas, das der Besucher angefordert hat, unbedingt erforderlich ist. Nach den ePrivacy-Regeln der EU wartet jede andere Speicherung auf die Einwilligung, dort ist also ein Standardwert abgelehnt mit einer echten Aktualisierung die sichere Einrichtung. Das Vereinigte Königreich hat inzwischen eigene Ausnahmen, darunter eine für die Anpassung einer Website an die Präferenzen des Besuchers. Prüfen Sie für britische Besucher daher die Hinweise der ICO.
© 2026
