Markus Baersch

Seit ein paar Tagen gibt es nun bereits neue Trigger und Consent Mode Einstellungen im Google Tag Manager. Das habe ich bisher als uninteressant abgetan. 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 keine Consent besteht und bedeutet vereinfacht, Google ohne Cookies dennoch lustig Daten sammeln zu lassen. Das finde ich aus mehreren Gründen nicht OK.

Die jüngsten Ergänzungen, die der Google Tag Manager zur Verwendung des Consent Mode erhalten hat, sind aber dennoch wert- und sinnvoll. Mit einer sauberen Implementierung kann man den o. a. "Kernnutzen" außer Kraft setzen, wenn das den eigenen Vorstellungen entspricht. Damit wird die Consent Mode Implementierung im GTM zu einem eleganten 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 bringt. 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 Umfang des Consent Mode Updates im GTM?

Das hier soll kein detaillierter Überblick über die Neuerungen sein. Wer mehr Infos sucht, findet Hinweise in der Google Hilfe oder - natürlich - bei Simo Ahava. Alle relevanten Punkte im schnellen Überblick - und vorher ein Hinweis: Wer die Einstellungen aktiv nutzen möchte, muss in den Einstellungen des Containers unter "Verwaltung - Containereinstellungen - Weitere Einstellungen" die Option „Einwilligungsübersicht“ aktivieren einschalten.

Zusätzliche 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.

Consent Einstellungen für alle Tag Typen

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 neue "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. Das ist ein wesentlicher Punkt, dessen Implikationen mir beim ersten Blick überhaupt nicht bewusst waren. Erst im Austausch mit Justus Blümer (Hat Tip an dieser Stelle nochmals dafür!) ist mir der echte Nutzen klar geworden.

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

Speziell dieser Punkt wird "lebenswichtig" dafür sein, dass der Consent Mode sich ggf. für andere Tracking-Anbieter nutzen lässt, um nicht nur die Ausführung der eigenen Tags blockieren zu lassen, sondern ggf. mit standardisierten Consent Mode Zustimmungen ein angepasstes Verhalten des Trackings zu erzeugen. Aus Sicht des GTM-Anwenders ist dieser Punkt nur aus einem Grund wichtig: Man kann sich damit eine elegantere Lösung zur Verwaltung von Consent-Vorgaben und Updates der Einstellungen bauen, als 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.

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 üblichen 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 schon jetzt 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 "AddToCart" 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 eine 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.
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.

Generell ist Performance ein gutes Stichwort: Sobald man Trigger auf die eine oder andere Weise mit Consent Bedingungen ergänzt, werden diese komplexer. Es ist nicht nur das Event xyz, sondern immer eine Kombination aus dem Event und dem Vergleich der aktuellen Consent-Einstellungen mit den erforderlichen Werten. Dabei wird wahlweise ziemlich oft auf Cookie-Werte oder Daten im Browser-Speicher zugegriffen, diese evtl. noch via JSON.parse() in einer JavaScript-Variable (immer und immer wieder) in ein Objekt umgewandelt, bestimmte Werte ausgelesen und dann schlussendlich daraus ein "OK" oder "Sorry, leider nicht" für einen Dienst wie Google Analytics gemacht. Das Ganze ist dann vielleicht im Code selbst oder bei der Bedingung zusätzlich mit Regulären Ausdrücken belastet. Das alles kostet Zeit.

Wie vereinfacht Consent Mode die Kontrolle für Tags?

Einfach ausgedrückt... so:

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 Universal 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. Hier ist davon auszugehen, dass diese Variante viele der vor allem die Performance betreffenden Nachteile der üblichen Lösungen nicht aufweist. Auf jeden Fall ist sie übersichtlicher, denn es werden keine neuen Trigger benötigt.

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.

Sobald sich dank der API andere Tracking-Anbieter entscheiden, ein "cookieloses" Verhalten anhand bestimmter Consent Einstellungen zu erzeugen, könnten auch deren Tags nicht nur platt blockiert, sondern ggf. im Datensammel-Verhalten granularer kontrolliert werden, wie es bei GA, Google Ads und Floodlight der Fall ist. Ob das gut oder schlecht ist, muss jeder selbst entscheiden - hier konzentrieren wir uns nur auf die Fähigkeit, mit eigenen Consent-Bedingungen alle Tags beliebig zuzulassen oder deren Feuern zu verweigern, ohne uns dabei mit der o. a. Triggerflut befassen zu müssen.

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. Dazu ist aktuell noch einiges an JavaScript in Benutzerdefinierten HTML Tags oder in Form von eigenen Templates erforderlich... aber mittelfristig ist zu erwarten, dass Consent Anbieter eine Benutzerauswahl zusätzlich optional in (benutzerdefinierte oder [quasi-]standardisierte) Consent Mode Einstellungen übernehmen können. Genauso wie die Auswahl derzeit schon über Cookies, localStorage oder als dataLayer-Wert gespeichert und "kommuniziert" wird, um damit das Tag Management zu steuern. Zum aktuellen Stand sind das noch sehr wenige und die Unterstützung umfasst derzeit (Stand: 06/2021) noch nirgends mehr als die beiden auf Google Dienste fokussierten (und m. E. unsinnigen) Einstellungen zur Steuerung von Cookies:

