Die ehrliche Consent Manager Checkliste: CMP-Features vs. Praxis-Anforderungen

Meine Probleme sind bestimmt nicht vergleichbar mit denen des Anton aus "Es ist nicht leicht ein Gott zu sein", aber auch Agnostiker haben es manchmal schwer. Wenn es um Webanalyse, Tag Manager, Reporting Plattformen und andere Themen geht, bezeichne ich mich gern als "tool-agnostisch". In wenigen Kategorien fällt mir das allerdings so schwer wie bei Consent Management Plattformen. Und obschon meine Berührungspunkte primär mit der (oft sehr holprigen) Zusammenarbeit zwischen Consent Manager, Consent Mode und Tag Manager zu tun haben (siehe mein E-Book dazu ;)) und dieser Bereich schon genug Stolperfallen bereithält, kenne ich aus der Praxis auch das eine oder andere Backend und die im Tool verankerten Prozesse.

Meistens dann, wenn es nicht rund läuft. Da es aber zu meinem Alltag gehört, Kunden bei der Implementierung und Optimierung von Tracking-Setups zu begleiten - und die CMP ist dabei die erste und oft schmerzhafteste Weichenstellung -, werde ich auch gelegentlich um Rat gefragt, welches Tool man anschaffen sollte. Weil das alte entweder schlichtweg schon auf den ersten Blick nicht die datenschutzrechtlichen Anforderungen erfüllen kann, zu teuer geworden ist oder man schlechte Erfahrungen gemacht hat. Mit der API, der Zuverlässigkeit, der Gestaltungsoptionen des Consent Dialogs... Gründe gibt es genug.

Gerade heute landete wieder eine dieser Anfragen in meinem Postfach, die ich in ähnlicher Form schon mehrfach bekommen habe: Ein größeres Unternehmen will seine bestehende CMP ablösen. In diesem Fall OneTrust, was nicht ganz unüblich ist, (räusper) und hat dafür ein Anforderungsprofil in einer Excel-Liste zusammengestellt. Verschiedene Anbieter sollen diese Liste beantworten und ich habe ein solches Exemplar bekommen, mit dem Feedback eines der Anbieter. Das klingt nach einem vernünftigen Prozess. Ist es auch - aber leider nur auf den ersten Blick.

Die Excel-Liste: Grüne Haken, wohin man schaut

Die Liste enthielt die üblichen Verdächtigen: Sprachlokalisierung, einfacher Widerruf, Consent Mode v2 (allerdings nur auf Google bezogen, kein Wort von MS Ads oder Clarity - sei´s drum), Cookie-Scanning, kein Script-Blocking durch die CMP (das ist auch idealerweise immer Aufgabe des Tag Managers), DataLayer-Integration, Google-Zertifizierung. Alles als "Must" gekennzeichnet, alles vom angefragten Anbieter brav mit "Compliant" beantwortet, garniert mit Links zur eigenen Dokumentation und dem ein oder anderen Marketing-Superlativ.

Die meisten dieser Punkte sind auch bei vielen Anbietern abgedeckt. Google selbst hat eine große und ständig wachsende Liste von zertifizierten CMPs, mit denen es i. d. R. unproblematisch zugeht, wenn man Ads schalten will. Ich habe diese Liste als Inspiration verwendet, um meinem GTM Consent & Checkup Helper möglichst viele Tools "beizubringen" und schon bei der Fokussierung auf die Art und Weise, wie hier mit dem Speichern und Kommunizieren der Zustimmung umgegangen wird, hat mir mehr Fragmentierung und Grenzfälle vor Augen geführt, als es wünschenswert ist.

Und genau hier beginnt das Problem. Denn diese Liste prüft, ob ein Feature existiert. Sehr digital, Null oder Eins, grüner Haken oder rotes Kreuz. Sie prüft nicht, wie es funktioniert. Und schon gar nicht, wie es sich anfühlt, wenn man es zum zwanzigsten Mal benutzt, weil wieder ein neuer Dienst eingebunden werden muss, den kein Scanner dieser Welt kennt. Die Realität ist leider auch hier viel komplexer, als es sich die Checklisten da draußen wünschen. Was an deren Herkunft liegt: Checklisten werden von Anbietern erstellt.

Die Antworten klingen immer gut

Nehmen wir das Thema DataLayer-Integration. Der Anbieter schreibt (sinngemäß): "Unsere CMP feuert automatisch mehrere Events in den DataLayer für perfektes Tracking, darunter irgendein_consent_eventname bei Seitenaufruf und Consent-Änderungen, immer mit detaillierten Consent-Variablen für die Tag-Management-Integration."

Das klingt großartig. Es klingt nach jemandem, der weiß, was ein DataLayer ist. Was es nicht verrät: Wie viele Events genau? In welcher Reihenfolge? Gibt es ein einziges, verlässliches Event, an dem alle Consent-Informationen gebündelt vorliegen und das als universeller Trigger taugt - oder feuert das System ein regelrechtes Dauerfeuer an Einzel-Events für jede Kategorie und jeden Vendor, nach dem dann irgendwann, vielleicht, hoffentlich, noch ein zusammenfassendes Event kommt? Manche Systeme liefern ein sauberes "Hier ist die Consent-Lage und der Consent Mode ist jetzt fertig"-Event und man ist im Bilde. Andere ballern erst dutzende Einzel-Events raus und das Event, das man eigentlich als Trigger braucht, kommt - wenn überhaupt - erst danach. Im Google Tag Manager wird aus "nahtloser Integration" dann ein Trigger-Setup, das man niemandem erklären möchte oder man integriert Helper in Custom HTML Tags, die das "Jetzt kannst Du"-Event nachpflegen, weil man nun mal für Facebook und GA die gleiche Event-ID verwenden muss, um die Deduplizierung für die CAPI nicht zu vermasseln. Wie ich schon sagte: Details können sehr entscheidend sein.

DataLayer-Dauerfeuer im GTM Preview Mode, aber wenigstens mit klarem Signal am Ende in Push 15.

Und fangen wir lieber gar nicht von Cookie-Scannern an. Naja, müssen wir (leider) ja. "Unsere Lösung scannt automatisch Ihre Website, erkennt alle Tracker und Cookies, kategorisiert sie nach Typ, Anbieter, Zweck und Lebensdauer." Auch hier: Klingt fantastisch. Aber ist der Scanner ein hilfreiches Werkzeug oder ein zwingender Flaschenhals? Es gibt Systeme, bei denen man erst ein Tag live auf der Website einbauen muss - es also faktisch ohne Consent feuern lassen muss - damit der Scanner das Cookie überhaupt findet und man den Dienst danach einer Kategorie zuordnen kann. Das ist nicht nur ein absurder Workflow, das ist ein Workflow, der gegen jede Compliance-Logik verstößt. Und es gibt ihn häufiger, als man denkt.

Mein Tipp an den Kunden: Der Killer-Test

