Markus Baersch

Seit der Ankündigung durch Google, dass der Consent Mode für alle im März 2024 obligatorisch wird, die via Google Analytics oder Google Ads Tagging Zielgruppen für Google Ads Kampagnen bilden wollen, sind eine Menge Fragen entstanden. Ich habe selbst, höre und lese sie und versuche an dieser Stelle, Antworten zu sammeln… soweit es diese gibt. Nicht alle Fragen haben bereits eine belastbare Antwort.

Was macht der Consent Mode?

Wie die “Version 1.0” des Consent Mode (siehe Google Ads Hilfe) geht es primär darum, durch zusätzliche Signale bei Fehlen von Zustimmung dennoch Daten zu generieren, die zur Modellierung von Conversions (Google Ads, Floodlight, Conversion-Verknüpfung) und Besucherverhalten und Conversions (GA4) dienen.

Durch das Setzen bestimmter Einstellungen werden durch mehr oder weniger vollwertige Requests, aber ohne Cookies im Consent Mode Daten auf Websites erhoben, wenn keine Zustimmung besteht oder diese explizit verweigert wurde, zumindest wenn die Implementierung in der empfohlenen Weise geschehen ist, bei der Tags in jedem Fall ausgeführt werden. Dieses Verhalten (jetzt als "Advanced Mode" in den Fokus gerückt, siehe unten) war vor allem im GA4 Umfeld bisher der übliche Weg.  Das ist - und bleibt mit den aktuellen Änderungen - ein kritisches Thema (siehe Video dazu auf YouTube).

Was ist neu im Vergleich zum bestehenden Consent Mode?

Der Consent Mode 2.0 bringt zwei neue Signale zur Steuerung hinzu. Wobei diese nicht zwingend das Verhalten von Tags verändern, sondern vor allem die Verwendung der entstehenden Daten zu Werbezwecken betreffen. Google hat beschrieben, um welche neuen Signale (“Flags”) es geht und wie man damit umgehen sollte.

• mittels ad_user_data wird bestimmt, ob die Daten zu Werbezwecken genutzt werden dürfen und
• ad_personalisation betrifft die Nutzbarkeit speziell für personalisierte Werbung. Also z. B. Remarketing

Diese beiden neuen Flags ergänzen die Einstellung ads_data_redaction, die im Zusammenspiel mit ad_storage weiterhin steuert, ob Klick-IDs verarbeitet werden - und sogar, an welche Domain Daten im Consent Mode gehen. Die o. A. Hilfe geht darauf ein, dass es zudem Wechselwirkungen mit der Einstellung allow_ad_personalization_signals für das Google Tag gibt und bei unklarer Lage (ein Signal sagt "Ja", das andere "Nein") im Sinne des Datenschutzes die Deaktivierung Vorrang hat.

Was ist der Unterschied zwischen Basic und Advanced Mode?

In der Kommunikation zu diesem Update ist der Fokus auf eine Unterscheidung zwischen einem “Basic” und einem “Advanced” Modus gelenkt worden, obschon dieser streng genommen nicht neu ist: Schon immer konnte man den Consent Mode nutzen, aber Tags trotzdem nur dann ausführen, wenn es Zustimmung gibt.

In der Google Analytics-Hilfe zum Consent Mode (statt der oben verlinkten "normalen" Hilfe zu Google Ads) finden sich dazu entsprechende Angaben. In der deutschen Fassung wird hier von der erweiterten und einfachen Variante der Implementierung unterschieden.

Es war nur eher unüblich, dies bisher für ein GA4 Setup  umzusetzen, so dass die Unterscheidung zwischen Basic und Advanced typischerweise nur in der Google Marketing Welt relevant / bekannt war, vor allem Floodlight. Geändert hat sich mit Version nun lediglich, dass die Signale des Consent Mode zur Pflicht für alle werden, die GA4 zur Bildung von Zielgruppen nutzen wollen - oder eben Marketing Tags einsetzen (siehe nächsten Abschnitt).

Basic Mode nutzen

In der Kommunikation ist einige Verwirrung darüber entstanden, wie die Steuerung des “Basic” Modus aussehen soll, da bisherige Implementierungen des Consent Mode üblicherweise (abzüglich der beiden neuen Signale) dem Advanced Consent Mode entspricht, bei dem bei Fehlen von Zustimmung dennoch Daten gesendet werden.

