Brauchen Sie mit Server-side Tagging noch ein Cookie-Banner?

Alle Beiträge

Ja, auch mit Server-side Tagging brauchen Sie ein Cookie-Banner. Server-side Tagging ändert, wo Ihre Tags laufen: nicht mehr im Browser des Besuchers, sondern in einem Container auf einem Server, den Sie kontrollieren. Es ändert nicht, ob Sie die Daten überhaupt erheben dürfen. Diese Frage beantwortet die Einwilligung, und die Einwilligung holt das Banner ein.

Was Server-side Tagging tatsächlich verlegt

Die Verwirrung ist verständlich, denn Server-side Tagging verschiebt tatsächlich eine Menge. Statt eines Dutzends Anbieter-Skripte im Browser sendet die Seite eine einzige Anfrage an einen Container, der Ihnen gehört, und dieser Container spricht mit Google, Meta und allen anderen. Sie bekommen First-Party-Anfragen von Ihrer eigenen Domain, Cookies mit längerer Laufzeit und die Möglichkeit, Daten zu bereinigen oder zu verwerfen, bevor sie überhaupt hinausgehen.

Nichts davon berührt den Moment, in dem ein Besucher entscheidet, was er erlaubt. Diese Entscheidung fällt auf der Seite, bevor die serverseitige Technik überhaupt läuft. So sieht die Aufteilung aus.

Die Einwilligungsentscheidung hat den Browser nie verlassen

Ein Banner hat genau eine Aufgabe: den Besucher fragen, ob Sie nicht notwendige Cookies und Tracker verwenden dürfen, und die Antwort festhalten. Beim Server-side Tagging geht es darum, die Daten zu verarbeiten, die Sie erheben dürfen. Zum Fragen trägt es nichts bei.

Das Gesetz sieht es genauso. Ob Sie eine Einwilligung brauchen, hängt davon ab, was Sie erheben und in welchen Regionen Ihre Besucher sind, nicht davon, auf welchem Server Ihre Tags laufen. In der EU verlangt Artikel 5 Absatz 3 der ePrivacy-Richtlinie eine Einwilligung, bevor Informationen auf dem Gerät des Besuchers gespeichert oder von dort ausgelesen werden, sofern das nicht unbedingt erforderlich ist. Dieses Speichern und Auslesen passiert im Browser. Ein Besucher aus der EU oder dem Vereinigten Königreich bekommt weiterhin das Opt-in. Ein Besucher aus Kalifornien weiterhin das Opt-out. Verlegen Sie alle Tags in einen Container in Ihrer eigenen Cloud, und die Pflicht liegt genau dort, wo sie vorher lag.

Wohin das Signal gelangen muss

Diesen Teil lassen die Anleitungen der Anbieter aus. Sie sagen, die Consent-Plattform übermittle das Signal an Ihren Server, und hören dann auf, als ginge das automatisch. Das tut es nicht. Das Banner setzt den Consent-Mode-v2-Status im Browser, und dieser Status muss mit der Anfrage reisen, die der Browser an Ihren Container sendet. In einem Google-Setup fährt er als Parameter gcs mit. Ihr Container liest ihn aus und entscheidet, was jedes Tag darf.

Merken Sie sich die Richtung. Die Entscheidung wird auf der Seite erfasst und an den Server weitergeleitet. Der Server kann sie respektieren, um sie herum modellieren und das anreichern, was erlaubt ist. Was er nicht kann: eine Entscheidung erfinden, die nie getroffen wurde. Kein Banner heißt kein Signal, und ein Container, bei dem nichts ankommt, ist nicht deshalb konform, weil er First-Party ist. Er ist ein Tracker, der nie gefragt hat. Wenn Sie nicht sicher sind, welchen Modus Ihre Website überhaupt nutzt, erklären wir in welcher Consent Mode auf Ihrer Website tatsächlich läuft, wie Sie das herausfinden. Die Anbindung selbst Schritt für Schritt finden Sie in So übergeben Sie das Consent-Signal an einen Server-side-Tagging-Container.

Wo das unbemerkt schiefgeht

Weil serverseitige Anfragen von Ihrer eigenen Domain kommen, wirken sie vertrauenswürdiger als Browser-Anfragen. Genau deshalb übersieht man die Fehler hier so leicht.