Denn das ist der Moment, in dem Marketing-Versprechen auf Realität treffen. Genau diesen Prozess wird man als Anwender immer und immer wieder durchlaufen, nachdem der Vertrag unterschrieben ist. Nicht der Scanner entscheidet über die Alltagstauglichkeit, sondern die Frage: Wie schnell und intuitiv lege ich einen Dienst manuell an? Was passiert, wenn ein neues Cookie im Report auftaucht, das keiner kennt? Je nachdem, wie viel mir das System über dieses Cookie verrät und wie einfach ich es selbst konfigurieren kann, wird es entweder eine Sache von zwei Minuten oder ein halber Tag mit Dokumentation lesen, Support-Tickets beim Dienstanbieter, Suchen in der Doku... und am Ende ganz viel Frust. Selbst ich weiß bei vielen Cookies von Trackingdiensten, die ich im Auftrag meiner Kunden verbaue, beim besten Willen nicht, welchem Zweck diese wohl dienen. Manchmal nicht einmal, wer sie wann und wie gesetzt hat. Das alles herauszufinden kostet Zeit. Leider ist eine Auflistung nun mal (offenbar, ich bin kein Anwalt - aber der gute Dr. DSGVO hat mich da mal sehr wirkungsvoll abprallen lassen, als ich das wegdiskutieren wollte) erforderlich. Aber wenn der Anbieter manchmal selbst nicht weiß, warum ein Cookie existiert und wie groß die Katastrophe ist, wenn es fehlt, dann ist die Erfüllung dieser Anforderung oft schwierig... oder endet in sehr generischen Beschreibungen, die keinem weiterhelfen.

Die Suche nach einer ehrlichen Checkliste

Getriggert durch die Anfrage und meine lange Antwort, die dennoch bei gründlicherem Nachdenken nur die Spitze des Eisbergs gestreift hatte, wollte ich wissen, ob es irgendwo eine CMP-Checkliste gibt, die über die üblichen Feature-Haken und Selbstverständlichkeiten hinausgeht. Eine, die die Fragen stellt, die man erst zu stellen lernt, nachdem man die dritte CMP-Migration hinter sich hat. Also habe ich das probiert, was man heute eben tut: Den KI-Modus von Google bemüht, ein paar LLMs befragt und mich durch die Ergebnisse gearbeitet.

Das Resultat war - diplomatisch formuliert - ernüchternd. Was mir angeboten wurde, war eine Mischung aus Feature-Beschreibungen in maximal zehn Worten, Links zu den Marketing-Seiten der CMP-Hersteller (die natürlich alle bei jeder Anforderung gut aussehen) und generisches Compliance-Blabla, das man in jede beliebige Datenschutz-Präsentation kopieren könnte, ohne dass jemand merkt, woher es stammt. Alles, was man findet, ist direkt oder indirekt (über "Partner" und "zertifizierte Berater") von den Anbietern selbst produziert oder nachgeplappert. Unabhängige Praxisberichte von Consultants, die wirklich regelmäßig CMPs implementieren und warten? Fehlanzeige.

Also mache ich es selbst - zumindest aus meiner Perspektive, die stark von Implementierung geprägt ist. Da ich zudem in den letzten Jahren auch aus Projekten oder eigener Erfahrung ein paar Stolperfallen jenseits des dataLayers kenne, versuche ich mit diesem Post, genau die Checkliste zu schreiben, die es offenbar noch nicht gibt. Keine Feature-Matrix, kein Anbietervergleich, keine Empfehlung. Stattdessen: Die Fragen, Konzepte und Details, die nach meinem Wissensstand wirklich über die Alltagstauglichkeit einer CMP entscheiden. Ich versuche dies zu tun, ohne einen einzigen Anbieter namentlich zu nennen oder zu bewerten. Denn die Konzepte sind wichtiger als die Namen, und wer die richtigen Fragen kennt, findet die richtigen Antworten selbst. Sollte ein einzelnes Feature, das hier beleuchtet wird, exklusiv für einen einzelnen Anbieter sein und daher eine Identifizierung erlauben: Sorry. Aber Daten wirklich anonym zu halten, ist halt schwieriger, als man denkt 😉

Was man wirklich fragen sollte

Die folgenden Punkte sind das, was selten in einer Excel-Liste auftaucht. Punkte, die erst dann relevant werden, wenn man das Tool tatsächlich in einem gewissen Umfang benutzt. Meint: Nicht alle Aspekte sind gleich relevant für jeden. Wer nur "ein Banner" braucht, damit Google das Ads Konto wieder entsperrt und es nur client-side Google Ads & Analytics auszuspielen gibt, braucht nicht viel und kann fast jedes Tool einsetzen. Wo eine API Integration (wozu auch immer - Consent im Browser, Daten zur Auswertung) ein Thema ist oder Self-Service für zahlreiche Auskünfte im "Compliance Center" im Fokus steht, wird andere Checkpunkte brauchen. Eben aus den echten Anforderungen, die sich nicht an die Idealvorstellungen der Produktmanager halten, sondern zum eigenen Anforderungsprofil und den bestehenden oder geplanten Prozessen passen.

DataLayer-Integration: Wann weiß ich, woran ich bin?

Im Einleitungsteil habe ich das "Dauerfeuer"-Problem bereits angesprochen. Es lohnt sich, hier tiefer zu graben, denn die Art, wie eine CMP ihre Consent-Entscheidungen an den Tag Manager kommuniziert, bestimmt die Komplexität des gesamten Setups dahinter.

Das Ideal ist simpel: Ein Event, ein Zeitpunkt, alle Informationen - und diese erst dann und nicht schon "zu früh" (z. B. direkt aus einem Cookie auf Folgeseiten nach Entscheidung), um die ohnehin schon problematischen Race Conditions nicht noch zu verschlimmern. Wenn ich im Google Tag Manager einen einzigen Custom Event Trigger bauen kann, der mir zuverlässig sagt "der Consent-Status steht jetzt fest, hier sind die Details" - dann ist das Setup beherrschbar. Ein Triggerkonzept, in dem man sicher vor diesem Zeitpunkt alles blockieren kann und danach ebenso sicher alles feuern kann, ist selbst bei viel zu früh im dataLayer erscheinenden E-Commerce Events mit Hilfe des Data Layer Event Repeaters überschaubar und robust aufzusetzen. Wenn ich weiß, wann ich was feuern darf und mir die CMP Änderungen auf gleiche Weise mitteilt wie eine bereits vorhandene oder initiale Entscheidung, kommt dasselbe Event im schlimmsten Fall entweder nochmal mit aktualisierten Werten oder es entgeht dem Tracking ggf. ein E-Commerce Event wie view_item, aber die wichtigen Dinge, die zur Attribution wesentlich sind, bleiben intakt.