Die Auflösung ist - soweit ich diese bisher verstanden habe - sehr unspannend: Der Basic Modus besteht darin, Tags nur zu feuern, wenn Zustimmung besteht. Also dem bisherigen Verhalten aller Tracking-Setups, die den Consent Mode nicht eingesetzt haben… oder ggf. zwar eingesetzt, jedoch Tags nur bei Zustimmung ausgespielt haben und somit bereits im Basic Modus operieren.

Im Google Universum kann das z. B. bedeuten, dass man die Consent Mode Funktionen des Tag Managers verwendet, die man optional dazu nutzen kann, Tags am Feuern zu hindern - nicht nur für Google Tags. Ich habe dazu vor einiger Zeit ein Video erstellt und dieses Mittel eine gewisse Zeit genutzt... glaube inzwischen allerdings, dass es zuverlässiger ist, sich auf die “klassische” Art des Zusammenspiels zwischen Consent und Tag Management zu verlassen und passende Trigger-Konzepte ohne diese Funktionen zu verbauen.

Muss ich den Consent Mode einsetzen?

Wer bisher keinen Grund zum Einsatz des Consent Mode hatte, muss dies auch jetzt nicht tun. Einzige Ausnahme: Wenn entweder

• GA4 Daten für die Bildung von Zielgruppen für Marketingzwecke genutzt werden sollen oder
• Google Ads oder Floodlight-Tagging vorhanden ist,

sind die beiden o. A. neuen Signale erforderlich (mit der Einstellung “granted”), damit die gesammelten Daten ihren Zweck erfüllen.

Wer davon betroffen ist, sollte möglichst zeitig das bestehende Setup um die Initialisierung des Consent Mode und das Setzen der entsprechenden Flags ergänzen.

Wichtig: Dabei ist es nicht nötig, etwas an den Triggern zu ändern oder damit anzufangen, ohne Zustimmung Daten zu senden! Vielmehr reicht es, den Consent Mode zu initialisieren und nach wie vor alle Tags nur dann auszulösen, wenn dazu Zustimmung erteilt wurde.

In den meisten Fällen wird es genügen, im Consent Manager die entsprechenden Optionen zu aktivieren und anschließend zu überprüfen, ob die Signale wie gewünscht initialisiert und mit den Daten an GA4 und / oder Google Ads gesendet werden. Da die meisten CMP-Anbieter den Consent Mode bereits unterstützen, werden die beiden neuen Signale diese nicht vor eine Herausforderung stellen. Die meisten haben hier sogar bereits reagiert.

Im Bedarfsfall ist eine manuelle Anpassung des eigenen Setups mit überschaubarem Aufwand möglich (siehe Abschnitt zur manuellen Konfiguration).

Was ist, wenn der Consent Mode bis März 2024 nicht implementiert ist?

Das ist eine gute Frage. Sicher ist wohl, dass dann mit GA4 keine Zielgruppen mehr für Marketingzwecke erstellt werden können. Vermutlich gilt das für Google Ads Remartketing-Tags etc. ebenso. Aber ob nun z. B. gar keine Conversions mehr im Ads Konto ankommen, kann man nur vermuten bzw. befürchten. Daher ist eine Umsetzung für alle Marketing-Setups im Google Kosmos unter den o. a. Bedingungen unvermeidlich. Was bereits bekannt ist: Wer den Consent Mode 1.o verwendet, wird ein "automatisch konvertiertes" ad_user_data Flag bekommen, das den Wert von ad_storage übernimmt. Ohne Consent Mode aber fehlen die Signale eben vollständig und das wird zum Problem ab dem 6. März.

Auch in der API, bei Funktionen zum Upload von Daten zum Kundenabgleich, Enhanced Conversions for Leads oder dem Offline Conversion Import finden sich inzwischen Einstellungen für die beiden neuen Flags zu ad_user_data und ad_personalization. Je nach Zweck der Funktion ist daher zu erwarten, dass die gleichen Regeln für alle Daten und nicht nur via Web und App gelten und ggf. Conversions gezählt, aber keine für Werbung nutzbaren Audiences entstehen.

Es ist denkbar, dass bisherige Funktionen wie das rückwirkende Befüllen neuer Audiences in GA4 nicht mehr verfügbar sind, wenn der Consent Mode nicht verwendet wird. Das würde bedeuten, dass auch ein reines GA4 Setup je nach Nutzung auf den Consent Mode - wenn auch "nur" Basic, (siehe nächsten Abschnitt) - angewiesen sein kann. Ob und welche Funktionen wie genau betroffen sind, werden wir im schlimmsten Fall erst nach dem 6. März 2024 erfahren.