Am häufigsten sehen wir einen GA4-Client im Server-Container, der seine Cookies selbst verwalten darf. In dieser Einstellung versieht er jede eingehende Anfrage mit einer First-Party-Kennung, auch die cookielosen Pings, die gerade deshalb gesendet wurden, weil ein Besucher abgelehnt hat. Diese abgelehnten Pings sind dann nicht mehr anonym und werden als echte Sitzungen gezählt. Wir haben das bei einem laufenden Consent-Umbau gefunden, nachdem der Unassigned-Traffic eines Kunden wochenlang ohne Erklärung gestiegen war. Wie das Ihre Berichte flutet, steht in einem eigenen Beitrag: Warum Ihr GA4-Traffic nach dem Einbau eines Cookie-Banners als Unassigned erscheint. Die Lösung war eine einzige Einstellung. Die Lehre daraus: Server-side Tagging hat Consent hier nicht sicherer gemacht. Es hat einen Verstoß schwerer erkennbar gemacht.

So prüfen Sie, ob Ihr Setup die Einwilligung respektiert

1. Prüfen Sie, ob das Banner weiterhin zuerst lädt

   Ob serverseitig oder nicht: Der Consent-Mode-Standard muss auf „denied“ stehen, bevor irgendein Google-Tag läuft, und zwar auf jeder Seite, auch der ersten eines Besuchs. Greift der Standard erst nach dem Tag, geht der erste Hit in einem Status hinaus, den niemand gewählt hat.

2. Ablehnen, dann die Anfrage beobachten

   Lehnen Sie in einem Inkognito-Fenster alles ab und öffnen Sie den Netzwerk-Tab. Suchen Sie die Anfrage an Ihren Server-Container. Der Parameter gcs benennt den Status, und G100 bedeutet, dass beide Speicherarten abgelehnt sind. Auf dieses Signal reagiert Ihr Server.

3. Prüfen Sie, ob der abgelehnte Ping anonym bleibt

   Suchen Sie in derselben abgelehnten Anfrage nach einer Client-ID. Ein abgelehnter Ping mit einer ID ist der Fehler mit dem serververwalteten Cookie, und er bläht Ihre Zahlen mit Traffic auf, den Sie eigentlich in Ruhe lassen sollten.

4. Prüfen Sie, ob die Werbe-Tags stillhalten

   Bei abgelehnter Einwilligung sollten die Werbe-Tags in Ihrem Container keine identifizierbaren Daten weitersenden. Feuern sie trotzdem, liest der Container die Anfrage zwar, macht aber nichts davon abhängig.

5. Als wiederkehrender Besucher testen

   Laden Sie die Website erneut mit einer gespeicherten Ablehnung. Sie wollen ein Setup, das die erste Entscheidung auch beim wiederholten Besuch respektiert, ohne sie stillschweigend zu überschreiben.

Was der Umstieg auf Server-side wirklich bringt

Nichts davon ist ein Grund, auf Server-side Tagging zu verzichten. Richtig umgesetzt, liefert es sauberere Daten und einen zentralen Ort, an dem die Entscheidung des Besuchers durchgesetzt wird. Wie viel Ihres Traffics hinter dem Banner liegt, hängt von Region, Zielgruppe und Banner-Design ab. Messen Sie es deshalb selbst: Lesen Sie die Zustimmungsrate in Ihrer CMP ab oder vergleichen Sie die GA4-Sitzungen mit den Anfragen, die Ihr Server oder CDN an denselben Tagen protokolliert hat.

Das muss man klar sagen, weil das Thema genau hier verschwimmt: Was Sie gewinnen, kommt aus einem saubereren Signal und, wo Googles Schwellenwerte erreicht sind, aus der Modellierung. Es kommt nie daher, dass Sie mehr erheben, als ein Besucher erlaubt hat. Server-side Tagging lohnt sich, weil es die Entscheidung besser respektiert, nicht weil es sie umgeht. Was nach einer Ablehnung tatsächlich übrig bleibt, beschreiben wir ausführlich in Was mit Ihren GA4-Daten passiert, wenn Nutzer Cookies ablehnen.

Kurz gesagt

Server-side Tagging verlegt Ihre Tags vom Browser des Besuchers auf einen Server, den Sie kontrollieren. Den Moment der Einwilligung verlegt es nicht, der bleibt auf der Seite. Und es nimmt Ihnen nicht die Pflicht zu fragen, die hängt weiter an Ihren Regionen und Ihren Daten. Sie brauchen das Banner also weiterhin. Was sich ändert: Ein gut angebundener Server gibt dem Banner einen saubereren Ort, an dem seine Entscheidung respektiert wird, und ein schlecht angebundener einen saubereren Ort, an dem sie ignoriert wird.

Velo erfasst die Entscheidung im Browser und sendet sie in der Form, die Google erwartet. So reagiert die Serverseite Ihres Stacks auf ein echtes Signal statt auf ein fehlendes. Wie das funktioniert, steht auf der Produktseite.

Neu beim Thema Server-side? Das Team hinter Velo hat im Blog von Amplio Data eine klare Antwort darauf geschrieben, was Server-side Tagging ist und ob Sie es wirklich brauchen.