Markus Baersch

Dass Google einen schlechten Start mit dem eigenen Consent Mode hingelegt hat, ist unbestritten. Eine kurze Frist, wenig Infos zu den Folgen bei Nichtbeachtung und spärliche Angaben zu den konkreten Auswirkungen waren ein ziemlicher Schreck für viele... vor noch nicht sehr langer Zeit. Nun hat Microsoft nachgezogen und alle Advertiser angeschrieben, dass der UET - eigene Consent Mode nun in der "Basic" Variante (um im Google Jargon zu bleiben) ebenfalls Pflicht wird. Ohne weitere Informationen zu Fristen und Folgen, ohne Unterstützung jenseits einer schon seit längerem existierenden Hilfe-Seite zum UET Consent Mode. Was ist denn da los?

Der Microsoft UET Consent Mode: Alter Hut

Den Consent Mode für das UET Tag gibt es schon eine ganze Weile. Der erste Fund zur URL (mit bereits dem gleichen Inhalt) in der Wayback Machine datiert bereits auf den 19. September 2021.

Er ist - wenig verwunderlich - theoretisch das Gleiche wie der Consent Mode bei Google: In die hauseigene "Kommando-Warteschlage" namens "uetq" wird - genau wie im Fall des dataLayer bei Google - die Consent-Lage hinterlegt. Da "analytics_storage" hier kein Thema ist, ist das einige Flag die "ad_storage", welche ebenfalls wie bei Google entweder "denied" oder "granted" sein kann. Gesteuert wird damit primär das Verhalten bzgl. Cookies: Ist "ad_storage" auf "denied", wenn ein Tag feuert, werden dennoch Daten gesendet, nur das keine Cookies entstehen.

Soweit, so Google. Ebenfalls gleich ist das System von "default" und "update": Das Flag kann einen Initialisierungswert per "default" erhalten (wie "denied" oder direkt "granted") und dieser Zustand kann durch ein "update" geändert werden.

Was ist neu?

Neu ist gar nichts, außer dem unbestimmten Druck, den Microsoft nun auf Advertiser ausübt. Bisher ausschließlich durch die angesprochene Mail mit dem Betreff "Important Update: UET Consent Enforcement for MAP Clients" und der unbestimmten Anforderung, dass man sich auf "upcoming changes" einstellen und den Consent Mode nun implementieren soll. Ein Link auf die oben angeschriebene Hilfe-Seite enthält wenig und wird auch nicht besser, wenn man sie sich auf Deutsch statt Englisch anschaut.

TCF? Wieso das denn?

Ich weiß es nicht. Warum alle Werbetreibenden, die das UET verbauen wollen, nun unbedingt ein TCF kompatibles Consent Management Tool einsetzen und den ganzen TCF Kram dort nutzen sollen, obschon sie kein Publisher sind, geht über mein Laienverständnis. Davon ausgehend, dass diese Anforderung von jemandem verfasst wurde, der genauso wenig Ahnung hat wie ich, bleibt meine Empfehlung: Kritisch bleiben, erst einmal nichts in dieser Richtung tun und auf den folgenden Satz vertrauen "If TCF is not currently applied, we will also accept a binary consent signal."

Die Aktivierung auf einer Website, auf der man sich bisher aus dem Thema raus gehalten hat, mag ggf. nur einen schnellen Klick im Backend kosten. Dennoch halte ich es für angebracht, diesen Schritt mit datenschutzkundigen und -verantwortlichen Menschen im eigenen Unternehmen zu besprechen. Es erscheint mir nach jetzigem Stand nicht sinnvoll (an dieser Stelle bin ich übrigens dankbar für eine kompetentere und idealerweise hier verlinkbare Einschätzung).

Wer hingegen bereits aktiv TCF v2.0 Signale mit seiner Consent Lösung erzeugt, sollte unbedingt sicherstellen, dass der eingebundene UET Code mit der in der Hilfe zu UET + TCF angegebenen Ergänzung versehen wird. Mehr dazu weiter unten im Abschnitt zur Implementierung.

Consent Mode muss sein