Die Realität sieht bei manchen Systemen allerdings anders aus. Da kommen beim Seitenaufruf erst Events für die Initialisierung, dann einzelne Events pro Kategorie oder sogar pro Vendor, dann vielleicht ein Ready-Event, und irgendwo dazwischen setzt Consent Mode seine Signale, gern auch mehrfach, lustig abwechselnd mal als "default" oder auch "update". So viele Buchstabenkombinationen kann Google gar nicht erfinden, um das im gcs Parameter abzubilden (Sorry, ein sehr nerdiger Scherz - einfach übergehen). Welches dieser Events ist jetzt der richtige Trigger? Das, nach dem wirklich alle Informationen vorliegen? Manchmal das letzte in der Kette - aber "das letzte" ist kein stabiler Trigger, wenn die Reihenfolge oder Anzahl je nach Konfiguration variiert. Das Ergebnis sind Custom HTML Tags mit Workarounds, die darauf warten, dass sich der DataLayer beruhigt hat oder die JS API des Tools nach Details fragt oder selbst im Cookie nachsehen muss, um die Consent Werte sauber gemeinsam mit dem "Jetzt wirklich"-Ereignis in die Datenschicht zu schreiben. Das funktioniert, natürlich. Aber es ist ein Indikator dafür, dass die Integration der CMP nicht zu Ende gedacht ist (und das ist traurig).

Wer lädt wen: CMP und Tag Manager

Ein Thema, das die Wahl der CMP nur bedingt betrifft, aber dennoch in diesem Kontext immer gern auftaucht: Lädt die CMP den Tag Manager oder lädt der Tag Manager die CMP? Die Frage klingt akademisch, hat aber handfeste Konsequenzen. Wenn der Google Tag Manager von googletagmanager.com geladen wird (also ohne First-Party-Serving über Lösungen wie serverseitiges Tagging, Google Tag Gateway, Proxies oder spezialisierte Dienste), dann ist er ein "Third-Party-Script" - und es kommt auch noch ausgerechnet von Google. Wer seine CMP in diesen Tag Manager packt, riskiert daher, dass die ganze Nummer im Bundle von AdBlockern torpediert wird und weder das eine, noch das andere geladen wird.

Steckt im Tag Manager wirklich nur die CMP und auf Zustimmung angewiesenes Tagging, ist das tatsächlich egal. Wenn aber der Tag Manager noch andere Aufgaben hat oder - was viel wahrscheinlicher ist - die CMP auch Dinge auf der Website blockieren oder freigeben muss, die nichts mit Tagging zu tun haben (Videos, eingebettete Inhalte, Third Party iFrame-Gedöns), ist dieses Paket aus GTM von Google → CMP schlecht geschnürt. Im ersten Fall kommt nur "Kein Consent-Dialog, kein Consent, kein legales Tracking" raus. Im zweiten Fall mag ein Blocker der CMP, auf den man sich verlassen hat (bitte nie tun!), fehlen und so werden ohne Zustimmung YouTube Videos geladen, Cookies gesetzt und überhaupt geht sofort die Welt unter! Auch doof: Man merkt es nicht, weil betroffene Nutzer einfach ohne Banner durchrutschen und in keiner Statistik als "kein Consent" auftauchen - sie tauchen gar nicht auf. Und sehen hoffentlich nicht so genau hin, wenn es doch Cookies und Videos zu sehen gibt.

Bei allen Custom Templates, die viele CMPs so gern anpreisen, um damit "ganz einfach via Tag Manager" auf die Seite zu gelangen: Dieser Weg ist nicht ideal. Die CMP sollte idealerweise direkt auf der Seite implementiert sein. Sie kann den Consent verwalten und anschließend den Tag Manager laden oder die Einbindung ggf. (bei korrekter Reihenfolge im Code - bitte testen und nicht glauben) zurückhalten, bis Zustimmung gegeben wurde. Bindet man dies z. B. an Statistik Consent, ist das nicht "optimal", aber praxistauglich. Kein Consent zu Statistik? Kein Tag Manager. Das ist vollkommen okay, solange im Tag Manager wirklich nur Tagging steckt, das auf Zustimmung angewiesen ist. Über Advanced Consent Mode reden wir hier jetzt explizit nicht. Wer mag, darf sich gern im entsprechenden Video meine Haltung dazu abholen.

Höre ich da einen Einwand? "Aber dann verliere ich ja alle Besucher, die zwar Marketing erlauben, aber Statistik ablehnen!" Stimmt. Theoretisch. Praktisch ist dieser Fall so exotisch, dass er im Rauschen der normalen Consent-Raten verschwindet. Wer aktiv "Marketing ja, Statistik nein" klickt, ist ein Einhorn unter den Besuchern. Die allermeisten stimmen entweder allem zu oder lehnen alles ab. Und für den Fall, dass man den Tag Manager bei "alles abgelehnt" trotzdem braucht, gibt es Lösungen. Aber das ist eine Architektur-Entscheidung, die man bewusst treffen sollte, nicht eine, die einem der CMP-Anbieter abnimmt.

Service-Konfiguration im Alltag: Jenseits des Killer-Tests

Der Killer-Test aus dem vorigen Abschnitt zeigt, ob das manuelle Anlegen eines Dienstes grundsätzlich möglich und einigermaßen intuitiv ist. Aber er zeigt noch nicht, wie der Alltag danach aussieht. Denn ein Dienst wird nicht einmal angelegt und dann nie wieder angefasst.

Was passiert, wenn der Anbieter des Tracking-Pixels seine Cookie-Namen ändert? Oder ein neues Cookie hinzufügt, das beim nächsten Scan als "unbekannt" auftaucht? Wie einfach ist es, einen bestehenden Dienst um ein Cookie zu ergänzen, ohne das ganze Setup neu konfigurieren zu müssen? Und - eine Frage, die ich aus eigener leidvoller Erfahrung stellen gelernt habe -: Gibt es ein Changelog oder eine Benachrichtigung, wenn die CMP selbst ihre vorgefertigten Dienst-Templates aktualisiert? Denn manche Systeme aktualisieren ihre interne Datenbank, und plötzlich hat ein Dienst, den man vor Monaten konfiguriert hat, andere Cookie-Zuordnungen als vorher. Ohne dass man irgendetwas geändert hätte. Dazu gleich mehr im Abschnitt über stille Änderungen, die auch andere Bereiche wie API oder Cookie-Formate betreffen können, aus denen man sich zwangsweise selbst bedienen muss, wenn der Data Layer nur wenig Hilfestellung bietet.

Ein weiterer Praxis-Test, der sich bewährt hat: Wie gehe ich mit einem Dienst um, der keine Cookies setzt, aber dennoch Consent braucht? Pixel-Tracking über Image-Requests, Fingerprinting-Bibliotheken, Dienste die ausschließlich mit Local Storage oder Session Storage arbeiten, Third-Party-Content in iFrames - all das existiert in freier Wildbahn und eine CMP, die konzeptuell auf "Cookie = Dienst" aufgebaut ist, stößt folgerichtig an ihre Grenzen.

