Ein Cookie-Banner vor serverseitigem Tagging: was sich ändert und was nicht

Ein First-Party-Hostname ist eine technische Eigenschaft einer Anfrage. Er ist keine Erlaubnis. Wenn Sie gestern eine Einwilligung brauchten, um ein Analytics-Cookie zu setzen, brauchen Sie sie heute auch, und dass das Cookie jetzt von metrics.ihreseite.de gesetzt wird statt von google-analytics.com, spielt dabei keine Rolle. Die Frage der Aufsichtsbehörde lautet, was Sie erfassen und warum – nicht, welchen Server das Paket unterwegs besucht hat.

Was sich ändert, ist, wohin eine blockierte Anfrage geht. Werbeblocker und Datenschutzfunktionen der Browser blockieren nach Hostname und URL-Muster, und sie blockieren googletagmanager.com. Ihre eigene Domain blockieren sie nicht. Ein Besucher, der eingewilligt hat und von einer Filterliste stillschweigend verworfen worden wäre, wird jetzt gezählt. Das ist der gesamte Nutzen – und er ist nur ein Nutzen für Besucher, die eingewilligt haben.

Googles Tags lesen einen Einwilligungsstatus mit einer Handvoll benannter Berechtigungen – analytics_storage, ad_storage, ad_user_data, ad_personalization – und passen an, was sie senden. Bevor der Besucher entscheidet, pusht ein Consent-Manager einen Standard von denied; wenn er wählt, pusht er ein Update. Im Status denied feuert das Google-Tag trotzdem, sendet aber einen cookielosen Ping: keine Client-ID, kein Cookie, ein Signal, dass eine Seite gesehen wurde, und mehr nicht. Sobald analytics_storage auf granted steht, sendet es den vollen Treffer. Der Server-Container empfängt, was gesendet wurde, und die Einwilligungssignale reisen mit dem Treffer mit – das serverseitige GA4-Tag verhält sich also genauso.

Der Consent-Manager muss vor dem Google-Tag laden, damit sein Standard gesetzt ist, wenn das Tag zum ersten Mal auswertet. Die meisten Consent-Manager bieten dafür einen wait_for_update-Wert – ein paar hundert Millisekunden, die das Tag auf einen Einwilligungsstatus wartet, bevor es denied annimmt.

Die Entitäten, die SignalHost in Ihrem Container anlegt, tragen keine Einwilligungsbedingungen. Das ist Absicht. Googles eigene Tags respektieren den Consent Mode; eine von Hand ergänzte Einwilligungsprüfung am Google-Tag, ohne eine an den GA4-Ereignis-Tags darunter, ist der erste der beiden Fehler unten.

Das Google-Tag ist das, was Messungen durch den Server-Container leitet. Ein GA4-Ereignis-Tag – etwa ein Purchase-Tag – kann eigenständig senden. Wartet das Google-Tag auf die Einwilligung und die Ereignis-Tags nicht, feuern die Ereignis-Tags vor der Einwilligung und senden direkt an Google – von einer Seite, deren Banner noch offen ist. Die Container-Seite zeigt nichts Auffälliges, weil die Treffer nie durch den Container gelaufen sind.

Entweder Sie gaten von Hand gar nichts und lassen den Consent Mode arbeiten, oder Sie gaten jedes Tag, das senden kann. Einen konsistenten Mittelweg gibt es nicht.

Manche Consent-Manager arbeiten, indem sie Skripte bis zur Einwilligung blockieren – sie fangen Script-Tags anhand der URL ab und halten sie zurück. Ihre Listen kennen googletagmanager.com. Sie kennen exxz2gdaz1jz.ihreseite.de nicht, weil das keine Liste könnte: Hostname und Dateiname des Loaders sind für Ihren Container einzigartig. Im Blockiermodus wird der Loader also möglicherweise bedingungslos durchgelassen – und wenn Sie sich auf das Blockieren statt auf den Consent Mode verlassen, ist das ein Tag, das vor der Einwilligung feuert.

Zwei Wege. Tragen Sie die URL des Loaders von Hand in die Blockierregeln des Consent-Managers ein, in der Kategorie, zu der Ihre Analytics gehört. Oder – besser, weil es auch den cookielosen Ping korrekt behandelt – verlassen Sie sich für Googles Tags auf den Consent Mode und nutzen das Blockieren nur für Skripte, die ihn nicht unterstützen. Unsere eigene Website betreibt einen Consent-Manager im Auto-Blocking-Modus mit Consent Mode daneben; das Google-Tag steht hinter dem Skript des Consent-Managers, und ein Test im Repository schlägt fehl, wenn jemand die Reihenfolge vertauscht.

Der Einwilligungsstatus kommt in jedem Treffer beim Server-Container an, und das serverseitige GA4-Tag liest ihn wie das browserseitige. Nichts auf unserer Seite erteilt oder erweitert eine Einwilligung; ein cookieloser Ping bleibt ein cookieloser Ping.

Wenn Sie ein Meta- oder TikTok-Ziel verbinden, speisen dieselben Treffer diese Ziele. Ob die verweigerte Marketing-Einwilligung eines Besuchers diese Weiterleitungen stoppen soll, ist eine Entscheidung, die Ihr Consent-Manager ausdrückt – über die Kategorie, in der der Loader sitzt, und darüber, ob ad_storage des Consent Mode in Ihrer Einrichtung respektiert wird. Prüfen Sie es so, wie Sie hier alles prüfen sollten: Website mit unbeantwortetem Banner öffnen, Netzwerk-Tab beobachten, sehen, was rausgeht.

• Das Skript des Consent-Managers steht auf der Seite über dem Google-Tag.
• Ein Standard-Einwilligungsstatus denied wird gepusht, bevor das Tag lädt, mit einem wait_for_update.
• Kein Tag im Container hat eine von Hand ergänzte Einwilligungsbedingung – oder jedes Tag, das senden kann, hat eine.
• Bei unbeantwortetem Banner zeigt der Netzwerk-Tab einen cookielosen Ping (gcs=G100 in der Anfrage) und keinen vollen Treffer.
• Nach dem Akzeptieren zeigt dieselbe Seite einen vollen Treffer, und die Container-Seite zählt ihn.
• Wenn der Consent-Manager nach URL blockiert, steht die URL des Loaders in seinen Regeln.