Consent Mode Features im Google Tag Manager zur Trigger-Reduktion nutzen?

Es gibt auch noch Jahre nach der Einführung einige Verwirrung  um die "Consent Mode" Einstellungen im Google Tag Manager. Meine Abneigung gegen den Consent Mode ist primär dadurch geprägt, dass seine Kernaufgabe meinen Vorstellungen von korrektem Verhalten bei fehlender Zustimmung widerspricht. Diese besteht in der Steuerung des Verhaltens von Google Analytics, Ads und Floodlight, wenn kein Consent besteht und bedeutet vereinfacht, Google ohne Cookies dennoch lustig Daten sammeln zu lassen. Das finde ich aus mehreren Gründen nicht OK.

Die Funktionen, die der Google Tag Manager zur Verwendung des Consent Mode beinhaltet, sind aber etwas anderes und haben nur bedingt damit zu tun, Tags auch ohne Zustimmung auszulösen. Mit einer sauberen Implementierung kann man damit den o. a. "Kernnutzen" außer Kraft setzen, wenn das den eigenen Vorstellungen entspricht, und sich ausschließlich auf das Triggern beschränken - bzw. das Einschränken der Auslösung von Tags, wenn keine Zustimmung besteht. Damit wird die Consent Mode Implementierung im GTM zu einem zusätzlichen Weg, das Auslösen von Tags - aller Art(!) -  zu steuern, ohne die übliche Multiplikation von Triggern gegenüber dem Betrieb ohne Consent-Bedingungen mit sich zu bringen. Auf diesen Ansatz konzentriert sich dieser Beitrag... oder - wer es lieber mag - auch das dazu passende Video bei Youtube zum Consent Mode im GTM.

Was gehört zum Consent Mode im GTM?

Schon vor der hier beschriebenen Übersicht existierte bereits bei jedem Tag ein Block mit entsprechenden Einstellungen. Während man die Übersicht vormals in den Einstellungen des Containers unter "Verwaltung - Containereinstellungen - Weitere Einstellungen" die Option „Einwilligungsübersicht“ einschalten musste, ist diese nun stets sichtbar und der Tipp lautet daher eher (siehe oben), die Funktion an dieser Stelle stattdessen auszuschalten, um den Features so wenig Aufmerksamkeit wie möglich zu geben, wenn man sich für einen besseren Weg entschieden hat, sein Trigger-Konzept aufzubauen.

"Eigene" Trigger

Es gibt zwei Trigger, die noch vor gtm.js stattfinden. Diese können zur Initialisierung oder dem Laden eines Consent Tools genutzt werden... und zur evtl. noch davor stattfindenden Ausspielung von Consent Mode "default" Einstellungen, um das generelle Verhalten zu definieren, bevor ein Consent Tool diese ggf. anhand bestehender Besucherauswahl mit einem "update" verändert - oder eben die üblichen Events im dataLayer stattfinden, mit denen die Ausführung von Tags üblicherweise gesteuert wird. Das Problem in der Praxis hierbei ist allerdings, dass dies eine Kontrolle darüber vorspiegelt, was in welcher Reihenfolge stattfindet. In einem asynchronen Umfeld wie hier ist aber die Reihenfolge des "Starts" bzw. Laden eines Tags nicht maßgeblich dafür verantwortlich, in welcher Reihenfolge Dinge wirklich ausgeführt werden oder gar fertig sind. Ein früher Triggerzeitpunkt allein entscheidet also nicht darüber, ob eine CMP wirklich schon "da" oder der Consent Mode fertig mit default initialisiert oder gar per update aktualisiert ist, wenn danach Tags beim Seitenladevorgang anhand von Ereignissen ausgeführt werden, die der Tag Manager als gtm.js, gtm.dom und gtm.load bereitstellt.

Consent Einstellungen für Tags

Jedes Tag kann in den erweiterten Einstellungen mit einem Consent Setup versehen werden. Per Vorgabe ist dies bei allen Tags undefiniert. Die Einstellung kann aber explizit so vorgenommen werden, dass keine weiteren Zustimmungen erforderlich sind... oder eben konkrete Consent Mode-Settings:

