Der Consent Manager unterstützt Sie dabei, Einwilligungen für Cookies, Tracking, externe Medien und weitere Drittanbieter-Dienste strukturiert zu erfassen, technisch umzusetzen und nachvollziehbar zu dokumentieren. Das Tool ist nicht nur ein Banner-Baukasten, sondern eine zentrale Arbeitsoberfläche für Domain-Einstellungen, Consent-Kategorien, Service-Vorlagen, Einbindungscodes, Design, Veröffentlichung, technische Diagnosen und optionales Consent-Protokoll.
In diesem Artikel
- So funktioniert das Tool in der Praxis
- Domain-Properties und Grundeinstellungen
- Entwurf, Speichern und Veröffentlichen
- Texte, Sprachen und Banner-Inhalte
- Kategorien, Services und Cookie-Logik
- Service-Vorlagen und eigene Services
- Drei Integrationsarten
- Code-Blöcke, Variablen und Platzhalter
- Google Consent Mode
- Design, Trigger und Vorschau
- Consent Log und CMP-ID
- Snippets und Integration auf der Website
- Diagnostics für Live-Prüfungen
- Export und Import
- Wartung, Revisionen und Löschlogik
- Empfohlene Arbeitsweise
Besonders wertvoll ist der Consent Manager, wenn eine Website nicht nur ein einfaches Cookie-Hinweisfenster benötigt, sondern Dienste sauber nach Kategorien getrennt, bestehende Skripte kontrolliert, eingebettete Medien blockiert und Änderungen kontrolliert veröffentlicht werden sollen. Dadurch behalten Sie die Kontrolle darüber, welche Dienste vor einer Zustimmung geladen werden dürfen, welche erst nach einer Auswahl aktiv werden und wie Besucher ihre Entscheidung später erneut anpassen können.
Die konkrete rechtliche Bewertung ersetzt das Tool nicht. Es schafft jedoch eine belastbare technische Grundlage: Sie können nachvollziehbare Kategorien, klare Texte, servicebezogene Schalter, dokumentierte Revisionen und technische Prüfungen zusammenführen, statt Banner, Skripte und Einwilligungslogik verteilt in verschiedenen Systemen zu pflegen.


