Consent Mode v2 in PrestaShop einrichten: die Signale in der richtigen Reihenfolge

Ein Cookie-Banner und Consent Mode v2 sind zwei verschiedene Dinge

Ein Cookie-Banner fragt einen Besucher um Erlaubnis. Consent Mode v2 ist der Weg, auf dem diese Erlaubnis an Google weitergegeben wird, bevor ein Tag wie Google Analytics oder Google Ads auch nur einen einzigen Datenpunkt erhält. Das sind zwei unterschiedliche Ebenen: Ein Shop kann ein DSGVO-konformes Banner haben und trotzdem ein falsch eingerichtetes Consent Mode, weil das Banner eine Oberfläche für den Besucher ist, während Consent Mode ein Protokoll zwischen der Website und den Google-Tags ist, mit genau benannten Signalen und einer genauen Reihenfolge, in der sie gesetzt werden müssen.

Seit Version 2, verpflichtend für alle, die in Europa Google-Tags gegenüber einem der DSGVO unterliegenden Publikum einsetzen, sind es nicht mehr zwei, sondern sechs Signale: ad_storage und analytics_storage gab es schon in v1, dazu kamen ad_user_data (Erlaubnis, personenbezogene Daten für Werbung an Google zu senden) und ad_personalization (Erlaubnis, diese Daten für personalisierte Werbung zu nutzen). In der Praxis behandeln fast alle echten Umsetzungen zusätzlich functionality_storage und personalization_storage für die Präferenzen der Website selbst. Ein siebtes Signal, security_storage, bleibt immer erlaubt, da es technische Sicherheits-Cookies betrifft, kein Tracking.

Die Reihenfolge zählt mehr als der Inhalt: der Default muss vor dem Tag stehen

Der häufigste Fehler liegt nicht in den gewählten Werten, sondern in der Reihenfolge. Ein Google-Tag (GTM, gtag.js), das lädt, bevor die Website einen Consent-Default erklärt hat, verhält sich so, als gäbe es gar kein Consent-Framework, also im für Google günstigsten Fall. Eine sauber gebaute Consent-Mode-v2-Umsetzung folgt immer demselben Schema:

• Sobald das Dokument zu laden beginnt, vor jedem Drittanbieter-Skript, wird ein abgelehnter Default für alle Tracking-Signale gesetzt (denied bei Marketing und Statistik, granted nur bei security_storage), mit einem kurzen Zeitfenster (in unserer eigenen Umsetzung 500 Millisekunden), das einer bereits gespeicherten Entscheidung Zeit gibt, gelesen zu werden, bevor ein Tag mit den falschen Werten startet.
• Hat der Besucher bei einem früheren Besuch bereits eine Wahl getroffen, wird diese aus dem Consent-Cookie gelesen und sofort als Update-Befehl an Google weitergegeben, ebenfalls bevor GTM oder gtag.js tatsächlich von Googles Servern angefordert werden.
• Erst danach, mit bereits erklärtem Consent-Kontext, werden GTM, ein direktes Google-Analytics-4-Tag (falls nicht über GTM eingebunden) und ein eventuelles Drittanbieter-Pixel wie das von Meta geladen. Auch das Pixel braucht dabei einen eigenen, separaten Consent-Aufruf, nicht nur ein einfaches "wenn das Cookie ja sagt, lade das Skript".

Den Default an der richtigen Stelle im Code zu setzen, ist eine Sache von drei Zeilen JavaScript. Ihn an der falschen Stelle zu setzen, etwa im selben Block, der GTM lädt, statt davor, macht den gesamten Mechanismus wirkungslos: Google sieht das Tag trotzdem vor dem Signal ankommen.

Das Banner allein blockiert nichts: es braucht eine generische Sperre

Eine praktische Lücke, die Consent Mode v2 allein nicht schließt, ist, dass es nur Googles eigene Tags betrifft, nicht die anderen Drittanbieter-Skripte, die ein Theme oder ein anderes Modul auf der Seite platziert haben können (eine eingebettete Karte, ein Bewertungs-Widget, ein Video). Eine ernsthafte Umsetzung fügt eine unabhängige Ebene hinzu, die den DOM beobachtet, während sich die Seite aufbaut, ein Skript oder Iframe anhand einer Liste von Domain-Mustern erkennt (zum Beispiel google-analytics.com, facebook.net, doubleclick.net oder die Domain eines Video-Dienstes), und es, falls die zugehörige Kategorie noch nicht akzeptiert wurde, durch einen inaktiven Platzhalter ersetzt, bevor es auch nur eine einzige Netzwerkanfrage stellen kann. Erst wenn der Besucher diese Kategorie akzeptiert, wird das echte Skript wieder eingesetzt. Ohne diese Ebene deckt ein abgelehnter Default nur die Tags ab, die die Website selbst dafür geschrieben hat, nicht die, die in Drittanbieter-Modulen stecken und den eigenen Consent Mode schlicht ignorieren.