Neben den bekannten Einträgen zur Steuerung von Cookies für Ads und Analytics sind "Gruppenzustimmungen" zu finden, die man nutzen kann, um Consent-Einstellungen aus einem Tool hierher zu übernehmen. Was vollkommen unklar bleibt, die unten beschriebenen Möglichkeiten zur kompletten Steuerung aller Tags aber überhaupt erst eröffnet: Man kann hier auch beliebige eigene Zeichenketten definieren, um diese je nach "denied" oder "granted" zu verwenden - genauso wie die bekannten / von Google erzeugten und unterstützten Vorgaben aus der Auswahlliste.

Sammelbearbeitung

Wer mehr als nur ein paar Tags mit Consent-Einstellungen versehen will, kann das nach der Aktivierung in den Containereinstellungen sichtbare "Consent Mode"-Symbol verwenden, um eine Übersicht einzublenden und die aktuell definierten Consent Mode Anforderungen aller Tags einzusehen oder anzupassen.

API für Custom Templates

Es existiert auch eine API zum Setzen und Auslesen von Consent Einstellungen. Aus Sicht des GTM-Anwenders ist dieser Punkt nur aus einem Grund wichtig: Man kann sich damit theoretisch eine eigene Lösung zur Verwaltung von Consent-Vorgaben und Updates der Einstellungen bauen, wie es hier im Beispiel mit Hilfe von HTML-Tags passiert. Um es aber nicht zu komplex zu machen, verzichten wir (erst einmal) auf Custom Templates, welche es aber inzwischen zahlreich gibt. Wo eine CMP eingesetzt wird, die sich nicht selbst um den Consent Mode kümmert, hat sich die Vorlage von Simo Ahava als Standard etabliert.

Wie kommt mit diesen Anpassungen nun der Consent Mode in ein bestehendes Setup?

Consent Mode für beliebige Consent Manager im GTM nutzen

Man kann mit diesen Mitteln Consent-Einstellungen eines bestehenden Consent Tools wie One Trust, CookieBot, Usercentrics, Borlabs & Co. mit einer überschaubaren Menge an Code in Consent Mode Einstellungen übersetzen. Damit ist die Ausführung von Tags zu steuern, ohne die übliche Masse an blockierenden oder ausführenden Triggern zu erstellen, die mit Anzahl der verbauten Tags und Granularität von Consent schnell ansteigt. Der eigene Code ist dabei zumindest solange erforderlich, bis die Consent Tool Anbieter die neuen Optionen nativ unterstützen. Das macht es etwas - aber nicht viel - aufwändiger.

So hilft der Consent Mode im GTM also theoretisch dabei, die Komplexität des Setups zu verringern, wenn Consent im Spiel ist. Wer GA4 Tags bei fehlender Zustimmung nicht dennoch feuern und nur auf Cookies verzichten, sondern das Ausspielen komplett verhindern will, kann das mit einem "Custom Consent" auch für GA Tags erzielen. So ist sämtliches Tracking an die Leine zu nehmen.

Warum Consent normalerweise viele Trigger erfordert (und was das bedeutet)

Ein "einfaches" E-Commerce-GTM Setup mit einer Handvoll Tags für...

• Google Analytics (Seitenaufruf, ggf. ein paar E-Commerce- und / oder andere Events für Downloads, Klicks auf Maillinks etc),
• Facebook (Pageview, einige Lead-Events und E-Commerce)
• Google Ads (Remarketing auf allen Seiten, Conversion bei Kaufabschluss)

... kommt, wenn man Consent aus dem Spiel lässt, normalerweise mit wenigen Triggern aus.

• Ein Trigger für die Seitenaufrufe; ggf. ein weiterer für spätere Events wie DOM Ready
• Trigger für E-Commerce-Events - entweder für mehrere Events gemeinsam oder je Event ein Trigger
• ggf. ein paar Klick-Trigger

Kommt nun Consent ins Spiel, können Trigger wie ein Seitenaufruf nicht mehr einfach verwendet werden, um Google Analytics Pageviews, Facebook Basis Pixel Aufrufe und das Remarketing für Google Ads auf allen Seiten zu triggern. Das gleiche gilt für Transaktionen oder E-Commerce-Aktionen wie "add_to_cart" oder andere, die nicht nur an GA, sondern ebenfalls an FB gesendet werden sollen.

