Brauchen Sie für Google Consent Mode v2 eine kostenpflichtige CMP?

💡 Kurzfassung (TL;DR):

• Google Consent Mode v2 macht für jede Website weder eine kostenpflichtige noch eine von Google zertifizierte CMP zwingend. Eine gewöhnliche Website mit GA4, Google Tag Manager und Google Ads kann einen kommerziellen Dienst, ein Open-Source-Werkzeug oder eine eigene Umsetzung einsetzen, sofern Einwilligungssignale und regionale Vorgaben korrekt umgesetzt sind.
• Für Publisher gilt etwas anderes. Bei AdSense, Ad Manager oder AdMob im EWR, Vereinigten Königreich und der Schweiz können eine Google-zertifizierte CMP und IAB-TCF-Anforderungen in die Entscheidung fallen. Diese Regel lässt sich nicht pauschal auf ein übliches Analyse- und Conversion-Tracking übertragen.
• Das Abo bezahlt selten nur das Banner. Es bezahlt Scans, Klassifizierung, regionales Verhalten, Einwilligungsnachweise, Pflege von Richtlinien, Verwaltung mehrerer Domains und dafür, dass ein Teil der operativen Verantwortung beim Anbieter liegt.
• Meine bewusst kurze Auswahl: Cookiebot und CookieYes für gehosteten Betrieb, iubenda wenn Richtlinienwerkzeuge wichtig sind, Consenti als umfassenderer selbst gehosteter Ansatz sowie Orest Bidas CookieConsent für Entwicklerinnen und Entwickler, die eine kleine Bibliothek möchten und den übrigen Betrieb selbst verantworten.

In dem Unternehmen, in dem ich arbeite, verlagern wir einen Bestand von WordPress-Websites schrittweise auf einen Next.js-Stack. Die bisherigen Seiten nutzen Complianz. Innerhalb von WordPress ist das eine recht komfortable Lösung: Scanner, Banner, Einwilligungsnachweise und Integrationen befinden sich in derselben Verwaltungsumgebung wie die Website.

Sobald das Frontend WordPress verlässt, bleibt dieser Komfort nicht erhalten.

Wir müssen ihn durch einen gehosteten Dienst ersetzen, etwas selbst betreiben oder eine kleinere Einwilligungsschicht in den neuen Stack bauen. Da diese Websites viele Länder bedienen, geht es nicht nur darum, ob ein Banner gtag('consent', ...) aufrufen kann. Wir müssen auch entscheiden, wer regionale Vorgaben pflegt, nachweist, was ein Besucher gewählt hat, neue von Marketingteams hinzugefügte Cookies entdeckt und Veränderungen im Werbeökosystem verfolgt.

In diesem Kontext stieß ich auf Consenti. Das Angebot sprach sofort den Entwickler in mir an: Open Source, selbst hostbar, für moderne Anwendungen gedacht und einem vollständigen Einwilligungssystem deutlich näher als die übliche Bannerbibliothek.

Es stellte aber auch eine unbequeme Frage erneut. Wenn das sichtbare Produkt aus einem Hinweis, einem Einstellungsdialog und vier Google-Einwilligungssignalen besteht, warum sollte ein Unternehmen dann monatlich und dauerhaft 10 €, 30 € oder wesentlich mehr pro Website zahlen?

Ich begann die Recherche mit der Erwartung, es gehe vor allem um die Umsetzung. Am Ende ging es darum, wo wir die fortlaufende Verantwortung ansiedeln wollen.

Dieser Beitrag ist eine technische und produktbezogene Einschätzung des Marktstands vom 18. August 2026. Eine CMP unterstützt ein Datenschutzprogramm; sie macht eine Website nicht von selbst rechtskonform. Dieser Beitrag ist keine Rechtsberatung.

Zunächst: Consent Mode ist keine CMP