Aber wir müssen offenbar zumindest eine Implementierung des Consent Mode vornehmen, auch wenn es nicht unser Ziel ist, Daten ohne Zustimmung zu erheben (Advanced Mode). Es geht eher darum, dass Microsoft nun die Zustimmungs-Signale mit den Daten haben will / muss, damit diese in Microsoft Ads nutzbar bleiben (dürfen). Der Hintergrund wird auch hier in den drei Buchstaben "DMA" zu finden sein... Und dazu reicht es, wenn wir den Consent Mode initialisieren, bevor wir Daten mittels eines UET Tags versenden wollen.

UET Consent Mode: Basic oder Advanced?

Das Fass will ich hier für Microsoft nun nicht nochmal aufmachen. Meine Einstellung zum Advanced Consent Mode bei Google ist kein Geheimnis und gut dokumentiert. Wer es geschafft hat, den Advanced Mode auch für Google über seine moralischen Schranken zu heben, wird dies bei Microsoft auch tun können.

Alle anderen sind ähnlich wie für Google Ads nun angehalten, die gleichen Daten zu senden wie bisher auch - nur mit dem Unterschied, dass nun vor dem Feuern des UET Tags (meint: hoffentlich nur bei Zustimmung) noch der Microsoft Consent Mode initialisiert werden muss, damit die Daten, die an Microsoft gesendet werden, die entsprechenden Parameter und Werte enthalten, die eben diese Zustimmung dokumentieren.
Meint: Wir nutzen auch bei UET idealerweise den Consent Mode nur, um die Consent-Lage explizit mitzuteilen und nicht dazu, auch Daten zu senden, wenn keine Zustimmung da ist. Der Verzicht auf Cookies allein ist aus Sicht der meisten datenschutzkundigen Personen schlichtweg zu kurz gedacht.

Welchen Effekt hat der Consent Mode auf die Daten?

Da er gerade in der Basic Variante (also nur Feuern, wenn Zustimmung da ist) vor allem dazu dient, Daten explizit mit Consent-Informationen auszustatten, geht es vor allem um Parameter.

Im Fall des UET Tags ist dies der Parameter "asc". Er hat den Wert "G", wenn Zustimmung per Consent Mode definiert wurde. Fehlt der Consent Mode, ist der Parameter auch nicht vorhanden und Microsoft nimmt (derzeit noch) Zustimmung an. Bis sich dies ändert (wann auch immer das ist), sollten wir also alle nach Wunsch von Microsoft dafür sorgen, dass hier ein "G" zu finden ist.

Ist die Zustimmung explizit per "denied" dokumentiert verweigert worden, findet sich (wer hätte es gedacht?) hier ein "D", wenn dennoch Daten an Microsoft gesendet werden. In diesem "Advanced Mode" fehlen auch weitere Daten:

• die Parameter für die Session ID (Paramater sid) und
• Visitor ID (Paramater vid) und
• ggf. aus Cookies oder der URL bekannte MS Klick IDs (Parameter msclkid).

Wobei (wie beim Google Consent Mode) eine Klick ID als Parameter wie "?msclkid=xxxxxxx" nicht aus der URL entfernt wird, wenn ein UET Request ohne Zustimmung den Browser verlässt.

So ein reduzierter Request kann z. B. so aussehen:

Ist hingegen Zustimmung vorhanden, hat der Parameter "asc" den Wert "G" und die drei oben angesprochenen Parameter sind ebenfalls vorhanden. Das war es; von einem weiteren Parameter "vids" abgesehen, der den Zustand der Session behandelt.

Das Plugin UET Tag Helper im Browser hilft leider nur bedingt, einen aktiven Consent Mode zu erkennen und zu sehen, ob alles richtig funktioniert. Lediglich durch Einblenden der Parameter findet man freilich auch hier den "asc" Parameter, dem der Helper weder einen Namen gibt, noch auf andere Weise auf den dortigen Wert reagiert.

Interessant zu wissen: Anders als bei Google, wo wir nur vermuten können, dass es am Ende egal ist, ob ein "granted" per update oder default Kommando zustande gekommen ist und wie der Wert ggf. vor einem Update war, scheint Microsoft das nicht sonderlich zu interessieren. Wir haben entweder ein "G" oder eben nicht. Wie die Einstellung erstellt oder geändert wurde, ist den Daten nicht anzusehen. Es ist aber durchaus eine Information, die das UET Tag verwaltet (dazu gleich mehr). Bei Google ist das vollkommen anders (ohne dass wir eine Ahnung haben, welche konkreten Folgen die unterschiedlichen Kombinationen wirklich haben könnten).