Baut man auf einen Ansatz, der individuelle Trigger für die jeweilige Kombination aus Ereignis (z. B. "Seitenaufruf") und Dienst (wie "Facebook Pixel" oder "Google Ads") erfordert, wird für alle Events, die bisher mehr als einen Dienst / mehr als ein Tag auslösen, eine Vervielfachung der Trigger geschehen. Entweder durch Kopien des Ursprungs-Triggers, der weitere Bedingungen des Consent aus einem Cookie liest oder durch Verwendung von Trigger-Gruppen. So oder so werden selbst bei den genannten drei Diensten aus 5 bis 10 Triggern "ohne Consent" schnell 25 oder mehr Trigger. Mit jedem weiteren Dienst steigt diese Anzahl an. Wer also noch MS Ads, LinkedIn, Pinterest, Criteo, AWIN und sonstwas verbaut hat, versinkt schnell in Triggern.

Alternativ können blockierende Trigger verwendet werden, die dafür sorgen (sollen), dass bestimmte Tags nicht gefeuert werden, wenn dafür keine Zustimmung besteht. Damit entstehen etwas weniger zusätzliche Trigger, da man im Idealfall für jeden Dienst nur einen benötigt und diesen dann bei allen mit dem Dienst verbundenen Tags als Ausschluss definiert, wenn die Consent-Bedingung nicht gegeben ist. Auf der Nachteil Seite stehen bei dieser etwas sparsameren Methode ein paar weitere Nachteile:

1. sogenannte "Race Conditions" sind hier in vielen Fällen noch wahrscheinlicher - und problematischer. Der Begriff umschreibt die Situation, in der der tatsächliche Ablauf wie die Reihenfolge von Events im dataLayer von der geplanten / erforderlichen Sequenz abweicht. Das kann im Einzelfall dumme Folgen haben: Ein Tag soll gefeuert werden, ein blockierender Trigger kann noch nicht auf die erforderlichen Consent-Bedingungen zugreifen und feuert so ggf. je nach Gestaltung Tracking-Hits ab, die eigentlich nicht gesendet werden dürfen. Das ist nicht das einzige, aber ein besonders kritisches Szenario, das gerade dann entsteht, wenn Ausnahme-Trigger für asynchron agierende Tags auf unberechenbare Antwortzeiten von beteiligten Diensten wie dem eigenen Server, der Consent Plattform und dem Trackingdienst stoßen. Daher setzt ein stabiles Setup ohnehin nicht auf Ereignisse wie "Container geladen"; sondern muss ohnehin auf die CMP warten, die hoffentlich die Consent Lage in die Datenschicht schreibt, zusammen mit einem Ereignis wie "consent_status" bei Usercentrics.
2. Blockierende Trigger müssen bei so ziemlich allen auftretenden Events berücksichtigt werden. Hat man also viele Dienste und dementsprechend viele Ausnahme-Trigger, kann das je nach Einsatz relevant für die Performance werden, wenn man etwas "immer ausführt, außer es gelten Ausnahmen A bis V"... Dem ist mit einer passenden Trigger-Strategie zu begegnen, aber das hat seine Grenzen. Hierbei aber auf die Consent Mode Features zu setzen, verringert bestenfalls die Anzahl der Trigger, aber behebt nicht das Problem, dass der Consent Mode "fertig" sein muss, wenn ein auslösendes Ereignis stattfindet.

Vereinfacht Consent Mode nun die Kontrolle für Tags?

Einfach ausgedrückt... Nein. Aber er versucht es. Das sieht dann bei einem Tag, das ausgelöst werden soll, ohne dass Zustimmung besteht, so aus:

Das Bild zeigt ein Google Analytics Tag, das "eigentlich" hätte feuern müssen und das per Consent Mode daran gehindert wurde. Alle Bedingungen des ausführenden Triggers sind erfüllt, es existieren keine blockierenden Trigger... und dennoch wurde das Analytics-Event nicht ausgeführt, weil die in den Consent Einstellungen definierten Anforderungen des Consent Mode nicht erfüllt wurden. Statt neue blockierende Trigger zu nutzen oder die Auslöseregeln komplexer zu gestalten, um Consent zu berücksichtigen, wird also ein weiterer Weg über den Consent Mode angeboten.

Auf der Haben Seite steht: Man muss das eigentliche Verhalten, für das der Consent Mode "gedacht" war, nicht unterstützen, wie das obige Beispiel zeigt. Google Analytics kann man zwar das "Sonderverhalten" der Datensammlung ohne Cookies via Consent Mode erlauben, muss dies aber nicht tun. Stattdessen kann man wie bei allen anderen Tags das Feuern ganz verhindern.