Ändert sich etwas aus Datenschutzsicht?

Um es einfach zu halten: Nichts. Jedenfalls nicht, wenn man den “Basic” Modus wählt und (wie vermutlich jetzt schon) nur dann Daten sendet, wenn Zustimmung erteilt wurde. Die aus dem Browser versendeten Daten sehen nicht anders aus als vorher, bringen nun aber explizit die Information mit, dass diese zu Marketingzwecken und ggf. personalisierter Werbung genutzt werden können.

Es ist davon auszugehen, dass damit primär eine belastbare und “mit aktiven Opt-Ins” versehene Basis für die Nutzung in den Marketing-Tools geschaffen werden soll. Funktional sind die Consent Mode Flags irrelevant, wenn man dem Advanced Mode fernbleibt. Dessen Einsatz wiederum ist in Zukunft ebenso kritisch zu prüfen, wie es heute bereits der Fall ist. Ebenso steckt in jedem Setup selbst ohne Consent Mode reichlich Potenzial für ungewollte Auslösungen von Tags, so dass ein Check unabhängig von dessen Einsatz sinnvoll ist.

Woran erkennt man den Einsatz?

Wenn der Consent Mode aktiv ist - sei es bei Zustimmung oder in Requests, die ohne Zustimmung verschickt werden -, werden zusätzliche Parameter genutzt, die man z. B. im Netztwerk-Tab des Browsers gezielt suchen kann, um zu sehen, ob

• der Consent Mode im Einsatz ist und die Daten
• mit oder ohne Zustimmung für Analytics- oder Ads-Cookies erhoben wurden

Hierzu dient der Parameter gcs. Ist er in Requests zu finden, hat er einen Wert im folgenden Format: G1xy.

Dabei steht “x” für die Zustimmung zu Google Ads Cookies und ist entweder “1” (zugestimmt) oder “0” (nicht erlaubt, kein Cookie wird gesetzt). Der zweite Wert "y" steht analog mit “1” oder “0” für die Zustimmung zu Google Analytics Cookies.

Mögliche Werte sind demnach

• G100: Request im “Advanced Mode”, keine Cookies
• G110: Zustimmung nur zu Google Ads, aber nicht Google Analytics
• G101: Zustimmung nur Google Analytics, aber nicht Google Ads
• G111: Volle Zustimmung

Sichtung des Netzwerkverkehrs

Durch Suche nach “collect” (Name des GA4 Endpunkts) bzw. dem Parameternamen “gcs” in der Netzwerk-Übersicht können z. B. GA4 Requests gefunden und per Klick die Nutzlast sichtbar gemacht werden, die alle Parameter und deren Werte aufzeigt:

Das Vorhandensein der beiden neuen Einstellungen des Consent Mode 2.0 ist hingegen an einem anderen Parameter “gcd” abzulesen (siehe “Nerdkram” unten).

Check in Tag Assistant

Auf der eigenen Website ist der einfachste Weg zur Kontrolle die Vorschau des Google Tag Managers. Wenn im Tag Assistant auf der linken Seite die Ansicht der Ereignisse im dataLayer betrachtet wird, finden sich dort Einträge vom Typ “Consent”. Hier kann abgelesen werden, ob Default-Werte oder ein Update erfolgt ist und welche Einstellungen gelten, bevor die entsprechenden Tags ausgelöst werden.

Hier ein Beispiel, in dem zunächst Standard-Einstellungen im Event Nummer 10 gesendet wurden und dann mit Event 13 aktualisiert und in allen entsprechenden Parametern auf “granted” gesetzt werden (siehe “API Call”):

Zudem kann auch der eigene Tab "Consent" verwendet werden, um bei jedem Ereignis die derzeit geltende Lage zur Zustimmung abzulesen. Dazu muss kein Tag Manager im Einsatz sein, die Kontrolle ist auch direkt über die Ereignisse des GA4 Datenstroms möglich. Weitere Info und Beispiele dazu gibt Google in der Hilfe zur Kontrolle des Consent Mode.

"Renovierte" Consent Übersicht 01/2024