Google Consent Mode ist ein Protokoll zwischen der Einwilligungsoberfläche einer Website und Google-Tags. Es teilt diesen Tags mit, welche Arten von Speicherung und Werbenutzung erlaubt sind. Eine CMP kann diese Entscheidungen erzeugen. Consent Mode zeichnet jedoch weder das Banner noch entscheidet er, ob Formulierungen und Wahlmöglichkeiten dem Recht genügen.

Version 2 dreht sich um vier Signale:

Entscheidend ist die Reihenfolge, nicht das Design des Banners:

1. Die Seite startet.
2. Ein Standardzustand für die Einwilligung wird vor Messbefehlen und laufenden Tags festgelegt.
3. Google-Tags werden entsprechend diesem Zustand initialisiert.
4. Der Besucher trifft oder ändert eine Entscheidung.
5. Die Website übermittelt eine Aktualisierung der Einwilligung.
6. Tags ändern ihr Verhalten für den Rest der Seite und für folgende Navigationen.

Googles Implementierungsleitfaden schreibt ausdrücklich vor, den Standard vor jedem Messbefehl zu setzen. Genau hier scheitern viele selbst gebaute Banner. Sie senden irgendwann die richtige Antwort, aber erst nachdem GA4 oder ein Werbe-Tag bereits mit dem falschen Standard ausgeführt wurde.

Außerdem werden zwei Betriebsarten häufig verwechselt.

Beim Basic Consent Mode bleiben Google-Tags gesperrt, bis der Besucher mit der Einwilligungsoberfläche interagiert. Wird die Einwilligung verweigert, laden diese Tags nicht. Dieses Modell ist leichter nachzuvollziehen, weil „verweigert“ bedeutet, dass der gesperrte Tag keine Anfrage sendet. Google stehen dann aber weniger Daten für Modellierung zur Verfügung.

Beim Advanced Consent Mode laden Google-Tags mit dem Standardzustand „verweigert“. Solange Speicher nicht verfügbar ist, können sie einwilligungsbewusste, cookielose Pings senden und ihr Verhalten nach einer Aktualisierung ändern. Google erklärt, dass dies eine umfangreichere werbetreiberspezifische Modellierung als der Basic Mode ermöglichen kann. Das bedeutet nicht, dass Advanced Consent Mode in jedem Land automatisch die rechtlich richtige Wahl ist. Es beschreibt ein anderes technisches Verhalten bei verweigerter Einwilligung. Google dokumentiert diesen Unterschied direkt; Rechtsgrundlage und Oberfläche müssen weiterhin zu den Regionen passen, in denen die Website betrieben wird.

Dieser Unterschied ist beim Produktvergleich wichtig. „Unterstützt Google Consent Mode v2“ kann alles bedeuten – vom korrekten Setzen aller vier Signale bis zu einem kurzen Callback-Beispiel, das der Kunde selbst integrieren und prüfen muss.

Die Verwirrung um die Zertifizierung

Die nützlichste Erkenntnis dieser Recherche war zugleich die einfachste: Google verlangt nicht von jedem Werbetreibenden, der Consent Mode nutzt, den Kauf einer Google-zertifizierten CMP.

Googles eigene Seite zu CMP-Anforderungen unterscheidet Werbetreibende von Publishern. Für eine gewöhnliche Website, die GA4, Google Tag Manager und Google Ads für Analysen, Conversions oder Remarketing nutzt, kann eine eigene CMP oder eine CMP ohne Partnerstatus Consent-Mode-Signale übergeben. Google erklärt, dass Werbetreibende keine CMP aus seinem Partnerprogramm verwenden müssen.

Der Publisher-Fall unterscheidet sich wesentlich. Verwendet eine Website AdSense, Ad Manager oder AdMob, um im EWR, Vereinigten Königreich oder der Schweiz personalisierte Anzeigen auszuliefern, können Googles Publisher-Regeln eine Google-zertifizierte CMP mit Integration in das IAB Transparency and Consent Framework (TCF) verlangen. Eine nicht zertifizierte Umsetzung kann dazu führen, dass der Datenverkehr auf nicht personalisierte oder eingeschränkte Anzeigen begrenzt wird, statt den vorgesehenen Monetarisierungsweg zu erhalten.