So funktioniert das Tool in der Praxis
Der typische Ablauf beginnt mit einer Domain-Property. Sie legen eine Domain ohne Protokoll und Pfad an, zum Beispiel example.com, vergeben bei Bedarf ein internes Label und ergänzen die wichtigsten Basisdaten wie Standardsprache, Datenschutzerklärung, Impressum und erlaubte Hosts. Diese Property wird anschließend Schritt für Schritt konfiguriert.
Danach pflegen Sie die Texte und Sprachen des Banners, aktivieren die passenden Consent-Kategorien, hinterlegen konkrete Services oder wählen Vorlagen aus, passen das Design an und prüfen die Konfiguration in der Vorschau. Erst wenn die Konfiguration fachlich und technisch stimmig ist, veröffentlichen Sie sie. Durch diese Trennung zwischen Entwurf und Veröffentlichung können Sie Anpassungen vorbereiten, ohne die Live-Website sofort zu verändern.
Nach der Veröffentlichung erhalten Sie die öffentliche Konfigurationsadresse und die passenden Einbindungssnippets. In der Regel wird genau ein Standard-Snippet früh im <head> der Zielseite integriert. Anschließend prüfen Sie die Live-Seite mit einer privaten Browsersitzung und mit der integrierten Diagnostik, damit keine alten Consent-Skripte, hart eingebauten Tracker oder ungewollten Requests vor der Zustimmung aktiv bleiben.
Die Oberfläche führt Sie dabei durch die wichtigsten Arbeitsbereiche und zeigt einen empfohlenen nächsten Schritt an, wenn zum Beispiel noch keine Services gepflegt wurden, Pflichtfelder fehlen, die Property noch nicht veröffentlicht ist oder nach der Veröffentlichung eine Diagnostik sinnvoll ist.
Domain-Properties und Grundeinstellungen
Eine Domain-Property ist der zentrale Container für eine CMP-Konfiguration. Alle Texte, Kategorien, Services, Designoptionen, Logs, Diagnosen und Snippets hängen an dieser Property. Dadurch können unterschiedliche Websites getrennt gepflegt werden, ohne dass sich Einstellungen gegenseitig beeinflussen.
| Einstellung | Bedeutung in der Praxis |
|---|---|
| Domain | Die Hauptdomain der Website, ohne https://, ohne Pfad und ohne Unterseite. Sie dient als Primärhost und bleibt immer erlaubt. |
| Label | Eine interne Bezeichnung für die Property. Sie hilft bei der Orientierung in der Domain-Liste und wird automatisch aus der Domain abgeleitet, wenn Sie kein eigenes Label eintragen. |
| Standardsprache | Die Fallback-Sprache des Banners, wenn keine automatische Spracherkennung greift oder für eine Sprache keine passende Übersetzung gepflegt wurde. |
| Datenschutzerklärung | Die URL zur Datenschutzerklärung, die in der veröffentlichten Konfiguration hinterlegt wird und im Consent-Kontext referenziert werden kann. |
| Impressum | Die URL zum Impressum oder zu vergleichbaren Pflichtinformationen der Website. |
| Erlaubte Hosts | Zusätzliche Hosts oder Subdomains, auf denen dieselbe CMP-Konfiguration genutzt werden darf, zum Beispiel www.example.com, shop.example.com oder eine Staging-Subdomain. |
| Public Key | Der öffentliche Schlüssel der Property, der in den Snippets und in der Konfigurationsadresse verwendet wird. Er verbindet die Website mit der richtigen veröffentlichten CMP-Konfiguration. |
| Status und Version | Der Status zeigt, ob eine Property nur als Entwurf existiert oder bereits veröffentlicht wurde. Die Konfigurationsversion hilft zu erkennen, welcher Stand zuletzt live gestellt wurde. |
Die erlaubten Hosts sind besonders wichtig, wenn eine Website über mehrere Hostnamen erreichbar ist. Der Primärhost der Property bleibt immer Bestandteil der erlaubten Hosts. Zusätzliche Hosts sollten Sie bewusst ergänzen, wenn die CMP auf Subdomains, Sprachdomains, Shop-Bereichen oder Testumgebungen verwendet werden soll.
Entwurf, Speichern und Veröffentlichen
Der Consent Manager trennt bewusst zwischen gespeicherten Entwürfen und der veröffentlichten Konfiguration. Speichern sichert Ihre Arbeit im Cockpit. Veröffentlichen erzeugt die öffentliche JSON-Konfiguration, aktualisiert den Live-Stand der Property und stellt die Snippets sowie die öffentliche Konfigurationsadresse bereit.
Diese Trennung ist wichtig, weil CMP-Änderungen oft fachlich geprüft werden müssen. Sie können Texte, Kategorien, Services oder Design anpassen, in der Vorschau kontrollieren und erst danach live stellen. Wenn der veröffentlichte JSON-Stand nicht mehr zu den aktuellen Domain-Daten passt, weist das Tool darauf hin, dass erneut veröffentlicht werden sollte.
Beim Veröffentlichen kann optional eine neue Consent-Revision ausgelöst werden. Das ist für Änderungen gedacht, bei denen Besucher bewusst erneut um eine Entscheidung gebeten werden sollen. Dazu können Sie pro Sprache eine Revisionsnachricht pflegen, die im Banner erklärt, warum eine erneute Auswahl notwendig ist. Normale Pflegeänderungen müssen nicht automatisch eine erneute Zustimmung erzwingen.
Texte, Sprachen und Banner-Inhalte
Im Bereich Text pflegen Sie alle sichtbaren Formulierungen des Banners und der Cookie-Einstellungen. Dazu gehören Titel, Beschreibung, Button-Beschriftungen, Einstellungsdialog, Revisionshinweise, CMP-ID-Hinweise, Kategorie-Titel, Kategorie-Beschreibungen und Texte für blockierte Inhalte wie eingebettete Videos oder Karten.
Das Tool startet mit deutschen und englischen Texten und erlaubt zusätzliche Sprachcodes wie fr, es oder pt-BR. Jede Sprache kann vollständig eigene Banner-, Einstellungs- und Blocker-Texte besitzen. Die Oberfläche zeigt an, ob Pflichttexte für eine Sprache vollständig gepflegt sind.
- Die Standardsprache ist der sichere Fallback, wenn keine erkannte Sprache passt.
- Die automatische Spracherkennung kann sich am Browser oder am Dokumentkontext der Website orientieren.
- Kategorie-Titel und Kategorie-Beschreibungen werden ebenfalls sprachabhängig gepflegt, damit die Cookie-Einstellungen für Besucher verständlich bleiben.
- Die Revisionsnachricht erscheint nur dann im Banner, wenn beim Veröffentlichen tatsächlich eine neue Consent-Revision erzeugt wird.
- Die Texte für blockierte Inhalte werden verwendet, wenn ein Embed oder iFrame erst nach Zustimmung freigegeben werden soll.
Kategorien, Services und Cookie-Logik
Die technische Logik des Consent Managers basiert auf Kategorien und Services. Kategorien beschreiben den Zweck der Einwilligung. Services sind die konkreten Dienste, Skripte, Pixel, Tags, Schriftarten oder Embeds innerhalb einer Kategorie. Diese Trennung sorgt dafür, dass Besucher nicht nur pauschal zustimmen, sondern in den Cookie-Einstellungen nachvollziehen können, welche Dienste hinter einer Auswahl stehen.
| Kategorie | Typische Verwendung |
|---|---|
| Notwendig | Essenzielle Funktionen der Website und der CMP selbst. Diese Kategorie ist immer aktiv und nicht abschaltbar. |
| Funktional | Komfort- und Funktionsdienste wie externe Medien, Karten, Schriftarten, Formularschutz oder andere Inhalte, die für zusätzliche Website-Funktionen benötigt werden. |
| Analytics | Analyse- und Messdienste wie Google Analytics, Matomo, Hotjar oder Microsoft Clarity. |
| Marketing | Werbe-, Remarketing- und Conversion-Dienste wie Google Ads, Meta Pixel, LinkedIn Insight Tag, Microsoft Ads UET, TikTok Pixel oder Pinterest Tag. |
Für einen schnellen Start enthält das Tool Presets für Standard-Setup, Analytics, Marketing, Medien-Embeds und Formulare beziehungsweise reCAPTCHA. Diese Presets legen passende Services an und aktivieren die zugehörigen Kategorien. Danach müssen Sie die jeweiligen IDs, URLs und Texte prüfen und ergänzen, bevor veröffentlicht werden kann.
| Preset | Typischer Inhalt |
|---|---|
| Standard-Setup | Kombiniert Analytics, Marketing, Medien-Embeds und Formularschutz als umfassenden Ausgangspunkt. |
| Analytics | Legt Google Tag Manager und Google Analytics 4 im Analytics-Kontext an. |
| Marketing | Legt einen Meta Pixel im Marketing-Kontext an. |
| Medien-Embeds | Legt Platzhalter für YouTube und Vimeo im funktionalen Kontext an. |
| Formulare / reCAPTCHA | Legt Google reCAPTCHA im funktionalen Kontext an. |
Service-Vorlagen und eigene Services
Beim Hinzufügen eines Services wählen Sie entweder eine Vorlage oder beginnen mit einem manuellen Service. Vorlagen liefern bereits sinnvolle Standardtexte, Anbieterinformationen, Datenschutz-URLs, Variablen, Code-Blöcke und teilweise Platzhalter-Regeln. Trotzdem bleibt jeder Service nach dem Hinzufügen editierbar, damit Sie ihn an die konkrete Website und die tatsächliche technische Einbindung anpassen können.
| Service-Gruppe | Beispiele aus den Vorlagen |
|---|---|
| Google und Tagging | Google Tag Manager, Google Tag, Google Analytics 4, Google Ads und Google Consent Mode-nahe Setups. |
| Marketing-Pixel | Meta Pixel, LinkedIn Insight Tag, Microsoft Ads UET, TikTok Pixel und Pinterest Tag. |
| Analytics und UX-Analyse | Matomo Analytics, Matomo Tag Manager, Hotjar und Microsoft Clarity. |
| Funktionale Dienste | Google Fonts und Google reCAPTCHA. |
| Embed-Platzhalter | YouTube, Vimeo und Google Maps mit CSS-Selektoren für vorhandene iFrames. |
Im Service-Editor bearbeiten Sie Kategorie, Aktivstatus, Namen und Beschreibung pro Sprache, Anbietername, Datenschutz-URL, Variablen und Code-Blöcke. Pflichtfelder werden direkt markiert. Ein Service kann erst sauber veröffentlicht werden, wenn die notwendigen Werte ausgefüllt sind. Optional sichtbare Warnungen helfen, auffällige oder unvollständige Einstellungen früh zu erkennen.
Für Website-eigene Skripte zeigt das Tool sowohl kategoriebezogene Attribute als auch servicebezogene Werte wie Public Service Key, data-service und kombinierte Beispiel-Snippets. Dadurch können Sie vorhandene Script-Tags gezielt einem konkreten Service-Schalter zuordnen, statt nur die gesamte Kategorie zu verwenden.
Drei Integrationsarten
| Integrationsart | Wann Sie sie nutzen | Wichtiger Hinweis |
|---|---|---|
| CMP-geladene Services | Das CMP lädt Skripte, Stylesheets, HTML oder Platzhalter erst nach der passenden Zustimmung. | Diese Variante eignet sich für Dienste, die vollständig über die CMP-Konfiguration kontrolliert werden sollen. |
| Website-eigene Skripte | Ein Skript bleibt im Website-Code, wird aber mit Attributen wie type="text/plain", data-category und optional data-service durch CookieConsent gesteuert. | Nutzen Sie diese Variante, wenn das Skript technisch bewusst im Website-Code bleiben soll. |
| Embed- und iFrame-Platzhalter | Vorhandene Einbettungen wie YouTube, Vimeo oder Google Maps sollen zunächst verborgen bleiben und erst nach Zustimmung erscheinen. | Dafür hinterlegen Sie CSS-Selektoren, zum Beispiel für bestimmte iFrame-Quellen. |
Wichtig ist, dass derselbe Dienst nicht doppelt verwaltet wird. Ein Tracker sollte entweder als CMP-geladener Service konfiguriert oder als Website-eigenes Skript markiert werden. Wenn beides parallel geschieht, entstehen schwer nachvollziehbare Ladezeitpunkte und doppelte Ausführungen.
Wenn ein Service einer deaktivierten Kategorie zugeordnet ist, weist die Oberfläche darauf hin. In der Praxis sollten Kategorie und Service immer zusammen betrachtet werden: Ein aktivierter Service in einer deaktivierten Kategorie kann nicht die erwartete Besucherentscheidung abbilden.
Code-Blöcke, Variablen und Platzhalter
Vorlagen arbeiten mit Variablen wie einer GA4 Measurement ID, einer Google Ads Conversion ID, einer Meta Pixel ID oder einer Matomo-URL. Die Platzhalter bleiben im gespeicherten Code erhalten und werden erst direkt vor der Ausführung mit den gepflegten Werten ersetzt. Dadurch bleibt nachvollziehbar, welche Teile des Codes aus der Vorlage stammen und welche Werte von Ihnen gepflegt wurden.
| Code-Block | Verhalten |
|---|---|
| Externe Script-URLs | Eine HTTPS-URL pro Zeile. Das CMP lädt die Script-Tags nach Zustimmung in derselben Reihenfolge. |
| Externes Stylesheet | Eine Stylesheet-URL, zum Beispiel für Google Fonts, die erst nach Zustimmung geladen wird. |
| Tracking-Script | JavaScript, das nach Zustimmung ausgeführt wird. Ein äußerer <script>-Wrapper kann beim Speichern normalisiert werden. |
| Zusätzlicher HTML-Code | Ein HTML-Fragment, das nach Zustimmung am Ende von document.body eingefügt wird. |
| Noscript-Fallback | Ein Fragment für Besucher ohne JavaScript. Ein äußerer <noscript>-Wrapper kann beim Speichern normalisiert werden. |
Bei eigenen oder angepassten Code-Blöcken nutzt der Consent Manager ein Warn- und Audit-Modell. Auffällige Muster werden nicht pauschal verdeckt, sondern für die Prüfung sichtbar gemacht. Änderungen an Service-Code werden dabei als Änderungsnachweis mit Hashes protokolliert, ohne den rohen Script-Inhalt in diesem Audit-Verlauf abzulegen.
Google Consent Mode
Der Bereich Google Consent Mode ist für Setups gedacht, in denen Google Tag Manager, Google Tag, Google Ads oder Google Analytics aktiv Consent-Signale erhalten sollen. Dort ordnen Sie CMP-Kategorien den Google-Signalen zu. Typische Signale sind analytics_storage für Analyse, ad_storage, ad_user_data und ad_personalization für Marketing sowie functionality_storage und security_storage für funktionale Kontexte.
Consent Mode ersetzt nicht das technische Blockieren hart eingebauter Skripte. Er ergänzt die CMP-Konfiguration, indem nach einer Entscheidung passende Google-Signale übermittelt werden. Wenn Google-Dienste bereits an anderer Stelle fest im Website-Code laufen, sollten diese Einbindungen ebenfalls geprüft und entweder sauber markiert oder in die CMP-Service-Logik überführt werden.
- Aktivieren Sie Google Consent Mode nur, wenn Ihre Website tatsächlich Google Tag Manager, Google Tag, Google Ads oder Google Analytics nutzt.
- Ordnen Sie nur aktive CMP-Kategorien sinnvollen Google-Signalen zu.
- Verwenden Sie keine parallelen frühen Google-Defaults an mehreren Stellen, wenn das CMP bereits diese Aufgabe übernehmen soll.
- Prüfen Sie nach der Integration, ob Tags vor und nach der Zustimmung das erwartete Verhalten zeigen.
Design, Trigger und Vorschau
Im Design-Bereich passen Sie das Consent Modal, das Preferences Modal, Farben, Theme, Trigger-Verhalten und zusätzliche Darstellungsoptionen an. Die integrierte Vorschau rendert den aktuellen Entwurf mit CookieConsent v3, sodass Sie Layout, Button-Gewichtung, Texte, Farben und den Einstellungsdialog prüfen können, bevor Sie veröffentlichen.
| Designbereich | Einstellungen |
|---|---|
| Consent Modal | Layout-Varianten wie Box, Cloud oder Bar, Position, Button-Reihenfolge und gleiche Button-Gewichtung. |
| Preferences Modal | Layout als Box oder Bar, Position bei Bar-Layouts, Button-Reihenfolge und Button-Gewichtung. |
| Theme | Voreinstellungen wie hell, dunkel, Dark Turquoise, Light Funky oder Elegant Black. |
| Button-Farben | Primäre und sekundäre Button-Hintergründe sowie automatische oder manuelle Textfarbe. |
| Verhalten | Dunkler UI-Modus, Deaktivierung der Seiteninteraktion während des Erstbanners und Deaktivierung von CMP-Animationen. |
| Trigger | Persistenter Zugriff auf die Cookie-Einstellungen nach der ersten Besucherentscheidung, entweder als Floating Button oder Footer Link. |
| Custom CSS | Erweiterte CSS-Anpassungen mit Validierung. Nutzen Sie dies vor allem für Feinschliff außerhalb der eigenen Button-Farbsteuerung. |
Der Trigger erscheint erst, nachdem ein Besucher eine erste Entscheidung getroffen hat. Das verhindert, dass ein zusätzlicher Cookie-Button den initialen Banner überlagert. In der Live-Prüfung sollten Sie kontrollieren, ob der Trigger nach der Entscheidung sichtbar ist und die Cookie-Einstellungen zuverlässig erneut öffnet.
Consent Log und CMP-ID
Das Consent Log kann pro Banner anonymisierte Consent-Änderungen speichern. Es arbeitet mit der nativen CMP-ID und speichert Entscheidungstyp, akzeptierte und abgelehnte Kategorien, akzeptierte und abgelehnte Services, Host, Sprache und Zeitstempel. IP-Adressen und WordPress-User-IDs werden dabei nicht gespeichert.
Wenn das Logging aktiv ist und auf der Live-Website eine echte Consent-Entscheidung vorliegt, kann die CMP-ID in den Cookie-Einstellungen angezeigt werden. Besucher können diese ID bei Rückfragen referenzieren, während Sie im Cockpit nach der CMP-ID suchen, Entscheidungen prüfen und relevante Protokolle exportieren können.
- Die Statistik zeigt Gesamtentscheidungen, „Alle akzeptieren“, „Alle ablehnen“ und individuelle Auswahl.
- Eine Tagesansicht visualisiert die Entwicklung gespeicherter Entscheidungen im gewählten Zeitraum.
- Die Kategorieauswertung zeigt, welche optionalen Kategorien häufig akzeptiert wurden.
- Das Protokoll kann nach CMP-ID sowie Datum von und bis gefiltert werden.
- Ein CSV-Export unterstützt die strukturierte Weitergabe oder Archivierung ausgewählter Nachweise.
- Datensätze werden 180 Tage nach der letzten Consent-Änderung einer CMP-ID automatisch entfernt.
- Die Vorschau erzeugt keine echten Logeinträge. Nur die veröffentlichte Live-Runtime schreibt in das Consent Log.
Snippets und Integration auf der Website
Nach der Veröffentlichung stellt der Consent Manager die öffentliche Konfigurationsadresse und mehrere Einbindungsvarianten bereit. Für die meisten Websites ist das CSP-freundliche Standard-Snippet der richtige Weg. Es wird früh im <head> platziert, idealerweise vor Tag Managern und vor anderen Tracking-Skripten. Für WordPress kann alternativ ein PHP-Snippet genutzt werden, das früh in wp_head ausgibt.
Das Tool zeigt zusätzlich ein Snippet mit frühen Google-Defaults. Dieses sollte nur eingesetzt werden, wenn ein Setup diese frühe Signalisierung ausdrücklich benötigt. Entscheidend ist, dass Sie nicht mehrere Consent-Systeme oder Google-Default-Mechaniken parallel betreiben.
Die öffentliche Konfiguration wird über die CMP-Einbindung geladen. Die benötigte Runtime und die CookieConsent-Bausteine werden über die CMP-Routen ausgeliefert, sodass Sie im Normalfall keine separaten CookieConsent-Dateien in der Website hinterlegen müssen.
- Veröffentlichen Sie die Domain zuerst, bevor Sie das finale Snippet übernehmen.
- Entfernen Sie alte CMP-, Cookie- oder Consent-Plugin-Ausgaben vollständig, bevor das neue Snippet live getestet wird.
- Integrieren Sie genau eine CMP auf derselben Website.
- Platzieren Sie das Standard-Snippet sehr früh im
<head>. - Prüfen Sie in einer privaten Browsersitzung, ob Banner, Buttons, Einstellungen, Trigger und blockierte Inhalte wie erwartet funktionieren.
- Kontrollieren Sie anschließend mit der Diagnostik, ob noch unerwartete Tracker, Cookies oder Requests vor der Zustimmung aktiv sind.
Diagnostics für Live-Prüfungen
Die Diagnostik scannt eine konkrete Ziel-URL Ihrer Property und prüft technische Signale vor der Zustimmung. Dabei werden Requests, initial gesetzte Cookies und Warnhinweise zu auffälligen Ressourcen oder Integrationsfehlern ausgewertet. Die Ziel-URL muss zur Domain oder zu den erlaubten Hosts der Property passen.
Diese Prüfung ist besonders nützlich vor dem Livegang, nach Relaunches, nach Tag-Manager-Änderungen, nach Theme-Anpassungen oder nach der Einbindung neuer Drittanbieter. Viele Consent-Probleme entstehen nicht im Banner selbst, sondern durch hart eingebauten Code, alte Plugin-Ausgaben oder externe Skripte, die bereits vor der CMP-Entscheidung laufen.
- Scannen Sie nicht nur die Startseite, sondern auch Seiten mit Formularen, Videos, Karten, Kampagnen-Landingpages und Tracking-relevanten Elementen.
- Viele frühe Requests oder initiale Cookies sind ein Hinweis auf Skripte außerhalb der CMP-Kontrolle.
- Warncodes helfen dabei, zuerst die technisch kritischsten Einbindungen zu prüfen.
- Ein sauberer Scan ersetzt keine fachliche Endkontrolle, beschleunigt aber die technische Fehlersuche erheblich.
- Bis zu 25 jüngste Diagnose-Läufe bleiben je Property abrufbar, sodass Sie den aktuellen technischen Prüfstand nachvollziehen können.
Export und Import
Mit Export und Import können Sie CMP-Konfigurationen zwischen ähnlichen Properties wiederverwenden. Der Export erzeugt ein JSON-Bundle mit bewusst ausgewählten Modulen. Beim Import wählen Sie erneut, welche Module in die Ziel-Property übernommen werden sollen. Nicht ausgewählte Bereiche bleiben unverändert.
| Modul | Was übertragen wird |
|---|---|
| Allgemein | Standardsprache, rechtliche URLs und erlaubte Hosts, wobei die Primärdomain der Ziel-Property weiterhin maßgeblich bleibt. |
| Kategorien | Aktivierte Consent-Kategorien. |
| Consent Mode | Google Consent Mode-Aktivierung und Signal-Zuordnung. |
| Text | Alle Spracheinstellungen und gepflegten UI-Texte. |
| Design | Modal-Layout, Theme, Trigger, Farben, Verhalten und Custom CSS. |
| Services / Cookies | Konfigurierte Services, Vorlagenkopien, Parameter, Code-Blöcke und Platzhalter-Einstellungen. |
Identitätswerte wie Domain, Public Key, Versionsstände und Consent-Revision bleiben property-spezifisch. Nach jedem Import sollten Sie die betroffenen Tabs prüfen, speichern, in der Vorschau kontrollieren und erst dann veröffentlichen.
Wartung, Revisionen und Löschlogik
CMP-Konfigurationen sind keine einmalige Einrichtung. Neue Marketing-Tags, geänderte Analytics-Setups, externe Medien, Formularschutz, Designanpassungen oder veränderte rechtliche Texte können eine Aktualisierung notwendig machen. Der Consent Manager unterstützt diese Wartung durch Entwürfe, Veröffentlichungsstände, Revisionen, Diagnosen, Export/Import und nachvollziehbare Service-Code-Änderungen.
Wenn eine Domain-Property gelöscht wird, werden auch zugehörige veröffentlichte Konfigurationsdaten, Diagnosen, Consent-Logs und Service-Audit-Daten entfernt. Deshalb sollte eine Property nur gelöscht werden, wenn sie wirklich nicht mehr benötigt wird. Für laufende Websites ist es meist besser, die bestehende Property zu pflegen und erneut zu veröffentlichen.
Empfohlene Arbeitsweise
- Beginnen Sie mit einer sauberen Domain-Property und ergänzen Sie erlaubte Hosts nur dann, wenn diese Hostnamen die CMP wirklich nutzen sollen.
- Pflegen Sie zuerst Texte und Sprachen, damit Kategorien und Services später direkt in der richtigen Besucherkommunikation erscheinen.
- Aktivieren Sie nur die Kategorien, die Ihre Website tatsächlich benötigt, und ordnen Sie jeden Dienst einer nachvollziehbaren Kategorie zu.
- Nutzen Sie Vorlagen als Startpunkt, prüfen Sie aber immer IDs, Anbieterinformationen, Datenschutz-URLs, Code-Blöcke und Platzhalter-Regeln.
- Entscheiden Sie pro Dienst eindeutig zwischen CMP-geladener Integration, website-eigenem markiertem Skript oder Embed-Platzhalter.
- Veröffentlichen Sie erst, wenn keine Pflichtfelder fehlen und die Vorschau die gewünschte Nutzerführung zeigt.
- Entfernen Sie alte Consent-Lösungen vollständig, bevor Sie das neue Snippet live testen.
- Führen Sie nach jeder relevanten Änderung eine Diagnostik auf echten Seiten durch, nicht nur auf der Startseite.
- Verwenden Sie eine neue Consent-Revision nur für Änderungen, bei denen Besucher bewusst erneut entscheiden sollen.
- Dokumentieren Sie intern, welche Services technisch über die CMP laufen und welche bewusst über markierte Website-Skripte kontrolliert werden.