Mit steigendem Druck zur Implementierung hat Google die Consent-Übersicht im Tag Assistant angepasst, um die Kontrolle zu vereinfachen. Hiermit kann zu jedem dataLayer-Ereignis nachvollzogen werden, wie beliebige Consent-Flags (also nicht nur die vordefinierten) initialisiert und ggf. per Update angepasst wurden.

Diese Übersicht erleichtert die Kontrolle im Tag Manager deutlich für alle, die sich jetzt mit dem Einbau befassen.

Kontrolle im dataLayer

Schwieriger - und nicht unbedingt zuverlässig - ist ein Blick in den dataLayer in der Konsole des Browsers. Unzuverlässig deshalb, weil nicht alle Wege zum Setzen von Consent Mode Einstellungen wirklich Spuren im dataLayer hinterlassen. Auf der anderen Seite ist ein Vorhandensein ein sicheres Zeichen und erlaubt das Auslesen der Einstellungen ebenso, wie es oben bereits für die Vorschau des Tag Managers beschrieben wurde.

Für welche Tags ist der Consent Mode relevant?

Der Consent Mode dreht sich generell “nur” um Tags aus dem Google Universum, also Google Analytics, Google Ads und Floodlight sowie Tags vom Typ "Conversion-Verknüpfung".

Auch andere Tags können theoretisch mit den von Google vorgesehenen weiteren allgemeinen Flags für “Personalisierung, Sicherheit und Funktionalität” (siehe Hilfe) gesteuert werden. Sogar beliebige selbst definierte Einstellungen sind nutzbar (siehe Video-Link oben). Diese dienen ausschließlich dazu, die Ausspielung von Tags zu steuern, aber nicht das Verhalten, wie es im Fall der Google Tags hinsichtlich der Nutzung von Cookies funktioniert.

Es gibt noch eine exotische Ausnahme von dieser Regel: Microsoft Ads kennt ebenfalls einen Consent Mode. Dieser muss allerdings zwar auf ähnliche Weise initialisiert und genutzt werden, lebt nicht im dataLayer und ist nicht direkt mit dem Google Consent Mode verbunden, sondern vollkommen unabhängig.

Muss ich die Consent Mode Funktionen im Tag Manager nutzen?

Wie oben bereits beschrieben ist der Einsatz der Consent Mode Funktionen zur Steuerung von Tags im Google Tag Manager nicht das einzige Mittel, um z. B. ein “Basic” Setup zu erstellen, indem alle Tags so konfiguriert werden, dass diese nur bei entsprechender Zustimmung feuern (statt nur deren Verhalten anzupassen und dennoch ausgespielt zu werden).

In den meisten Fällen existiert bereits ein “Zustimmungs-sensitives Setup” und dieses kann und sollte beibehalten werden. Nur eine entsprechende Initialisierung der Consent Mode Flags vor dem Ausspielen kann erforderlich sein, wenn die Daten zu Werbezwecken eingesetzt werden sollen (siehe “Muss ich den Consent Mode einsetzen?”).

Was soll ich tun, wenn mein Consent Manager den Consent Mode nicht unterstützt?

Im Fall des Einsatzes einer CMP, die den Consent Mode nicht unterstützt, kann die Initialisierung in das eigene Setup aufgenommen werden und entweder per JavaScript direkt in der Seite oder einem HTML Tag über den Tag Manager oder (bei Einsatz des GTM) mit der Tag Vorlage von Simo Ahava erledigt werden.

Als HTML Tag, das bei Zustimmung möglichst früh ausgeführt wird (ggf. als Setup-Tag des Google-Tags oder der Google Ads Conversions etc.), kann das bei manueller Konfiguration so aussehen:

<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('consent', 'default', {
'ad_storage': 'granted',
'analytics_storage': 'granted',
'ad_user_data': 'granted',
'ad_personalization': 'granted',
'wait_for_update': 500
});
</script>

Mit der o. a. Tag Vorlage aus der Community Gallery geht dies genauso:

Fazit: Mit passenden “default” Einstellungen initialisiert oder vor dem Feuern der Tags durch ein “update” aktualisiert, so dass gemäß der Consent Einstellungen die jeweiligen Signale auf “granted” gesetzt sind, kann ein (sauberes!) bestehendes Tracking-Setup leicht so gestaltet werden, dass die neuen Signale an Google gesendet werden. So können auf den Google Marketing-Plattformen nach wie vor Zielgruppen erstellt und Conversions gemessen werden.

Nerdkram: Parameter und Formate