Schritt 1: Consent Mode Einstellungen definieren

Um den Consent Mode im GTM 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 unsere beiden zusätzlichen "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 Anaytics 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") eigesetzt 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: schwierig

Dabei ist es einstweilen noch egal, ob es bereits einen Consent Manager gibt, wie die konkrete Auswahl dort aussieht und ob die bestehenden Trigger im GTM diese Einstellungen berücksichtigen. Ist ein Consent Manager auf der Site aktiv, Zustimmung für FB und / oder GA vorhanden und wird eine Seite aufgerufen, werden die entsprechenden Tags scheitern und wie beim oben abgebildeten Beispiel-Event-Tag im Debugger als von Consent blockiert ausgewiesen und nicht gefeuert.

Ansonsten ist es im GTM Debugger alles noch alles etwas "holprig", aber die derzeitige Implementierung ist ein guter Anfang. Was wirklich stört, ist die Tatsache, dass man in der Preview nirgends sehen kann, wie zu einem gegebenen Zeitpunkt die aktuelle Lage der Einwilligungen im Consent Mode aussieht. Da wird sich Google sicher noch was einfallen lassen. Einstweilen kann man sich damit behelfen, die Consent Einstellungen aus dem dataLayer auszulesen und als JavaScript-Variable im Debugger einzublenden. Das ist weder schön, noch vollständig, wenn nicht immer alle Einstellungen bei einem Update gesendet werden, sondern nur die geänderten. Außerdem ist diese Methode darauf angewiesen, dass die Consent Einstellungen wirklich auf die "übliche" Weise über den dataLayer gesteuert werden. Ist die API im Einsatz (ein Link zu einem Template für Neugierige findet sich unten), kann der Consent über diesen Weg nicht eingesehen werden. Es ist aber für den Anfang mehr als nichts. Der folgende Code (ja, es geht sicher eleganter) sucht rückwärts im dataLayer den letzten "update" oder "default" Eintrag des Consent Mode und gibt die geltenden Einstellungen zurück.

function() {
  var res, dl = window.dataLayer;  
  if (dl)   
    for (var i = dl.length-1; i >= 0; i--){   
      var el = dl[i];  
      if (el[0] === "consent") {  
        res = el[2];  
        break;  
      }  
    }  
  return res;  
}

Verwendet man diesen Code als JS-Variable im GTM, kann in der Vorschau bei jedem Event so nachvollzogen werden, wie es gerade um den Consent bestellt war (mit den o. a. Einschränkungen).

"Ü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.

Die meisten Tools schreiben aber 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 Einstellungen 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 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 nun unter Tests entfernt 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:

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.
• 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.
• Früh einsteigen bedeutet Mehrarbeit: Wie man sehen kann, ist hier noch einiges an Bastelei im Spiel. Es wird sicher einfacher. Wer also wartet, hat evtl. weniger Aufwand. Das ist ein Argument, das mit steigender Komplexität des eigenen GTM Containers an Gewicht gewinnt. Vielleicht also lieber erst mal mit einem "Spielcontainer" anfangen.
  • Custom Templates? Wer lieber mit eigenen Templates statt HTML Tags arbeitet und die Sandbox API zum Zugriff auf den Consent Mode verwenden möchte, findet im oben verlinkten Beitrag von Simo ein paar Zeilen Beispiel-Code. Damit lässt sich die hier gelöste Aufgabe des Setzens von Consent und Auslesen aus One Trust Einstellungen leicht in ein Tag Template übersetzen. Ich habe das getan und den Code eines "Demo-Consent Mode Tag Templates" bei Github abgelegt. Er dient ausschließlich Demo Zwecken und kann als Grundlage verwendet werden, um andere Consent Tool - Einstellungen in Consent Settings zu übersetzen. Aber nochmals: Alles eine schöne Bastelei, aber eigentlich Aufgabe der Consent-Toolanbieter.
• "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 m. E. auch jetzt schon eine valide Option mit den genannten potentiellen Vorteilen.
• 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!