Bedienung: Nicht "welche Features", sondern "wer kann sie nutzen"

Feature-Listen prüfen, ob etwas geht. Sie prüfen nicht, wer es bedienen kann - oder sollte. Das klingt nach einem weichen Kriterium, ist aber im Unternehmensalltag einer der härtesten Faktoren überhaupt. Wenn das Rechts-Team den Text im Consent-Dialog anpassen möchte, weil sich die Rechtslage geändert hat oder ein Audit neue Formulierungen verlangt: Wer kann das umsetzen? Direkt in der CMP-Oberfläche, ohne die IT-Abteilung zu bemühen? Oder ist "Customizing" ein Euphemismus dafür, dass jemand eine JSON-Konfiguration oder ein CSS-File anfassen muss, das dann durch den Deployment-Prozess geschleust wird? Bei manchen Systemen bedeutet "Textänderung im Banner" ein Developer-Ticket, eine Code-Review, ein Deployment. Für einen Satz... dessen vorheriger Zustand im Zweifelsfall auch nachweisbar sein muss. Detailfragen ohne Ende...

Dasselbe gilt für Sprachen. "Unterstützt 65 Sprachen" klingt beeindruckend in der Feature-Matrix. Aber wie sieht der Prozess aus, wenn ich eine neue Sprache hinzufüge? Kann ich Übersetzungen direkt einpflegen oder muss ich ein Support-Ticket beim CMP-Anbieter aufmachen? Müssen alle Dienste je Sprache neu konfiguriert oder eine Änderung nachher 65 Mal eingepflegt werden? Wie funktioniert überhaupt die Spracherkennung - über den Browser, über die URL, über Geolocation? Und was passiert, wenn keine Regel greift: Sehe ich dann kein Banner (schlecht), ein englisches Banner (akzeptabel), eines in Niederländisch (True Story, lustig) oder gar keins und der Consent fällt auf "denied" (mist!)?

Rollenkonzepte sind ein weiterer blinder Fleck. In größeren Organisationen arbeiten unterschiedliche Menschen mit der CMP: Rechtsabteilung, Marketing, IT, externe Agenturen. Die Frage ist nicht, ob es "verschiedene Rollen" gibt (grüner Haken, nächster Punkt), sondern wie granular diese sind. Kann die Rechtsabteilung Texte ändern, ohne versehentlich die DataLayer-Konfiguration zu zerschießen? Kann die Agentur Dienste anlegen, ohne Zugriff auf die Abrechnungsdaten oder Consent Historie der Besucher zu haben? Es geht nicht darum, ob es ein Rollenkonzept gibt, sondern ob es in der Praxis verhindert, dass gut gemeinte Änderungen unbeabsichtigte Nebenwirkungen haben oder man mit jedem externen Dienstleister aus Angst vor der DSGVO reflexartig Verträge abschließen will, die nur Anwälte glücklich machen (frag nicht).

Pricing: Die Kunst der unvergleichbaren Volumen

Dass unterschiedliche Anbieter unterschiedliche Preise haben, überrascht niemanden. Dass die Preise auf völlig unterschiedlichen Metriken basieren und damit praktisch unvergleichbar sind, überrascht wohl kaum.

Der eine Anbieter rechnet nach "Sessions" ab. Was ist eine Session? 30 Minuten Inaktivität als Trennlinie, wie bei Google Analytics? Oder einfach pauschal alle 30 Minuten eine neue? Oder etwas ganz anderes? Werden Bots und Crawler mitgezählt, die auf manchen Websites locker 30-40% des "Traffics" ausmachen, auch wenn diese gar nicht mit der CMP interagieren, sondern einfach nur JavaScript ausführen, weil das heute eben dazu gehört? Der nächste Anbieter rechnet nach "Monthly Active Users". Zählt ein Nutzer, der an fünf Tagen wiederkommt, als einer oder als fünf? Und wie wird ein "User" überhaupt identifiziert, wenn die CMP per Definition erst nach Consent ein Cookie setzen darf? Wieder ein anderer rechnet nach "Consent-Entscheidungen" - also nur Interaktionen mit dem Banner. Das ist vermutlich die fairste Metrik, weil sie wenigstens misst, was die CMP tatsächlich tut. Aber sie macht es unmöglich, die Kosten mit einem Session-basierten Modell zu vergleichen, weil die Zahlen in völlig unterschiedlichen Größenordnungen liegen.

Die eigentliche Herausforderung ist also nicht der Preis pro Einheit, sondern die Schätzung des eigenen Volumens in der jeweiligen Metrik. Und hier wird es haarig. Die meisten Unternehmen kennen ihre Pageviews aus Analytics (wobei diese Zahl ohne Consent ohnehin nur einen Teil der Realität abbildet), aber nicht ihre "Consent-Entscheidungen" oder ihre "MAUs nach CMP-Definition". Also schätzt man. Und der Anbieter hilft gerne bei der Schätzung - mit erstaunlich optimistischen Zahlen, die im ersten Vertragsjahr auch meistens passen. Spätestens im zweiten Jahr, wenn der Traffic gewachsen ist oder sich die Bot-Situation geändert hat oder der Anbieter seine Zählmethodik "optimiert" hat, wird es dann teurer als geplant. Plötzlich wird also Logfile-Analyse wieder hervorgekramt, um Zahlen zu ermitteln. Gute Idee natürlich, aber mit großem Potenzial zur Überschätzung des zu erwartenden Volumens. "Dann lieber den nächst größeren Plan". Klar 😉

Mindestens genauso wichtig wie der Preis selbst: Was passiert bei Überschreitung? Das Spektrum reicht von "das Banner wird ausgeblendet" (was bedeutet, dass kein Besucher mehr zustimmen kann und damit das gesamte Tracking zum Erliegen kommt) über "automatisches Upgrade in die nächste Preisstufe" (willkommen in der Kostenfalle) bis hin zu "wir drücken ein Auge zu und reden im nächsten Quartal darüber" (überraschend häufig bei Enterprise-Verträgen, aber nicht etwas, das man als Planungsgrundlage hernehmen sollte).

Was unter der Haube lauert

Die bisherigen Punkte betreffen den Alltag: Setup, Bedienung, Kosten. Was folgt, ist technischer und betrifft die Architektur der CMP selbst. Nicht jeder, der eine CMP auswählt, muss das alles im Detail verstehen. Aber jemand im Team sollte es. Und die richtigen Fragen im Sales-Prozess stellen zu können, schadet auch dann nicht, wenn man die Antworten nicht bis ins letzte Detail selbst bewerten kann.

Performance: Messen, nicht fühlen

"Unser Script ist leichtgewichtig und SEO-freundlich" steht so oder ähnlich auf jeder zweiten CMP-Website. Nett. Aber was heißt das in Zahlen?