Neben dem oben beschriebenen Parameter gcs, an dem der Zustand des Consent Mode bzgl. der Zustimmung zu Cookies abgelesen werden kann, ist der Zustand der beiden neuen Flags aus dem Consent Mode 2.0 dort nicht zu finden.

Hierzu dient der zusätzliche Parameter gcd. Ob das “D” dabei für “Defaults” steht oder nicht: Er ist in allen Fällen vorhanden, wenn der Consent Mode im Einsatz ist. Das war nicht immer so und er hatte früher ein anderes Format, das dem des gcs Parameters entsprochen hat; also z. B. Werte wie “G100” hatte. Inzwischen ist er aber bei Nutzung des Consent Mode stets vorhanden, selbst wenn es kein “update” ursprünglicher Einstellungen gibt und das Format hat sich ebenfalls deutlich geändert.

Unabhängig davon, ob die aktuellen Einstellungen zum Zeitpunkt der Entstehung des Requests durch “default” oder ein “update” entstanden sind: Er beinhaltet an unterschiedlichen Stellen Marker für den Zustand aller vier Parameter, die relevant sind:

• Google Ads (ad_storage)
• Google Analytics (analytics_storage)
• Werbezwecke (ad_user_data)
• Personalisisierung (ad_personalization)

Das aktuelle Format sieht so aus:

11ad_storage1analytics_storage1ad_user_data1ad_personalization5

Wobei die “11” am Anfang ebenso konstant sind wie die drei Stellen, wo jeweils eine “1” die Marker für die fett gedruckten Einstellungen trennt sowie die “5” am Ende.

Viele Varianten

Statt der "5" am Ende sind hier offenbar auch eine "6" oder "7" gesichtet worden. Ebenso kann statt einer "1" auch eine "3" vorkommen (außer an der ersten Stelle). Meint: eine "3" als Präfix der jeweiligen Buchstaben, die ebenso unterschiedlich ausfallen (siehe unten) ist kein Indikator für ein Problem, sondern kommt offenkundig vor. Was genau dahinter steckt, wird uns wohl nur Google verraten können.

Die Marker selbst können wiederum durch Buchstaben wie p, t, q, r oder l besetzt sein. Ein Beispiel für vollständig konfigurierten Consent mit “granted” für alle vier Werte wäre 11t1t1t1t5.

Ja, das ist eher kryptisch. Und es wird noch besser: auch ein 11r1r1r1r5 ist genau so gut wie die oben angegebene Zeichenkette. “Alles denied” würde entsprechend z. B. so aussehen: 11p1p1p1p5  oder 11q1q1q1q5. Zudem gibt es Mischungen der t und p bzw. r und q Zustandsmarker. Alle Marker können zudem neben t/r oder p/q ein l beinhalten.

Weiterhin scheint es zusätzliche Varianten zu geben, bei denen andere Buchstaben den gleichen Zweck erfüllen. So stehen Buchstaben "m" oder "u" für "denied" bzw. "n" oder "v" für "granted" (Danke an Wolfgang Lukas für diese Ergänzung).

Selbst bei komplettem Fehlen der Consent Mode Einstellungen ist dieser Parameter vorhanden und hat für alle Flags folgerichtig ein "l". Dass kein Consent Mode initialisiert ist, sieht man nicht nur am Fehlenden gcs Parameter, sondern auch an einer "1" am Ende des gcd Parameters statt einer "5" oder "6" (vermutlich eine Versionierung?), der in einem solchen Fall z. B. "11l1l1l1l1" lauten kann.

Was steckt dahinter?

Für die beiden ursprünglichen Flags für Ads und Analytics gibt es, wenn der Consent Mode aktiv ist, nur die beiden Optionen “granted” oder “denied”. Daher reichen hier üblicherweise zwei verschiedene Zustände (warum es dennoch zwei Varianten gibt, wird gleich aufgeklärt).

Die beiden neuen Flags hingegen können bei einem “alten” (also heute bestehenden) Consent Mode Setup undefiniert sein (denn sie sind ja neu). Um diesen Zustand abzudecken, dient das l. Es kommt bei den beiden ersten Flags ebenfalls zum Einsatz, wenn analytics_storage oder ads_storage nie definiert wurde. Da dieser Fall in einem normalen Setup nicht vorzufinden ist, kann er vernachlässigt werden. Mit diesen verschiedenen Buchstaben als Zustands-Marker ist auf Empfängerseite klar, wie Werte definiert sind und ob das Setup ggf. nur einen Teil der Flags gesetzt hat.