Die erste Frage lautet daher nicht „Unterstützt dieses Werkzeug Consent Mode v2?“, sondern:

Sind wir ein Werbetreibender, der die eigene Website misst, oder ein Publisher, der über Googles Publisher-Produkte Werbeinventar verkauft?

Diese eine Antwort räumt viel schlechte Beratung aus dem Weg. Eine kleine SaaS-Landingpage mit GA4 und Conversion-Tracking benötigt nicht automatisch dieselbe Einwilligungsinfrastruktur wie ein Medienangebot, das programmatische Werbung in ganz Europa ausliefert.

TCF ist ebenfalls kein allgemeines Synonym für ein Cookie-Banner. Der aktuelle Standard IAB Europe TCF v2.3 koordiniert Zwecke, Anbieter und Einwilligungssignale in der Lieferkette für Werbung. Nur eine registrierte CMP kann nach den TCF-Richtlinien einen gültigen Framework-Einwilligungsstring schreiben. IAB Europe hatte bereits im Juli 2026 den Zeitplan für den Übergang zu v2.4 angekündigt – eine weitere Erinnerung daran, dass es sich um gepflegte Infrastruktur und nicht um eine einmalige Bannerintegration handelt. Diese Fähigkeit ist für Publisher wertvoll und manchmal verpflichtend, für eine von Entwicklern betreute Website mit drei bekannten Tags aber unnötiger Ballast.

Eine Zertifizierung darf auch nicht mit einer Rechtsgarantie verwechselt werden. Google stellt ausdrücklich klar, dass seine Zertifizierung die Einhaltung von Googles CMP-Anforderungen prüft, nicht die vollständige Einhaltung des Datenschutzrechts. Ein zertifiziertes Produkt kann falsch konfiguriert sein; ein ansprechendes Banner kann ungültige Standardwerte verwenden; eine Datenschutzerklärung kann etwas beschreiben, das der Code nicht tut.

„Es ist doch nur ein Banner und vier Aufrufe“

Für die kleinste Website trifft dieser Einwand teilweise zu.

Wenn ich jedes Script kontrolliere, die bedienten Länder kenne, Tags vor der Einwilligung blockieren, die Wahl eines Besuchers speichern, eine Widerrufsmöglichkeit anbieten und jede Bereitstellung testen kann, muss ich nicht für ein Dashboard zahlen, das lediglich vier JavaScript-Werte ausführt. Eine ausgereifte Bibliothek kann den Großteil der Oberflächenarbeit abnehmen. Ein kleiner Backend-Endpunkt kann Einwilligungen protokollieren, falls Nachweise erforderlich sind. Das kann eine völlig vernünftige technische Entscheidung sein.

Doch das ist nicht das gesamte Produkt, das eine kommerzielle CMP verkauft. Die wiederkehrende Gebühr bezahlt meist eine Kombination aus:

• geplanten Crawls und dem Auffinden neu eingeführter Cookies;
• einer gepflegten Datenbank, die das Gefundene zu klassifizieren versucht;
• regionalen Standardwerten und Geolokalisierung;
• Einwilligungs- und Richtliniennachweisen, die bei einer Prüfung abrufbar sind;
• IAB-Anbieterlisten und TCF-Integration;
• übersetzten Oberflächen und Richtlinienmaterial;
• einer Verwaltungsoberfläche für mehrere Websites und Domains;
• einer Oberfläche, die Kolleginnen und Kollegen aus Marketing oder Recht ohne Bereitstellung bedienen können;
• fortlaufenden Anpassungen, wenn sich Browser, Google-Produkte oder regulatorische Erwartungen ändern.