Seit Google die Core Web Vitals als Ranking-Faktor etabliert hat und spätestens seit INP (Interaction to Next Paint) als Metrik dazugekommen ist, lässt sich die Performance einer CMP ziemlich konkret messen. Es geht nicht mehr nur darum, ob das Banner "schnell" erscheint, sondern was passiert, wenn jemand auf "Alle akzeptieren" klickt. Dieser Klick löst eine Kaskade aus: Consent wird gespeichert, Consent Mode Signale werden gesetzt, der DataLayer bekommt seine Events, Tags feuern, externe Scripts werden nachgeladen. All das passiert im selben Moment, auf demselben Main Thread des Browsers. Und wenn die CMP dabei nicht sauber mitspielt, blockiert sie den Thread so lange, dass der Browser die visuelle Rückmeldung (Banner verschwindet, Seite reagiert wieder) spürbar verzögert. Das ist dann ein schlechter INP-Wert - und den misst Google bei echten Nutzern, nicht im Labor.

Interessanterweise gibt es hier einen architektonischen Unterschied, der selten diskutiert wird: Manche CMPs rendern ihr Banner in einem iFrame, andere direkt im DOM der Seite oder im Shadow DOM. Die iFrame-Variante isoliert die Interaktion vom Rest der Seite, was in Tests zu dramatisch besseren INP-Werten führt (einstellige Millisekunden vs. dreistellige). Das heißt nicht, dass iFrame automatisch immer besser ist - es gibt gute Gründe für DOM-basierte Banner, etwa barrierefreie Bedienung oder komplexe Styling-Anforderungen. Aber es heißt, dass die Architektur-Entscheidung des Anbieters direkte, messbare Auswirkungen auf die Web-Performance hat.

Und dann ist da noch ein ein Detail: Was wird eigentlich gemessen, wenn die CMP aktiv ist vs. wenn sie es nicht ist? Für wiederkehrende Besucher, die bereits zugestimmt haben, wird kein Banner angezeigt. Aber die Consent-Prüfung und das Setzen der Consent-Mode-Signale passiert trotzdem. Bei Erstbesuchern dagegen blockiert das Banner potenziell die Interaktion mit der eigentlichen Seite. Performance-Tests, die nur den "Banner schon weg"-Zustand messen, erzählen also bestenfalls die halbe Geschichte.

DebugBear und SpeedCurve haben hier unabhängig voneinander ziemlich ernüchternde Analysen veröffentlicht, die man sich geben sollte, wenn Performance ein Thema ist. Und, seien wir ehrlich: Wenn man mit Google Ads arbeitet, ist Performance immer ein Thema. Das weiß, wer morgens in die Search Console schaut und sieht, was Core Web Vitals mit dem eigenen Quality Score anstellen.

TCF-Payload: Wo landet der Consent-String?

Dieser Punkt ist nur für diejenigen relevant, die das IAB Transparency & Consent Framework nutzen - also vor allem Publisher mit programmatischer Werbung und Shops mit umfangreichen Vendor-Listen. Wer "nur" Google Ads und Analytics braucht, kann getrost weiterspringen zum nächsten Punkt.

Das TCF erzeugt bei jeder Consent-Entscheidung einen sogenannten tcString: eine Base64-kodierte Zeichenkette, die für jeden einzelnen Vendor und jeden Zweck den Consent-Status enthält. Bei überschaubaren Vendor-Listen (20-30 Partner) ist das ein paar hundert Bytes, kein Problem. Bei großen Publisher-Setups mit 400+ Vendoren wird dieser String allerdings... üppig. Und hier wird die Implementierung der CMP relevant. Dummerweise sind es gerade die auf TCF "angewiesenen" Publisher, die selten nur "ein paar Einträge" in dieser Liste haben. Das Problem ist also u. U. nennenswert, wenn man zu den Sites gehört, die Ghostery glühen lassen beim Aufruf.

Die entscheidende Frage: Wo speichert die CMP diesen String? In einem First-Party-Cookie oder im localStorage des Browsers?

Die Unterscheidung klingt kleinlich, ist aber potenziell mit echtem Impact ausgestattet. First-Party-Cookies werden vom Browser bei jedem einzelnen HTTP-Request an den Server mitgeschickt. Bei jedem Bild, jedem API-Call, jedem Font-Download. Wenn der TCF-String im Cookie liegt und mehrere Kilobyte groß ist, bläht er jeden Request auf. Da eine Seite (wir reden von Publishern!) oft mehrere 100 Requests für den Aufbau braucht, addiert sich das dramatisch. Server und CDNs haben Limits für HTTP-Header-Größen (meistens irgendwo bei 8 KB), und wenn der aufgeblähte Cookie-Header diese Grenze überschreitet, antwortet der Server mit einem HTTP 431 "Request Header Fields Too Large". Die Website geht in die Knie - nicht weil irgendjemand etwas am Code geändert hat, sondern weil die CMP ihren Consent-String an die falsche Stelle geschrieben hat. Passiert dies nicht, ist nur eine ganze Menge TCF-Cookie-Inhalt massenhaft durch die Gegend (und freilich auch wieder an uns selbst) geschickt worden und nur 2% der Empfänger interessiert sich dafür. CO2-neutral wird man da nur noch durch Kauf von Ablassbriefen bei der Kirche der grünwaschenden Madonna.

Die bessere Option: localStorage. Daten im localStorage werden nicht automatisch an den Server gesendet. Tags, die den TCF-String brauchen (Header-Bidding, Programmatic), fragen ihn lokal über die standardisierte __tcfapi JavaScript-API ab. Kein aufgeblähter Header, keine 431-Fehler, keine Server-Probleme. Die CMP liefert den String gezielt an die Tags aus, die ihn brauchen, ohne den Rest der Website-Kommunikation damit zu belasten.

Die Alternative ist das Risiko echter Ausfälle, die manchmal Tage gedauert haben, bis deren Ursache gefunden wurde - weil niemand auf dem Schirm hatte, dass ein zu großer Cookie die Server-Infrastruktur irgendwann lahmlegen kann.

Cross-Domain Consent: Das Versprechen, das der Browser nicht halten kann

"Einmaliges Opt-in über alle Ihre Domains hinweg." Klingt fantastisch, besonders für Unternehmen mit mehreren Marken, Shops oder Länder-Domains. Man stimmt einmal zu und der Consent gilt überall. Man ahnt es schon: So einfach ist es in der harten modernen Browserlandschaft leider nicht.

Cross-Domain Consent Sharing funktioniert in der Regel über "Linking per URL Parameter", Third-Party-Cookies oder localStorage-Workarounds in unsichtbaren iFrames. Und genau hier hat Apple (und in zunehmendem Maße auch Firefox) einen ziemlich dicken Strich durch die Rechnung gemacht. Die Intelligent Tracking Prevention (ITP) in WebKit (der Browser-Engine, die auf jedem iOS-Gerät erzwungen wird, egal ob Safari, Chrome oder Firefox draufsteht) blockiert genau diese Mechanismen. Auch andere Browser haben je nach Einstellungen zum Datenschutzniveau und/oder installierten Plugins aktiv etwas dagegen. Abschneiden von Parametern, verweigerte oder partitionierte Cookies und Browserspeicher... es gibt viele Wege, hier Ärger zu machen.