Ein paar Bedingungen sind erforderlich, damit das Tag Verhalten via Consent Mode so gesteuert werden kann, dass man die Einstellungen eines bestehenden Consent Tools verwenden kann. Consent Anbieter übersetzen dazu eine Benutzerauswahl oft zusätzlich optional in (benutzerdefinierte oder [quasi-]standardisierte) Consent Mode Einstellungen. Genauso wie die Auswahl derzeit schon über Cookies, localStorage oder als dataLayer-Wert gespeichert und "kommuniziert" wird, um damit das Tag Management zu steuern, werden zusätzlich im Consent Mode sogar Flags wie "facebook_storage" oder andere kreative Marker eingesetzt. Generell ist aber bei jeder modernen CMP davon auszugehen, dass der Google Consent Mode mit allen Flags (auch ad_user_data und ad_personalization, oft auch Dinge wie functionality_storage etc explizit für den GTM) unterstützt wird und auch die Microsoft-eigenen Varianten für das UET Tag oder Clarity direkt von der CMP passend zur Zustimmung initialisiert werden. Das ist auch der Grund, warum man ohnehin auf die CMP warten muss und daher die Consent Mode Features faktisch nur noch dazu verwenden kann, blockierende Trigger einzusparen.

Schritt 1: Consent Mode Einstellungen definieren

Um den Consent Mode im GTM also statt blockierender Trigger zur Steuerung der Auslieferung zu nutzen, müssen alle Tags, die eine Consent-Abhängigkeit haben, mit entsprechenden Einstellungen versehen werden. Dabei gibt es neben den oben in der Aufzählung der Features im GTM dargestellten Option, die Einstellungen bei jedem Tag einzeln zu definieren, auch eine Übersicht, die über das Symbol oberhalb der Tag-Liste eingeblendet wird.

Dort finden sich alle Tags mit bereits konfigurierten oder unbestimmten Consent-Einstellungen. Die erforderlichen Einwilligungen werden in zwei unterschiedlichen Spalten dargestellt: Den Integrierten Einwilligungen und den Zusätzlichen Einwilligungen.

Die erstgenannten sind der Mist, der bei den Google Tags schon zur Steuerung des Verhaltens ohne Cookies eingebaut ist und der von anderen Anbietern ebenfalls zu erwarten / befürchten ist. Im Sinne dessen, was die ePrivacy-Verordnung will, eigentlich ein klares No-Go. Meinte auch unser Gast Tilman Herbrich in unserer Podcastfolge zum Thema Consent bei beyond pageviews. Vergessen wir das also einstweilen alles; zumindest bis andere Hersteller per API (siehe oben) auf den Zug aufspringen.

Der wirkliche Nutzen steckt in den "Zusätzlichen Einwilligungen". In der folgenden Abbildung rot markiert sind die - frei erfundenen - Zustimmungen zu "facebook" und "google_analytics".

Diese beiden Einwilligungen müssen nun, damit sie von den Tags genutzt werden können, per Consent Mode verwaltet werden.

Schritt 2: Consent Mode Defaults setzen

Wie in der der Anleitung zum Consent Mode von Google beschrieben, setzen wir zu diesem Zweck zunächst einmal Vorgabewerte. Also die Initialisierung der Consent Voreinstellungen. Die nicht nur für ad_storage und analytics_storage vorgenommen werden, sondern zudem wenigstens unsere beiden zusätzlichen und erfundenen "Rechte" umfassen. Per Default soll alles zunächst einmal verboten werden, damit weder Facebook- noch Analytics-Tags ohne Zustimmung feuern. Meint: Nicht nur das im Printscreen noch zu sehende exemplarische E-Commerce-Event für Analytics, sondern alle Analytics Tags werden mit der zusätzlichen Einwilligung google_analytics versehen. Dito facebook für alle FB Tags. Und weitere eindeutige Einwilligungs-Schlüssel für alle anderen Dienste, die ggf. verbaut sind und Consent erfordern. Wir belassen es bei diesen beiden Beispielen.