TCF Aktivierung

Wer sich fragt, ob die TCF Aktivierung einen Einfluss hat: Ja, das ist der Fall. Hierfür ist ein weiterer Parameter "tcf" zuständig. Ein möglicher Wert (codiert) bei Aktivierung ist z. B. st=L&gdpr=Y. Die Werte des st-Parameters werden auf die eine oder andere Weise widerspiegeln, welche Zwecke per TCF freigegeben sind (Ad Storage, Measurement, Personalization - wie man es schon von Google kennt). Für gdpr braucht man kein Sherlock zu sein, um das "Y" zu deuten, das ich in meinem Test zu sehen bekommen habe.

Debugging in der Konsole

Consent Mode

Wer es genauer wissen will, kann die Konsole seines Browsers verwenden und sich den Inhalt von "uetq.uetConfig.consent" (einfach durch Eingabe + Enter) ansehen. Hier hat UET die aktuellen Einstellungen und Zustände gespeichert. Hinweis: UET kann die Struktur jeden Tag ändern. Diese Methode ist also nur zu Debugging-Zwecken geeignet. Etwas übersichtlicher ist es mit console.table() zu lesen:

Hier sieht man mehrere Dinge: Der erste Eintrag zeigt an, ob der Consent Mode initialisiert ist. Es folgt der Wert für "adStorageAllowed", welcher das "granted" oder "denied" übersetzt. Und obschon es den Daten nicht anzusehen ist, ob der aktuelle Zustand auf ein update oder default zurückzuführen ist, wird dies offenbar dennoch hier protokolliert.

Undokumentiert: "wait_for_update"

Die größte Überraschung ist das Vorhandensein eines "hasWaited" und "waitForUpdate" in diesem Kontext. Normale Werte sind hier false und eine 0. Die Hilfe schweigt sich dazu aus, aber offenbar kann hier (wie oben an den Werten zu sehen) offenkundig genau wie beim Google Consent Mode im Fall eines default Kommandos bestimmt werden, ob und wie lange ein UET Tag warten soll, ob nicht ggf. noch ein Update stattfindet.

TCF Unterstützung

Auf gleiche Weise kann ein Check erfolgen, wenn die TCF Option eingeschaltet wurde. Ist dies der Fall und funktioniert die Kommunikation zwischen Consent Tool und UET, findet man im Indexschlüssel "uetq.uetConfig.consent"ein true für enabled.

Ist dies trotz der Aktivierung via Code oder Option im Microsoft UET Consent Mode Tag nicht der Fall, ist der wahrscheinlichste Grund, dass auch nach der Wartezeit von einer halben Sekunde, die hier lt. Hilfe Standard ist, kein TCF v2.0 string eingegangen ist. UET schaltet die Funktion dann einfach selbst wieder aus.

Wie implementieren - und wann?

Vor allem die "Wann" - Frage ist komplex. Wir kennen keine Frist oder Deadline. Wir wissen nicht, was passiert, wenn wir nicht handeln. Da ist der auf den ersten Blick einfachste Weg, das Script anzupassen, wenn man das UET Tag als Code selbst in die Seiten einfügt (z. B. über einen Consent Manager) oder über einen Tag Manager ein entsprechendes Tag bei Zustimmung feuert.

Verwirrenderweise empfiehlt Microsoft auf der Hilfe-Seite, diese Initialisierung hinter dem Code des UET Tags zu platzieren. Ich habe es daher sowohl vor und nachher probiert und beides hat zum gleichen Ergebnis geführt. Logisch erscheint es mir aber, wie bei Google vor dem Feuern dafür zu sorgen, dass sich die aktuelle Lage in der "uetq" befindet.

Wird zum Tagging ein Template verwendet, wie es im Fall des Google Tag Managers wahrscheinlich ist, hilft z. B. ein HTML Tag, in dem man den Code aus der Hilfeseite unterbringt und dieses Tag feuert, bevor (oder nachdem) das UET Tag ausgeführt wird (siehe unten).