Was bedeutet das in der Praxis? Auf iOS-Geräten (je nach Markt gern bis zu 50% des Traffics) funktioniert Cross-Domain Consent schlichtweg nicht. Nutzer werden auf jeder Domain erneut nach ihrer Zustimmung gefragt, unabhängig davon, was sie auf der Schwester-Domain gerade erst bestätigt haben. Der schicke Name dafür ist "Consent Loop" - und er ist nicht nur nervig für den Nutzer, sondern kann die Consent-Rate auf Subdomains signifikant drücken, weil Menschen irgendwann entnervt auf "Ablehnen" klicken, wenn sie zum fünften Mal gefragt werden.

Manche Anbieter kommunizieren das in ihren Entwickler-Docs auch durchaus ehrlich - allerdings im Kleingedruckten, das man erst findet, wenn man explizit nach ITP-Limitierungen sucht. Damit ist das ganze Cross-Domain-Consent Thema immer wackelig und lückenhaft. Die Situation wird auch nicht mehr besser, sondern nur schwieriger. Was dazu führt, dass im "schlimmsten" Fall sogar vielleicht mit Fingerprinting im Browser und Hashtables beim CMP Anbieter gearbeitet wird, alles im Namen des Datenschutzes. Wer findet den Fehler?

Letzter Wermutstropfen: Nicht alle CMPs verwalten Consent im Kontext der Domain und nicht des Hosts. Wer also shop.meinladen.de und www.meinladen.de betreibt, muss sich unabhängig von funktionierendem Cross Domain Tracking genau ansehen, ob die CMP ein Cookie für .meinladen.de setzt oder unterschiedliche Cookies für jeden Host entstehen. Habe ich schon mehrfach gesehen und in einem der Fälle lässt sich der Anbieter den Consent dann pro Host bezahlen. Schändlich, unnötig und rein finanziell motiviert: sowas muss man mögen.

Selbst wenn das Cookie für alle Hosts der Domain gesetzt wird, ist immer noch nicht garantiert, dass man beim Wechsel des Hosts nicht doch nochmal gefragt wird. Der Grund ist dann vielleicht der verschärfte Trackingschutz im Browser, der nicht auf die billige CNAME Weiterleitung für shop.meinladen.de reinfällt und eine eigene Version des Cookies dort erzeugt. Richtig geraten: leider erst nach Einblendung des Banners und erneuter Entscheidung.

GPC: Das Signal, das immer mehr Gewicht bekommt

Global Privacy Control ist ein vergleichsweise neuer Standard, bei dem der Browser über einen HTTP-Header (Sec-GPC: 1) oder eine JavaScript-API (navigator.globalPrivacyControl) signalisiert, dass der Nutzer keine Weitergabe oder keinen Verkauf seiner Daten wünscht. In Kalifornien hat GPC bereits Einzug in die "dortige DSGVO" namens CCPA/CPRA gehalten. Natürlich diskutiert auch die europäische Diskussion darüber, inwieweit Browser-Signale als rechtsgültiger Opt-Out zu werten sind... wie man ja gern allesmögliche im Kontext Datenschutz sauber durchspricht, bevor man es an der Praxis vorbei zur Entscheidung treibt.

Für die CMP-Auswahl bedeutet das: Unterstützt das Tool GPC? Und wenn ja, was genau tut es damit? Wird der Consent-Dialog angepasst, wenn GPC erkannt wird? Werden bestimmte Kategorien automatisch auf "abgelehnt" gesetzt? Oder wird das Signal schlicht ignoriert? Und ist das Thema relevant für mich?

Je nach der Audience der eigenen Website wird Ignoranz sonst zunehmend zum Compliance-Risiko. Browser wie Firefox und Brave haben GPC standardmäßig aktiviert, und der Anteil der Nutzer mit aktivem GPC-Signal wächst. Wer heute eine CMP anschafft, die GPC nicht erkennt, kauft sich potenziell ein Problem für morgen.

Die unbequemen Wahrheiten

Was bisher kam, lässt sich im Sales-Prozess noch einigermaßen abfragen. Die folgenden Punkte sind (leider) anders. Sie betreffen Dinge, die gern erst nach Monaten oder Jahren sichtbar werden und daher im Vertriebsgespräch kein Thema sind. Ich kann hier daher nur aus Leidensgeschichten meiner Kunden und Erfahrungen aus dritter Hand berichten. Aber das macht die Probleme nicht weniger real.

Silent Breakage: Wenn sich unter dir der Boden bewegt

Es gibt eine besonders perfide Art von Problem: Etwas geht kaputt, ohne dass irgendjemand irgendetwas geändert hat. Kein Deployment, kein neues Tag, kein Update am eigenen Code. Trotzdem bricht über Nacht das Tracking ein, Tags feuern nicht mehr, Consent-Kategorien verhalten sich anders als gestern. Willkommen in der Welt der stillen Änderungen, die an vielen Stellen lauern können.

CMPs pflegen z. B. oft interne Datenbanken mit vordefinierten Diensten, Cookie-Zuordnungen, Vendor-Listen. Diese Datenbanken werden aktualisiert - manchmal durch automatische Synchronisation mit der IAB Global Vendor List, manchmal durch den CMP-Anbieter selbst, der seine Templates "verbessert" oder die Knowledge Base ausbaut. Was das in der Praxis bedeutet: Ein Vendor ändert seine ID in der globalen Liste, die CMP übernimmt das automatisch, der Consent für diesen Vendor steht plötzlich auf "Denied", weil die alte ID nicht mehr existiert.

Klingt zu unwahrscheinlich? Dann überzeugt vielleicht dieser Fall, den ich vor allem da erlebt habe, wo die Kommunikation zwischen CMP und Datenschicht suboptimal ist: der Anbieter ändert das Cookie-Format, in dem er Consent-Entscheidungen speichert, und plötzlich funktioniert das Custom HTML Tag nicht mehr, das dieses Cookie ausliest, weil man eben mit dem DataLayer gar nichts (oder nicht alles) bekommt, was man braucht. Ergebnis ist auch hier, dass Tags vergeblich auf einen Startschuss warten und nicht mehr ausgeführt werden.