Keine dieser Funktionen beweist Rechtskonformität. Einige sind auch deutlich weniger zuverlässig, als die Verkaufsseite nahelegt: Ein Scanner kann nicht jeden First-Party-Speicherschlüssel verstehen, und automatische Kategorisierung braucht weiterhin menschliche Prüfung. Dennoch decken sie echte Arbeit ab. Das Abo ist ein Tausch von Betriebskosten: den Anbieter bezahlen oder Ingenieurteams und Datenschutzverantwortlichen die fortlaufende Arbeit zuweisen.

Das ist vertrautes Terrain beim Abschied von WordPress. Wie ich in meinem Beitrag über den Wechsel von WordPress zu einem Git-basierten Nuxt-Stack geschrieben habe, bedeutet das Entfernen der Wartungslast der alten Plattform auch, die Bequemlichkeiten ihres Plugin-Ökosystems neu aufzubauen. Complianz ist eine dieser Bequemlichkeiten. Sein Jahrespreis ist kein sinnvoller Vergleichswert, wenn die Alternative einen internen Serviceverantwortlichen, Monitoring, Release-Arbeit und Unterstützung für jede regionale Ausnahme erfordert.

Wie ich den Markt eingegrenzt habe

Ich habe mehr Produkte betrachtet, als in eine nützliche Abschlusstabelle gehören.

Complianz bleibt eine starke WordPress-Referenz, ist jedoch grundsätzlich ein WordPress-Plugin. Es zeigte, woran wir gewöhnt waren – Scans, Momentaufnahmen als Einwilligungsnachweis, regionales Verhalten –, ist aber nicht die natürliche Steuerungsebene für eine Gruppe von Next.js-Anwendungen.

OneTrust repräsentiert das Unternehmensende des Spektrums: breite Governance, viele Rechtsräume und ein vertriebsorientiertes Produkt ohne brauchbaren öffentlichen Preis. Für eine Compliance-Organisation kann es der richtige Maßstab sein. Es ist aber keine aussagekräftige Antwort auf die Entwicklerfrage, ob eine kleine Einwilligungsschicht ein weiteres Abo braucht.

Termly ist eine glaubwürdige gehostete Alternative mit dokumentiertem Installationsweg für Next.js. Klaro bleibt eine interessante selbst hostbare Bibliothek; aufgrund seiner öffentlichen Release-Kadenz und der manuellen Consent-Mode-Integration war Orest Bidas CookieConsent für diesen Vergleich jedoch der stärkere Bibliotheksvertreter. Silktide Consent Manager v2 bietet für ein Open-Source-Paket ungewöhnlich gute Consent-Mode-Unterstützung, überschneidet sich als neue Hauptversion aber mit derselben Reifefrage, die Consenti ohnehin aufwirft.

Damit blieben fünf Optionen, die wirklich unterschiedliche Einkäufe darstellen statt fünf fast gleicher Banner.

Die Auswahl, Stand August 2026

Die folgenden Preise sind öffentliche Listenpreise, geprüft am 18. August 2026, ohne Steuern und Unternehmensverhandlungen. Seitenaufruf- und Seitenlimits ändern sich häufig; prüfen Sie sie vor einem Kauf erneut.

Die aktuellen Preislisten von Cookiebot, CookieYes und iubenda sind bessere Belege als Vergleichsseiten Dritter, bleiben aber Momentaufnahmen. Die selbst gehosteten Zeilen haben gerade deshalb keinen Abopreis, weil die Kosten in Technik und Betrieb wandern; sie verschwinden nicht.

Consenti: das interessanteste Fragezeichen

Consenti verdient mehr Aufmerksamkeit, weil es die Untersuchung ausgelöst hat und einen ungewöhnlichen Mittelweg einzunehmen versucht.