Dass es für “granted” und “denied” für die verschiedenen Flags jeweils zwei verschiedene Varianten von Buchstaben gibt, liegt daran, dass hieraus abgelesen werden kann, ob die Zustimmung oder Ablehnung durch Voreinstellungen (“default”) oder ein “update” entstanden sind.

Damit kann man die Buchstaben wie folgt übersetzen:

• l: Einstellung wurde nicht definiert
• p: Einstellung “denied” durch “default” Einstellung
• q: Einstellung “denied” durch ein “update”
• t: Einstellung “granted” durch “default” Einstellung
• r: Einstellung “granted” durch ein “update”
• m: Einstellung “denied” durch ein “update” ohne vorherige “default”
• n: Einstellung “granted” durch ein “update” ohne vorherige “default”
• u: Einstellung “denied” durch ein “update”, nachdem der “default” Wert “granted” war
• v: Einstellung “granted” durch ein “update”, nachdem der “default” Wert bereits “granted” war

Wenn hier neben diesen Werten ggf. andere Buchstaben zu sehen sind, mag das an weiteren Kombinationen von Default- und Update-Werten liegen. Auch die Methode (API vs. dataLayer) scheint eine Rolle zu spielen. Egal in welcher Weise Google hier das Alphabet durchspielt: In jedem Fall sollte es für eine Kontrolle der korrekten Übertragung der Einstellung genügen, deren Vorhandensein zu prüfen und die Bedeutung zu kennen.

Übrigens: Die zusätzlichen Consent Mode Einstellungen funtionality_storage, personalization_storage und security_storage, welche nur für GTM gedacht sind, haben hier folgerichtig keine Auswirkungen.

Wer die Einstellungen via Konsole kontrolliert, sollte darauf achten, dass keine unlogischen Werte wie 11p1p1t1t5 (ad_user_data und ad_personalization erlaubt, jedoch keine Cookies) o. Ä. zu finden sind, denn so würde zwar die Bildung von Zielgruppen erlaubt sein, aber GA4 und Google Ads nicht genug Daten erhalten.

Weitere Parameter

Im Zusammenhang mit dem Consent Mode sind weitere Parameter im Spiel, die ohne dessen Einsatz nicht Teil der Requests sind. Ich habe den Vergleich von zwei Requests, die einmal mit und einmal ohne Zustimmung entstanden sind, als Diff abgelegt. Dort findet man u. A.:

• npa: nicht vorhanden, wenn Zustimmung besteht, bei fehlender Zustimmung (zu personalisierter Werbung) mit einer “1” belegt
• dma_cps: hat bei fehlender Zustimmung ein “-” als Wert, bei Zustimmung steht dort üblicherweise “sypham”. Fehlen hier einzelne Buchstaben, hat man in seinem Google Tag die "Datennutzung für alle Google-Dienste verwalten" konfiguriert, so dass nur einzelne Dienste die erhobenen Daten erhalten dürfen. Wie Simo Ahava entschlüsselt hat, stehen die einzelnen Buchstaben für Search, Youtube, Play, Shopping, Ads und Maps. Werden einzelne Dienste deaktiviert, sind auch die passenden Buchstaben aus dem Parameterwert verschwunden.

Warnung: All diese verschiedenen Parameter, Werte, Marker und das komplette Format sind zusammen mit den bestehenden Fragen zu einzelnen Werten ein sicheres Zeichen dafür, dass hier weitere Änderungen zu erwarten sind. So sind z. B. die neuen Einstellungen ggf. Irgendwann direkt am gcs-Parameter ablesbar.

Wer den Consent Mode im Browser nicht einsetzen und dafür ersatzweise an einem server-side GTM den Requests passende Ergänzungen verpassen will, damit diese die passenden Signale zur Aktivierung für Werbezwecke enthalten, sollte diesen Plan lieber verwerfen, denn diese Lösung erscheint einfach zu unsicher. Dann bei Bedarf lieber im “Basic Mode” bleiben, Tags nur bei Zustimmung feuern und die Signale direkt im Browser durch passende Initialisierung des Consent Mode erzeugen. Das erscheint sicherer, denn wer weiß schon, was sich Google bzw. gtag.js in diesem Zusammenhang noch alles einfallen lässt.