Noch ein Horrorthema, was nicht unbedingt jeden betrifft, aber schon bei weit verbreiteten CMPs massive Probleme verursacht hat, die erst dann auffallen, wenn man ein Loch in den Daten bemerkt oder die Conversions im Ads Konto ausbleiben: Die API ändert sich. Es ist erstaunlich, wie wenig Wert manche Anbieter dabei auf Abwärtskompatibilität legen. Man stellt eine API bereit, veröffentlicht irgendwo eine neue Doku, sendet vielleicht sogar einen Newsletter rum, in dem das Thema eines von fünf Punkten ist und wundert sich, warum nicht jeder Nutzer seine an die API angebundenen Lösungen rechtzeitig umgestellt hat und nun den Support belästigt. Auch dieses Detail habe ich mir nicht ausgedacht, sondern gemeinsam mit einem Kunden durchlebt, bei einer namhaften CMP.

Ähnlich blöd wie umbenannte oder in der Struktur der Werte geänderte Cookies sind DataLayer-Events, die plötzlich anders heißen als vorher. Auch das ist leider mit eigenen Erfahrungen zu untermauern. Es passiert nicht oft und nicht bei jeder CMP. Wenn es aber Deine Website trifft, ist das ein schwacher Trost.

Das Audit-Trail-Märchen

Jeder CMP-Anbieter führt gern ein ganz besonderes Argument an: die serverseitige Speicherung der Consent-Historie beim CMP Anbieter sei unverzichtbar. Compliance, Nachweispflicht, behördliche Anfragen - ohne den Audit-Trail auf dem Server ist man aufgeschmissen. Das klingt einleuchtend. Und es ist das Argument, mit dem sich oft das ganze Geschäftsmodell rechtfertigt: Ohne Server-Komponente kein Anbieter, ohne Anbieter kein Abo, ohne Abo kein Umsatz, denn was bleibt ist "ein Stück JavaScript" und ein Dialog. Daher gibt es ja auch Consent Lösungen, die nicht nur selbst gehostet werden, sondern die die Zustimmung und die Historie der Zustimmungen im Browser speichern. Ohne den Unterschied rechtlich verbindlich beurteilen zu können, erscheint mir aus rein technischer Sicht das Delta sehr sehr gering.

Schauen wir auf die Details, wie eine irgendwo außerhalb des Browsers gespeicherte Historie funktioniert. Die CMP erzeugt bei jeder Consent-Entscheidung "irgendwo" einen Datensatz. Darin stecken z. B. Zeitstempel, gewählte Kategorien oder Tools, Banner-Version, vielleicht eine Geräte-Kennung. Dieser Datensatz wird auf dem Server des Anbieters oder dem Webserver der besuchten Site (wenn man z. B. das eine oder andere Plugin für typische CMS verwendet) gespeichert und mit einer Referenz verknüpft. Das ist typischerweise ein Hash oder eine ID, die als Cookie oder ggf. auch exklusiv oder redundant im localStorage im Browser des Nutzers wohnt. Wenn die Datenschutzbehörde fragt "Hat Nutzer X am Tag Y zugestimmt?" oder der Nutzer selbst Fragen zu seinen Daten und deren rechtmäßiger Erhebung hat, kann man den Server-Datensatz über die Cookie-ID dem Nutzer zuordnen und den Nachweis führen.

Nur: Wie lange lebt dieses Cookie denn typischerweise? In Safari unter ITP werden First-Party-Cookies, die per JavaScript gesetzt wurden, je nach Szenario nach einem Tag oder spätestens 7 "browseraktiven" Tagen ohne Erneuerung durch Besuch auf der gleichen Website gekappt. Oder der Nutzer löscht seine Cookies, der Browser wird dauerhaft gewechselt oder das Gerät getauscht. In all diesen Fällen ist die Referenz im Browser weg, aber der Datensatz auf dem Server bleibt. Für immer. Ohne lebendiges Gegenstück in der freien Wildbahn und eine faire Chance, jemals bei der Beantwortung einer Frage Hilfreiches beizusteuern. Technisch gesehen also wäre die Historie direkt im Browser, die vermutlich die Lebensdauer des Referenz-Cookies mit den aktuellen Entscheidungen im Browser ebenso teilt wie dessen Ende, einer armen, verwaisten Zeile in einer Datenbank jederzeit vorzuziehen. Wie gesagt: ich bin kein Anwalt und kann nicht darüber entscheiden, ob eine serverseitige Komponente wirklich in den Buchstaben der Gesetzgebung als harte Anforderung zu finden ist. Aber Methoden zur Härtung des Consent Cookies sind sicher eine gute Idee, wenn man dem CMP Anbieter Geld dafür gibt, diese ganzen Karteileichen bis zum Tag x (Aufbewahrungsfristen hierfür? Keinen Schimmer) durchzufüttern mit Speicherplatz und CO2.

Ich nenne das dennoch gern "Hashtables des Todes". Zu 96% (konservativ geschätzt ;)) sind die Consent-Records auf den Servern der CMP-Anbieter tote Einträge. Der Hash existiert noch in der Datenbank, aber das Cookie, das als Schlüssel diente, ist längst der natürlichen Vergänglichkeit aller Browser-Persistenz zum Opfer gefallen. Diese Records sind nicht löschbar (weil man nicht wissen kann, ob der Nutzer nicht doch wiederkommt), nicht zuordenbar (weil das Gegenstück fehlt) und damit auch vermutlich nicht gerichtsfest, wie es verkauft wird. Das als zentrale Daseinsberechtigung von CMPs erscheint mir dünn. Aber sei's drum: irgendwo muss die Historie gespeichert werden. Daher nun...

Dark Patterns: Wenn das Tool es zu leicht macht

Es gibt CMPs, die bieten A/B-Testing für Consent-Banner an. Verschiedene Texte, verschiedene Farben, verschiedene Button-Anordnungen - alles mit dem Ziel, die "Consent Rate" zu optimieren. Das ist auch ein m. E. sehr sinnvolles Feature, denn man kennt Studien und Case-Studies zuhauf, bei denen enorme Uplifts erzielt wurden.

Das Problem beginnt dort, wo man ggf. zu viele Freiheiten hat, ohne wenigstens eine Warnung aktiv ignorieren zu müssen, bevor man den "Ablehnen"-Button aus dem ersten Layer verbannt und hinter einen Klick auf "Einstellungen" oder was auch immer verschiebt. Es gibt sicher Handlungspielraum in optischer Gestaltung, der evtl. mit Blick auf Risikomanagement oder Kosten/Nutzen abgewogen werden kann, aber einige Aspekte haben sich inzwischen als klare Anforderungen herauskristallisiert, zu denen Bußgelder drohen. Auch bei Erhalt des Buttons kann man schnell in "Dark Patterns" abgleiten, wenn man das mit ein paar Klicks im CMP Backend mit einem guten Gefühl macht. Denn warum sonst gibt es diese Option oder jedes Template? Auch ohne Bußgeld fällt eine Menge Aufwand und interner Kosten an, wenn man einmal in den Briefwechsel mit der zuständigen Datenschutzaufsichtsbehörde genötigt wird.

