Manchmal erscheint ein Cookie (typisch: _fbp vom Meta/Facebook Pixel) schon vor der Einwilligung, obwohl der AdSimple Consent Manager korrekt eingebunden ist. In den meisten dieser Fälle liegt kein Fehler am Consent Manager vor: Das Cookie wird nicht im Browser gesetzt, sondern von Ihrem eigenen Server.

Dieser Artikel erklärt den Unterschied und zeigt, wie Sie ihn in zwei Minuten selbst feststellen und was jeweils zu tun ist.

Was der Consent Manager blockiert

Der AdSimple Consent Manager arbeitet mit einer Content Security Policy (CSP). Diese wirkt wie eine Freigabeliste: Drittanbieter, die beim Website-Scan erkannt und einer Einwilligungs-Kategorie zugeordnet wurden, werden vor der Einwilligung blockiert und erst nach Zustimmung geladen.

Das gilt für:

  • externe Scripts, iFrames, Schriften, Bilder und Videos von Drittanbietern
  • und damit auch die Cookies, die diese externen Ressourcen setzen würden

Beispiel Meta Pixel: connect.facebook.net/en_US/fbevents.js wird vor der Einwilligung blockiert. Deshalb werden vor der Einwilligung keine Events aus dem Browser an Meta gesendet. Serverseitig gesendete Events (Conversions API) sind davon nicht erfasst – siehe den CAPI-Abschnitt am Ende dieses Artikels.

Damit das funktioniert, muss der Consent-Manager-Code als erstes Script direkt nach dem öffnenden <head>-Tag stehen, ohne async/defer, und vom Caching ausgenommen sein.

Was der Consent Manager nicht blockieren kann

Cookies, die Ihr eigener Server direkt in der Server-Antwort setzt (HTTP-Header Set-Cookie), entstehen, bevor überhaupt JavaScript ausgeführt wird.

Solche Cookies kann kein browserseitiges Consent-Tool verhindern – weder eine CSP noch ein Script-Blocker. Zu diesem Zeitpunkt hat der Browser noch keinen Code ausgeführt, der eingreifen könnte.

Typische Quelle sind WordPress-Plugins, die serverseitig arbeiten – etwa für die Conversions API (CAPI) oder Server-Side-Tracking. Das Plugin „Official Facebook Pixel“ setzt beispielsweise das Cookie _fbp serverseitig, damit serverseitig gemeldete Events einem Besucher zugeordnet werden können.

Das erklärt ein auf den ersten Blick widersprüchliches Bild:

Die Browser-Events werden erst nach der Einwilligung gesendet (der Consent Manager blockiert korrekt) – das Pixel-Cookie ist aber trotzdem schon vorher da (weil es vom eigenen Server kommt).

So stellen Sie in zwei Minuten fest, welcher Fall vorliegt

  1. Öffnen Sie Ihre Website in einem privaten Fenster und löschen Sie alle Cookies für Ihre Domain (DevTools → Application → Cookies).
  2. Öffnen Sie den Tab Network/Netzwerkanalyse und laden Sie die Seite neu, ohne dem Banner zuzustimmen.
  3. Klicken Sie auf den ersten Eintrag (das HTML-Dokument Ihrer Seite) und sehen Sie sich die Response Headers an.

Ergebnis A – serverseitig: Dort steht bereits Set-Cookie: _fbp=… → Das Cookie kommt von Ihrem Server. Der Consent Manager kann es nicht verhindern. Weiter mit dem nächsten Abschnitt.

Ergebnis B – clientseitig: Dort steht kein Set-Cookie, das Cookie erscheint aber später → Prüfen Sie zunächst, ob es in einer anderen Server-Antwort gesetzt wird: Filtern Sie dazu in Chrome im Network-Tab nach has-response-header:Set-Cookie. Taucht das Cookie dort ebenfalls nirgends auf, wird es per JavaScript gesetzt. Prüfen Sie dann, ob der Consent-Manager-Code wirklich als erstes Script im <head> steht und nicht durch ein Caching- oder Optimierungs-Plugin (z. B. WP Rocket „JavaScript verzögern“/„verschieben“) verschoben wird.

Ergänzend können Sie im Network-Tab prüfen, ob die externe Ressource blockiert wird: Bei fbevents.js sollte der Eintrag vor der Einwilligung als blockiert markiert sein (in Chrome: Status (blocked:csp)) und keine Übertragungsgröße zeigen.

Lösung bei serverseitig gesetzten Cookies

Hier hilft nur, an der Quelle anzusetzen – also dort, wo das Cookie entsteht:

  1. Das Plugin deaktivieren bzw. entfernen, das den Dienst serverseitig einbindet (im Beispiel: „Official Facebook Pixel“).
  2. Den Dienst stattdessen über den Google Tag Manager einbinden.
  3. Den Tag mit einem einwilligungsabhängigen Trigger versehen, sodass er erst bei erteilter Marketing-Einwilligung auslöst.

Damit läuft vor der Einwilligung kein Pixel-Code und es entsteht kein Pixel-Cookie – weder serverseitig noch im Browser. Nach der Einwilligung funktioniert das Tracking im Browser wie gewohnt.

Hinweis für Umsteiger von anderen Cookie-Plugins

Reine WordPress-Consent-Plugins laufen selbst in PHP mit und können deshalb die Ausgabe anderer Plugins unterdrücken – auch serverseitig gesetzte Cookies.

Der AdSimple Consent Manager arbeitet browserseitig über die CSP. Das hat den Vorteil, dass er unabhängig vom eingesetzten System funktioniert (WordPress, Shop, individuelle Website) und beim Scan erkannte Drittanbieter blockiert. Serverseitig gesetzte Cookies kann er systembedingt nicht verhindern – diese müssen an der Quelle abgestellt werden.

Hinweis zur Conversions API (CAPI)

Die Conversions API sendet Events serverseitig an Meta und ist damit unabhängig von Browser-Blockern. Wichtig: Die CAPI ersetzt die Einwilligung nicht. Serverseitige Events, die personenbezogene Daten für Marketing verarbeiten, benötigen ebenfalls die Marketing-Einwilligung des Besuchers. Die CAPI verbessert die Datenqualität, ist aber kein Weg, die Einwilligung zu umgehen – der Einwilligungsstatus muss auch an die CAPI übergeben werden.

Über den Google Tag Manager (mit Server-Container) lässt sich die CAPI so anbinden, dass der Einwilligungsstatus korrekt berücksichtigt wird.