Damit die Einstellungen da sind, wenn das Tagging los geht, kann und sollte der neue Trigger Consent Initialization (das korrespondierende dataLayer Event heißt "gtm.init_consent") eingesetzt werden, um das Tag zu feuern, das die Einstellungen setzt - jedenfalls so lange, bis das ggf. von integrierten Consent-Tools übernommen wird und gar nicht mehr Aufgabe des GTM ist. Das kann ein fancy eigenes Tag sein, das mit der API-Anbindung des Consent Mode als Custom Template angelegt wurde... oder im einfachsten Fall ein simples Tag vom Typ "Benutzerdefiniertes HTML". Hier ein Beispiel:

Die Initialisierung kann alternativ direkt im Seitenquellcode erfolgen, bevor der GTM (und / oder der Consent-Manager) in die Seiten eingebunden wird. Vorteil GTM (wie so oft): Anpassbarkeit synchron mit den verbauten Tags. Daher ist das i. d. R. die bessere Option.

Schritt 3: Consent-Tool-Einstellungen verwenden

Sind die Consent Einstellungen definiert und alles pessimistisch (wie es sein sollte) erst einmal auf "denied" gestellt und haben die FB- und GA-Tags im Container die o. a. Zusätzlichen Einwilligungen als Voraussetzung verpasst bekommen, kann man in der Vorschau nun testen, ob irgendetwas feuert.

Testing im Debugger

In der Vorschau des Tag Assistant dient die Ansicht "Einwilligungseinstellungen" dazu, bei jedem dataLayer-Ereignis die derzeitige Lage der Zustimmung lt Consent Mode nachzuvollziehen. Dabei kann man auch sehen, ob die derzeitige Lage durch Vorgaben oder ein Update zustande gekommen ist.

"Übersetzung" der Einwilligungen aus dem Consent Tool in Consent Mode Einwilligungen

Damit nun die Tags feuern, wenn Consent besteht und alle Hilfsbedingungen bei auslösenden Triggern - oder blockierende Trigger, die die Zustimmungen bisher durchgesetzt haben - entfernt werden können, muss je nach Consent Tool ein etwas unterschiedlicher Weg gegangen werden. Während für die Standardeinstellungen von Google und den oben bereits angesprochenen "functionality_storage" und anderen Keys inzwischen die meisten CMP die passenden Werte selbst in den Consent Mode schreiben, müssten zumindest die hier im Beispiel selbst erfundenen Schlüssel manuell verwaltet werden.

Die meisten Tools schreiben aber ja zum Glück a) den Consent irgendwo hin und teilen dem GTM b) per Event mit, wenn diese Einstellungen geladen und / oder geändert wurden. So unterscheiden sich z. B. bei Usercentrics, One Trust und Borlabs die Namen der Events, aber bei allen kann man direkt aus der Datenschicht die Zustimmungen ablesen. Beim Consent Tool "One Trust" heißt das entsprechende Event "OptanonLoaded" und der Schlüssel, in dem Gruppen-Consent Einstellungen gespeichert sind, trägt den Namen "OptanonActiveGroups". Das ist nicht die einzige Option, aber eine typische Variante.

Zur Nutzung und Weitergabe der "eigenen" Einstellungen wie "facebook" aus One Trust an den Consent Mode benötigt man zunächst einen Trigger und eine Variable. Für das Event des geladenen Consent wird dazu ein Trigger angelegt. Eine Datenschicht-Variable liest die Consent Einstellungen.

Mit dem neuen Trigger wird ein Benutzerdefiniertes HTML Tag (oder wiederum ein eigenes Tag auf Basis eines Custom Templates, wenn man das [ver]mag) gefeuert, das die Consent Einstellungen aus der Datenschichtvariable ausliest und in Consent Mode Einstellungen übersetzt. Hier wieder ein einfaches Beispiel, das auf die beiden "Custom-Einwilligungen" zu GA und FB beschränkt ist und wo die Zustimmung anhand von Fundstellen bestimmter Kennungen in der Consent-Variable von One Trust ermittelt wird.

Auf diesem Weg stehen nun nach dem Ausführen dieses Tags unmittelbar nach dem Laden des Consent Managers im Browser und dessen Einstellungen - oder nach einer späteren Anpassung der Einstellungen - stets die aktuelle Lage im Consent Mode bereit. Diese Einstellungen übernehmen nun den Job, Tags zu blockieren, wenn die Zustimmung fehlt.