Für die CMP-Auswahl stellt sich daher die Frage: Macht es das Tool einfach, Dark Patterns zu implementieren? Und gibt es Leitplanken, die das verhindern? Ein Tool, das in seiner Default-Konfiguration den Ablehnen-Button in der gleichen Größe und Prominenz wie den Akzeptieren-Button anbietet, sendet ein anderes Signal als eines, das im Standard bereits mit asymmetrischen Buttons daherkommt und die "gleichwertige Alternative" erst über Konfiguration freigeschaltet werden muss.

Exit-Strategie: Was passiert, wenn man gehen will

Es gibt vielschichtige Gründe, warum man eine CMP wechseln will. Im einfachsten Fall hatte man seit 2018 irgendein Plugin, das irgendwas gemacht hat und ist damit bisher gut gefahren. Bis dann Datenschutzanforderungen von innen oder außen in den Fokus gerückt werden, das eigene Ads Konto plötzlich steht oder man dem Druck steigender Kosten gern mit einem Wechsel begegnen will. Vielleicht ist auch die Zusammenarbeit mit dem CMP Anbieter mit zu viel Supportaufwand verbunden, die API zu unzuverlässig... ich habe jeden der genannten Gründe und daraus folgenden Wechsel schon von außen begleiten "dürfen".

Was passiert in einem solchen Fall mit allem, was man in den Monaten oder Jahren der Nutzung im alten Tool aufgebaut hat?

• Umfangreiche Tracking Setups
• Integrationen von zustimmungspflichtigen Inhalten auf der eigenen Website
• Individuelle Konfigurationen von Diensten
• Mit Legal abgestimmte Texte in 12 Sprachen
• Kategorien, die an das eigene Rechtsverständnis angepasst sind
• Design- und Template-Anpassungen
• API-Integrationen
• Reporting zu Consent Raten

Vieles davon ist direkt oder indirekt mit dem Backend des Anbieters verknüpft. Aber wie nimmt man es mit? Die traurige Antwort lautet "manuell" oder "gar nicht". Es gibt kein Standard-Exportformat für CMP-Konfigurationen, also fängt man in vielen Belangen von vorn an (oder muss Dinge parallel neu aufbauen, um den Switch vorzubereiten).

Das größte Problem ist dabei vermutlich die Consent-Historie beim alten Anbieter. Die (aus den im vorigen Abschnitt dargelegten Gründen überwiegend toten) Datensätze müssen portiert (wenn man überhaupt dran kommt) oder weiter dort aufbewahrt werden, denn man muss ja Auskunft geben können. Wie lange werden die nach Vertragsende aufbewahrt und zu welchen Kosten?

Manche Anbieter machen den Wechsel erträglicher und bieten an, den Consent-Status des alten Systems zu importieren, sodass wiederkehrende Besucher nicht erneut gefragt werden. Das ist technisch möglich (das Cookie des alten Systems ist ja noch da, zumindest bei manchen Besuchern). Aber das ist kein Standard und es ist nichts, worauf man sich verlassen kann, ohne es vertraglich fixiert zu haben - und meistens muss man es auch bezahlen; im schlimmsten Fall auf beiden Seiten.

Speziell die Phase des Übergangs kann auch ungeachtet der Historie ein Problem sein. Wo z. B. ein Scanner die primäre Quelle zur Bestückung des neuen Tools ist, das erst dann eingesetzt werden kann, wenn alle Dienste konfiguriert sind, mag man in eine tödliche Spirale geraten. Ich erlebe dies gerade bei einem Kunden, wo von einem renommierten Anbieter zum nächsten gewechselt werden soll. Der glückliche neue CMP Anbieter hat einen Scanner, der aber leider keine Cookies mitbringen kann für den Scan einer Seite, auf dem er aber Cookies braucht, damit die alte CMP alle Dienste ausspielt, die es zu erkennen gibt. Seit geraumer Zeit spielen nun Kunde, Anbieter A und Anbieter B sich die Bälle gegenseitig zu. Es werden IP Adressen an die IT gesendet, Parameter beim Aufruf durch den Scanner erprobt und verworfen und am Ende wird man an einen Punkt gelangen, an dem 90% der Website gecrawlt sind und man alles gefunden hat, was ausgespielt wird. Bis auf die Conversion-Tags, die hinter Formularen oder einem aufgelösten Warenkorb lauern. Nur wenige Scanner sind so flexibel konfigurierbar, dass man sie mit der passenden Konfiguration und Nutzlast auf wirklich alle relevanten Seiten einer Domain senden kann. In diesem Fall warte ich gespannt, wie es weiter geht.

Die Checkliste

Wer bis hierher durchgehalten hat: Respekt. Das war viel Text und viel Detail. Aber genau das ist der Punkt - die Realität einer CMP-Auswahl lässt sich nicht in zehn Bulletpoints pressen, ohne dabei alles wegzulassen, was nachher wirklich zählt.

Trotzdem: Hier ist der Versuch einer Destillation. Die folgenden Fragen sind das Konzentrat aus allem, was oben steht. Sie taugen als Fragenkatalog für den Sales-Prozess, als Checkliste für die interne Bewertung oder als Grundlage für ein Gespräch mit dem Dienstleister, der die Implementierung begleiten soll. Nicht alle Fragen sind für jedes Setup gleich relevant - aber jede einzelne hat ihren Ursprung in einem realen Problem, das irgendwann irgendwo aufgetreten ist. Was genau für Deinen Anwendungsfall relevant ist, kannst Du mit den Details der knappen zwei Meter Text oberhalb auf jeden Fall sicher recht gut einschätzen.

Schlusswort

Diese Liste ist nicht vollständig. Sie kann es nicht sein, denn jedes Setup ist anders und jede Organisation hat eigene Prioritäten. Was für einen Publisher mit 500 Vendoren und TCF existenziell ist, spielt für einen mittelständischen Online-Shop mit drei Tracking-Tags und einem Kontaktformular keine Rolle. Und umgekehrt.

Was diese Liste aber hoffentlich zeigt: Die Fragen, die wirklich über die Alltagstauglichkeit einer CMP entscheiden, stehen in keiner Hochglanz-Broschüre und werden in keinem Webinar beantwortet. Sie entstehen aus Erfahrung, aus Fehlern und aus dem Moment, in dem man zum dritten Mal um 22 Uhr vor dem Rechner sitzt und versucht herauszufinden, warum seit gestern keine Conversions mehr reinkommen, obwohl man selbst absolut nichts geändert hat.

Merke: Wer die richtigen Fragen stellt, bekommt hilfreichere Antworten. Oder zumindest ein aufschlussreiches Schweigen 🙂 Ich kann nur viel Erfolg wünschen, wenn Du gerade eine solche Migration vor Dir hast und ich hoffe, diese sehr sehr sehr ausführliche Gebrauchsanweisung der "etwas anderen CMP Checkliste" erlaubt Dir eine informierte Entscheidung. Denn darum geht es schlussendlich ja auch beim Consent Management!