Das Projekt ist unter Apache-2.0 lizenziert. Es kann als reine Frontend-Integration laufen oder seine Backend-Pakete mit Express, Fastify, Next.js oder einem allgemeinen Node.js-Dienst nutzen. Das Repository enthält derzeit widersprüchliche Hinweise zur Speicherung – die Beispiele verwenden SQLite, während eine technische Entscheidungsnotiz dateibasiertes JSON als Standard und SQLite als optional beschreibt. Vor einer Einführung würde ich daher den vorgesehenen Produktionsadapter prüfen. Consenti speichert Einstellungen, kann Browser-Tabs synchronisieren, erkennt Global Privacy Control, bietet einen optionalen backendgestützten Standortpfad und kann Einwilligungsnachweise führen.

Vor allem besteht die Consent-Mode-Unterstützung nicht nur aus einem Abzeichen auf der Startseite. Die Implementierung ordnet Kategorien analytics_storage, ad_storage, ad_user_data und ad_personalization zu, setzt Standardwerte und veröffentlicht Aktualisierungen. Lädt Google Tag Manager, während diese Werte verweigert sind, ähnelt das Ergebnis dem Advanced Consent Mode. Werden Scripts bis zur Erlaubnis gesperrt, lässt sich ein Basic-ähnliches Setup umsetzen.

Es gibt wichtige Vorbehalte.

Zum Zeitpunkt dieser Prüfung hatte das öffentliche Repository nur neun Commits, und seine Pakete befanden sich noch in der 0.x-Reihe. Scanner-Code ist vorhanden, seine Verteilung und Dokumentation sind jedoch noch nicht so vollständig wie die UI- und API-Pakete. Die Regionsbehandlung kann Backend-IP-Informationen verwenden, während eine reine Browser-Bereitstellung zwangsläufig auf schwächere Signale wie Gebietsschema oder Zeitzone zurückfällt. TCF-/GPP-Unterstützung ist teilweise vorhanden, doch Consenti ist weder registrierte IAB-CMP noch Google-zertifizierte Publisher-CMP. Ein Betreiber müsste diese organisatorische Voraussetzung gesondert lösen; ein cmpId-Feld im Code schafft keine Registrierung.

Das macht Consenti nicht zu einer schlechten Wahl. Es macht die Lösung zu einer jungen Infrastrukturabhängigkeit. Für ein technisch versiertes Team, das Kontrolle möchte, den Quellcode prüfen kann und keinen zertifizierten Publisher-Weg braucht, ist sie einer der vollständigsten quelloffenen Ansätze, die ich gefunden habe. Bei einem globalen Unternehmen würde ich die Einführung wie den Betrieb eines Dienstes behandeln: Versionen fixieren, jede Region testen, Releases überwachen, das Datenmodell prüfen, Aufbewahrung festlegen und bestimmen, wer reagiert, wenn Google oder IAB den Rahmen ändert.

Die größte Stärke der Dokumentation ist, dass sie nicht so tut, als beseitige Selbsthosting diese Verantwortung. Die größte Schwäche ist schlicht die Zeit: Keine Dokumentation kann Jahre produktiver Nutzung für ein Projekt erzeugen, das bei meiner Prüfung noch nicht einmal zwei Monate alt war.

Wie der schlanke Weg aussieht

Am anderen Ende ist CookieConsent v3 ein gutes Beispiel für eine Bibliothek statt einer Plattform. Sie gibt einer Anwendung eine zugängliche Einstellungsoberfläche, Persistenz, Script-Sperrung und Revisionsverhalten. Ihr offizielles Consent-Mode-Beispiel deckt alle vier v2-Werte ab.

Wichtiger ist, was sie bewusst nicht bietet. Sie entdeckt nicht das neue Marketing-Pixel, entscheidet nicht, zu welcher Rechtsregion ein Besucher gehört, führt keinen prüfbaren serverseitigen Verlauf, pflegt keine IAB-Anbieterlisten und benachrichtigt kein Datenschutzteam, wenn eine Richtlinie überprüft werden muss. Das offizielle Beispiel zur Einwilligungsprotokollierung zeigt, wie ein Datensatz an einen eigenen Endpunkt gesendet wird, weil Speicherung und Aufbewahrung Ihre Aufgabe sind.