Ein echter Fall: technisch korrekter Default, ein Banner, das niemand verstand

In unserem eigenen Consent-Modul haben wir am 14. September 2026 einen lehrreichen Fehler gefunden: Der Consent-Mode-Mechanismus selbst war korrekt, der abgelehnte Default startete an der richtigen Stelle, und trotzdem erschien der Banner-Text (Titel, Inhalt, die drei Schaltflächen, die Kategorienamen) auf Englisch für jeden, der einen Shop auf Französisch, Spanisch oder Deutsch besuchte, während Italienisch und Englisch korrekt waren. Die Ursache war keine fehlende Übersetzung im Sprachkatalog von PrestaShop: Der Banner-Text stand direkt im Code des Moduls, in einem Array, das nur zwei Sprachen vorsah, und für jede andere Sprache fiel der Code stillschweigend auf Englisch zurück. Wir haben es korrigiert, indem wir die drei fehlenden Sprachblöcke ergänzt haben (Französisch, Spanisch, Deutsch, je 17 Zeichenketten, mit echten Umlauten statt Ersatzschreibweisen) und Version 1.0.9 veröffentlicht.

Das ist nicht nur kosmetisch. Eine Einwilligung, die mit einem für den Besucher unverständlichen Text eingeholt wird, ist eine schwache Einwilligung: Die DSGVO selbst verlangt, dass der Hinweis für die lesende Person verständlich ist, nicht nur technisch auf der Seite vorhanden. Ein auf Code-Ebene fehlerfreies Consent Mode nützt wenig, wenn die Person vor dem Banner eine Sprache liest, die sie nicht spricht.

Eine praktische Checkliste zum Überprüfen der eigenen Einrichtung

• Öffnen Sie den Seitenquelltext der Startseite (nicht die Entwicklertools, sondern "Seitenquelltext anzeigen") und prüfen Sie, ob gtag("consent","default",...) vor jedem Google-Tag-Manager- oder gtag.js-Tag im Dokument steht, nicht danach.
• Prüfen Sie, ob alle sechs Signale im Default vorhanden sind, nicht nur ad_storage und analytics_storage aus Consent Mode v1: Fehlende ad_user_data oder ad_personalization sind der häufigste Fehler bei Einrichtungen, die nur dem Namen nach "aktualisiert" wurden.
• Prüfen Sie mit den Netzwerk-Tools des Browsers, ob ein Skript wie Google Analytics tatsächlich erst nach der Einwilligung startet: Ein abgelehnter Default muss sich in null Netzwerkanfragen an diese Domain niederschlagen, nicht nur in einem erklärten und ignorierten Signal.
• Wechseln Sie die Sprache des Shops und schauen Sie sich das Banner erneut an: Ein nur halb übersetzter Text ist ein ebenso häufiger wie unsichtbarer Fehler, weil er fast immer nur in der Sprache geprüft wird, in der das Team selbst arbeitet.

Kurz gesagt

Consent Mode v2 ist keine Checkbox im Einstellungsbereich eines Cookie-Moduls: Es ist eine genaue Abfolge von Signalen, bei der die Reihenfolge ebenso zählt wie der Inhalt, und eine Blockierungsebene, die auch Skripte abdecken muss, die die Website selbst nie geschrieben hat. Eine technisch korrekte Umsetzung kann trotzdem ihr Ziel verfehlen, wenn der Text zur Einwilligung die lesende Person nie wirklich in ihrer Sprache erreicht. Für PrestaShop gibt es dafür eigene Module, darunter eines kostenlos in unserem eigenen Katalog (cll_consent), aber die oben beschriebene Reihenfolge gilt unabhängig davon, welches Modul sie am Ende umsetzt.

Installations- und Konfigurationsanleitung

Cookie-Banner und Google Consent Mode v2Kostenloses Modul: jetzt herunterladen und installieren. DSGVO-Cookie-Banner mit granularen Kategorien…Produkt ansehen

Dieser Beitrag erklärt, wie Consent Mode v2 funktioniert. Die Schritt-für-Schritt-Konfiguration finden Sie in der Anleitung Google Consent Mode v2 auf PrestaShop einrichten.