Alle bisher verwendeten je Dienst individuell angepassten Trigger oder blockierende Trigger - also alles, was bisher den Consent im Container durchgesetzt hat -, kann damit theoretisch eingespart und die Steuerung dem Consent Mode überlassen werden. Das kann je nach Containerumfang eine wesentliche Verschlankung sein. Weniger GTM Code, der geladen werden muss, einfachere Auslösungsregeln, weniger RegEx-, Cookie- und JSON-Zauberei. Das ist schon durchaus hilfreich. Aber nicht die Lösung aller Probleme, die man auch bei den klassischen Mitteln zur Durchsetzung kombinierter Trigger-Regelwerke im GTM hat. Daher zum Abschluss die Empfehlung aus der Einleitung:

Hinweise zur Umsetzung

Für alle, die sich mit diesem Wissen an eine Umsetzung im eigenen GTM Container machen wollen, hier ein paar Tipps bzw. Denkanstöße.

• Race Conditions sind immer noch ein Thema. Abstand zwischen Tag und Verfügbarkeit der Consent Einstellungen aus dem Consent Tool zu bringen, ist daher immer noch eine gute Idee. DOM Ready Trigger statt "Seitenaufruf" und / oder Consent Events in Kombination mit Setup-Tags für die Aktualisierung der Consent Einstellungen vor dem Ausführen von Tags sind hier gute Helfer, aber nicht perfekt. Daher ist ein Setup, das die Ereignisse der CMP verwendet, ohnehin unerlässlich. Dann konsequenterweise für jeden Dienst einen eigenen blockierenden Trigger anzulegen und so ein direkt im Tag Manager "lesbares" Trigger-Konzept umzusetzen und sich nicht auf die Zuverlässigkeit des Consent Mode zum Blockieren zu verlassen, erscheint als die bessere Wahl, selbst wenn dabei ein paar Trigger mehr entstehen.
• Single Page Applications sind in vielen Aspekten "anders", wenn es um das Tracking geht. Hier speziell darauf achten, was mit Seitenaufrufen nach dem Eintritt passiert und / oder ob nach einem manuellen Reload das Timing noch immer stimmt oder ob ggf. wesentliche Hits nicht gesendet werden, weil der Consent noch nicht aktualisiert wurde.
• Custom Keys bedeuten Mehrarbeit: Wie man sehen kann, ist hier einiges an Bastelei im Spiel, sobald man nicht mit den Consent Mode Standards arbeiten will. Das ist ein Argument, das mit steigender Komplexität des eigenen GTM Containers an Gewicht gewinnt.
• "Never Touch a Running System". Wenn es funktioniert, wie es jetzt gebaut ist, Performance nicht das Problem und die Komplexität zu ertragen, bringt ein Umbau stets das Risiko mit, dass es "besser" wird, aber sich Fehler einschleichen. Siehe vor allem den ersten Punkt dieser Liste. Daher ist Vorsicht geboten, wenn schon etwas da ist. Wird ein Tracking neu aufgebaut, ist der Consent Mode aber evtl. eine valide Option mit den genannten potentiellen Vorteilen, aber auch Einschränkungen.
• Consent Mode im GTM bedeutet auch eine weitere Fehlerquelle. Wenn Tags sich nicht so verhalten, wie man es sich vorstellt, kann das künftig an Consent Mode Einstellungen des Tags liegen, die man nur nicht auf dem Schirm hat.

Damit - und wenn der GTM nicht nur Dein Werkzeug, sondern zugleich Spielwiese ist: Viel Spaß beim Ausprobieren! In einem "ernsthaften" Setup empfehle ich aber dringend, beim Trigger-Konzept auf die Hilfe des Consent Mode zu verzichten. Die CMP muss ohnehin befragt werden. Die Antworten in "Custom Consent Mode Flags" zu übersetzen, führt der ganzen Sache am Ende also doch nur eine weitere Schicht hinzu, in der etwas schief laufen kann. Saubere und robuste Setups verlassen sich daher lieber ganz auf die CMP und gehen Race Conditions aus dem Weg. Im o. a. E-Book wird das Thema ausführlich behandelt. Wer vor allem Race Conditions in seinem E-Commerce Setup aus dem Weg gehen will, findet in Tools wie dem Event Repeater wirkungsvolle Mittel, die ebenfalls auf die CMP Events aufgesetzt werden können.