Zur Steuerung kann die Tag-Reihenfolge genutzt werden, oder man schreibt nach dem Initialisieren des UET Consent Mode ein Event in den dataLayer und nutzt dieses, um schlussendlich das UET Tag zu feuern. Auch die von Microsoft nun eingeforderte Anpassung für die Nutzung des TCF-Frameworks kann auf gleichem Weg umgesetzt werden. Die Hilfe beschreibt, dass der TCF Part vor dem UET Code stehen soll und der Consent Mode danach. Es scheint mir aber auszureichen, einfach beides vorher auszulösen und die Zeile

window.uetq.push('config', 'tcf', { 'enabled' : true });

bei Bedarf einfach dem obigen Code beizufügen, z. B. als neue Zeile 2.

Wie oben schon beschrieben: Die Reihenfolge scheint bis zu einer gewissen Grenze egal zu sein. Auch ohne Verwendung des oben angegebenen "wait_for_update" Parameters wird eine gewisse Verzögerung von Haus aus vorhanden sein. Auch im Fall der TCF Option gibt es eine dokumentierte Wartezeit von 500 Millisekunden, die das UET Tag auf Einstellungen wartet. Ich habe die Implementierung im Google Tag Manager im Detail auch in einem YouTube-Video zum UET Consent Mode demonstriert. Hier ist auch zu sehen, wie die TCF-Option funktioniert und wie Microsoft Clarity als "Huckepack-Produkt" zum UET Tag in diese Gleichung passt.

Consent Anbieter: Bisher nichts oder Unterstützung "Light"

Auch ein Script als HTML Tag, das auf die API des Consent Tools hört und damit ein Update ausführt, wann immer die Consent-Lage klar ist oder sich gerade geändert hat, ist eine Option für einen Einbau (Beispiel dazu bei Cookiebot). Mehr ist derzeit noch nicht zu finden, aber die Situation hat sich ja gerade erst gewandelt, also kann man hoffen. Zumindest für den Fall, dass der Google Consent Mode umgesetzt wurde... was allerdings noch lange nicht bei jedem "Consent Banner Plugin" von der Stange der Fall ist.

Tag Template für Google Tag Manager

Wer kein HTML Tag verwenden kann oder will, kann dazu auch ein Custom Template verwenden. Ich habe ein "Microsoft UET Consent Mode Tag Template" erstellt und auch für die Community Gallery eingereicht.

Hierüber kann ein "default" oder "update" mit "granted" oder "denied" für den Consent Mode angesetzt werden. Im Fall des "default" Kommandos ist auch ein "Wait for Update" definierbar. Über eine weitere Option kann man die TCF Unterstützung aktivieren, wenn wirklich erforderlich. Auch den Einsatz des Templates kann man im o. a. Video im Detail kennenlernen.

Lieber warten?

Statt einer Implementierung kann und darf man hoffen, dass genau wie beim Google Consent Mode seitens der Anbieter von Consent Tools reagiert und der Druck gemildert wird, indem diese sich um die Initialisierung und / oder das Update der UET Consent Einstellungen kümmern - genau schon beim Google Consent Mode.

Die Implementierung würde damit bestenfalls zu einem einfachen Klick im Backend von CookieBot, Usercentrics & Co. Wird das passieren? Ich halte es für sehr wahrscheinlich. Der Aufwand ist gering und alle Funktionen sind oft für bereits Google implementiert.

Fazit: Ärgerlich, aber was bringt`s?

Das ganze Thema ist vor allem eines: ärgerlich. Da sind gerade alle mit der Umstellung auf den Google Consent Mode fertig, schon kommt der nächste Player daher und will das Gleiche von uns. Gut für alle, die mit Implementierung zu tun haben, aber mal ehrlich! Solche "Arbeitsbeschaffungsmaßnahmen" braucht eigentlich niemand, schon gar nicht so schlecht kommuniziert.

Trotzdem kommen wir nicht an einer Umsetzung vorbei, wenn Microsoft Ads genutzt werden soll und Daten zu Conversions, Zielgruppen & Co. vom UET Tag kommen sollen. Ob die TCF Anforderung bestand hat oder nicht, wird sich noch zeigen. Vielleicht mag Microsoft ansonsten vielleicht wirklich zumindest Zielgruppen einschlafen lassen, wenn keine Neuzugänge mit passenden Consent Signalen zu finden sind.