Für eine persönliche Website kann diese Zurückhaltung genau richtig sein. Bei fünfzig internationalen Angeboten, die mehrere Teams verwalten, kann sie stillschweigend zu einem internen CMP-Produkt werden. Der Banner-Code bleibt klein, während die Verantwortungsfläche wächst.

Ein minimaler Ablauf für Consent Mode v2

Die konzeptionelle Umsetzung ist tatsächlich kurz. Der Standard muss vor GTM, GA4 oder anderen Google-Messbefehlen ausgeführt werden:

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag() { dataLayer.push(arguments); }

  gtag('consent', 'default', {
    analytics_storage: 'denied',
    ad_storage: 'denied',
    ad_user_data: 'denied',
    ad_personalization: 'denied'
  });
</script>

Nachdem der Besucher die relevanten Kategorien erlaubt hat, werden dieselben Signale aktualisiert:

gtag('consent', 'update', {
  analytics_storage: 'granted',
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

Reale Umsetzungen erlauben selten alle vier Signale gemeinsam. Die Analyse-Einwilligung aktualisiert möglicherweise nur analytics_storage; die Werbeeinwilligung steuert die anderen drei. Besucher können eine frühere Zustimmung auch widerrufen. Der Aktualisierungspfad muss deshalb in beide Richtungen funktionieren.

In Next.js muss dieser Standard früh genug ausgegeben werden, damit Framework-Hydration, Routenwechsel und Komponenten für Drittanbieter-Scripts nicht davor laufen. Setzt das Team Consent Mode über ein benutzerdefiniertes GTM-Template statt über Seitencode um, empfiehlt Google die Consent-APIs des Templates (setDefaultConsentState und updateConsentState) statt gtag-Befehle aus dem Template in die Warteschlange zu stellen. Timing ist hier kein Optimierungsdetail. Es entscheidet, ob der Standard die erste Anfrage überhaupt geschützt hat.

Regionale Standardwerte verkomplizieren das saubere Beispiel. Eine globale Website kann in einer Ländergruppe standardmäßig verweigern, andernorts ein anderes Hinweis-Modell anwenden und GPC in relevanten US-Bundesstaaten berücksichtigen. Diese Logik sollte ein dokumentierter Richtlinieninput sein, keine Sammlung von Ländercodes, die das Frontend-Team erfindet.

So würde ich es prüfen

Die Aussage eines CMP-Dashboards, die Verbindung bestehe, reicht nicht. Für jede wesentliche Region und jeden Einwilligungspfad würde ich Folgendes prüfen:

• Enthält das früheste Consent-Ereignis in Google Tag Assistant die vorgesehenen Standardwerte, und enthalten spätere Ereignisse die erwarteten Aktualisierungen?
• Welche Tags wurden in GTM Preview vor der Interaktion, nach „Alle akzeptieren“, nach „Alle ablehnen“ und nach einer granularen Wahl ausgelöst oder blockiert?
• Entsprechen Netzwerkanfragen und Cookies in den Browser-DevTools dem gewählten Basic- oder Advanced-Modell – und nicht nur der im localStorage gespeicherten Banner-Einstellung?
• Erhält ein wiederkehrender Besucher die gespeicherte Wahl, bevor Tags initialisieren, und fragt eine Richtlinien-/Versionsänderung erneut, wenn dies beabsichtigt ist?
• Kann der Besucher Einstellungen genauso leicht wieder öffnen und die Einwilligung widerrufen wie sie zu erteilen?
• Bleibt der Zustand bei der Navigation innerhalb der Next.js-Anwendung erhalten, ohne Tags versehentlich mit veralteter Einwilligung erneut auszulösen?
• Kann das Team, wenn serverseitige Nachweise behauptet werden, einen brauchbaren Datensatz mit Richtlinienversion, Entscheidungen und Zeitstempel unter einer festgelegten Aufbewahrungsregel abrufen?
• Stimmen automatisierte Scans und ein manuelles Tag-Inventar überein? Falls nicht: Welches von beiden liegt falsch?

Googles Leitfaden zum Debuggen von Einwilligungen macht Tag Assistant zum Ausgangspunkt. Ich würde darum wiederholbare Integrationstests für den eigenen Einwilligungsadapter ergänzen. Drittanbieter-Konfiguration kann sich ohne Code-Diff ändern – gerade deshalb muss das Produktionsverhalten regelmäßig geprüft werden.

Die Empfehlung hängt von der Website ab

Einen ehrlichen universellen Gewinner gibt es nicht, weil jede Option eine andere Risikoart bepreist.

Cookiebot überzeugt, wenn ausgereifte Scans, domainübergreifende Einwilligung und abrufbare Einwilligungsdaten wichtig sind. CookieYes bietet die klarsten öffentlichen Tarife und einen der praktischsten dokumentierten Next.js-Wege. iubenda ergibt mehr Sinn, wenn die Organisation neben dem Tag-Zustand auch Datenschutzdokumente und eine Einwilligungsdatenbank möchte. Consenti ist die ambitionierteste selbst gehostete Option dieser Gruppe, sofern das Team sein junges Alter und die fehlende Publisher-Zertifizierung akzeptiert. CookieConsent ist die sauberste Antwort, wenn die tatsächliche Anforderung wirklich nur eine gut gemachte Oberfläche plus anwendungseigene Logik ist.

Als Publisher würde ich mich nicht auf eine Tabelle in einem Blogbeitrag verlassen – auch nicht auf diese. Prüfen Sie vor der Umsetzung Googles aktuelle zertifizierte Liste, die aktuelle IAB-Richtlinie und das konkret verwendete Google-Produkt. TCF v2.3 ist zum Zeitpunkt dieser Prüfung die aktuelle Framework-Version; diese Angabe gehört jedoch zu den Fakten, die besonders schnell veralten können.

Was diese Recherche für mich verändert hat

Ich begann mit einer Preisfrage: Was rechtfertigt eine monatliche Zahlung für etwas, das Entwickler mit wenig JavaScript nachbauen können?

Die bessere Frage lautet: Welche Teile des Einwilligungssystems wollen wir zu unserem eigenen Produkt machen?

Für eine kontrollierte einzelne Website kann die Antwort vernünftigerweise „die meisten“ lauten. Für einen globalen Bestand, der von WordPress zu Next.js wechselt, ist das Banner die am wenigsten interessante Komponente. Inventar, regionale Richtlinien, Nachweise, Widerruf, Reihenfolge der Bereitstellung, Publisher-Status und organisatorische Verantwortung bestimmen die Entscheidung.

Wir haben diese Recherche genutzt, um unsere eigene Wahl anhand unseres Traffics, unserer Länder, Google-Produkte, internen Fähigkeiten und unserer Bereitschaft zur Wartung zu treffen. Ich nenne diese Wahl hier bewusst nicht. Einen Gewinner ohne den vollständigen organisatorischen Kontext zu veröffentlichen, würde genau die Abkürzung fördern, vor der dieser Beitrag warnt.

Eine kostenpflichtige CMP ist nicht automatisch sicherer. Open Source ist nicht automatisch günstiger. Eigener Code ist nicht automatisch einfacher. Es sind drei unterschiedliche Orte für dieselbe Verantwortung.

Wählen Sie den Ort, an dem Ihr Team diese Verantwortung auch in einem Jahr noch tragen kann – nachdem der Entwickler, der Freude am Bannerbau hatte, das Unternehmen verlassen hat, ein Marketingmitarbeiter sechs weitere Tags ergänzt hat und die nächste Version des Einwilligungsrahmens erschienen ist.