"Google Tag" ist da. Wozu eigentlich?

So, seit vorgestern also rollt das neue "Google Tag" langsam aus und zeigt sich in den ersten UIs von Google Tag Manager (da habe ich es gestern zumindest erstmals gefunden) und offenbar bald auch in Google Ads, den anderen Werbeprodukten und Google Analytics. Wenn ich Ankündigung und Hilfe richtig verstehe, denn ich muss gestehen, dass ich vorgestern erst einmal ziemlich hilf- und ergebnislos nach der Konfiguration gesucht habe, nachdem ich die Info bei Simo Ahava (wo sonst?) gefunden habe.

Erwartung: Weniger Last im Browser und mehr Kontrolle über Datenfluss? Falsch :(

Seit ein paar Wochen habe ich mit mehreren klugen Menschen darüber spekuliert, was sich wohl hinter dem Google Tag verstecken mag und die Vermutung / Hoffnung war, dass es sich um eine zusätzliche Option zur Stream-Konsolidierung handeln würde. Meint: gtag.js sammelt alles im Browser ein, sendet es an einen "Google Tag Endpunkt" und kann von dort orchestriert werden.

Das ist es aber leider nicht ;(

Stattdessen bietet die Google Tag Konfiguration und die Verknüpfung eines Tags mit einem Empfänger (Analytics und oder Google Ads / 360 Werbeprodukte) nur den Vorteil, dass damit beide Ziele mit dem gleichen gtag.js Code versorgt werden können; ungeachtet der Measurement ID / Ads ID, die dort angegeben ist.

Zentrale Konfiguration

Zudem erlaubt Google Tag die übergreifende Konfiguration von Ereignissen, die mit dem jeweiligen Tag gesammelt werden sollen sowie anderer Parameter - was nicht nur die sehr ähnlichen Einstellungen eines Daten-Streams in GA4 ergänzt, sondern diese auch "überschreiben" kann. Mit Potential zur Verwirrung; zumindest so, wie es derzeit aufgesetzt ist. Stellt sich die Frage:

Wozu das Ganze?

Ehrlich gesagt scheint mir das Thema primär einem Zweck zu dienen: Auch da, wo kein "umfangreiches" Tagging für Google Ads & Co. existiert, soll künftig mehr an Daten fließen.

Erreicht wird das z. B. dadurch, dass ein für Google Analytics implementiertes und konfiguriertes gtag.js meistens auf allen Seiten einer Website zu finden ist. Google Ads hingegen wird gern nur auf Conversion-Seiten ausgespielt und eingehende Klick IDs wandern per Conversion Linker oder GA bis dort hin, um die Conversion korrekt zurück zu melden.

Mehr Daten für Kampagen?

Das klappt aber immer schlechter. Wenn nun aber via einem direkt implementierten gtag.js auch Google Ads mit Daten versorgt werden kann, sind Zielgruppen auch ohne GA Verknüpfung in Ads zu nutzen. Und vor allem: Enhanced Conversions können auch ohne eine "komplexe" Implementierung via Google Tag Manager stattfinden.

Wenn sich Meta mit Advanced Matching und Google Tag "Automatic collection" für "user-provided data" auf jede Formulareingabe stürzen, dann tun sie das hauptsächlich deshalb, weil es Klick IDs und Cookies an den Kragen geht und die Erfolgsmessung immer schwieriger wird.

Das ist kontraproduktiv, wenn man jedem Kunden eine Performance Max Kampagne aufs Auge drücken will. Wo im Tag Manager also ein Anliefern zusätzlicher Identifier "einfach" einzurichten ist, bleibt bei direkter Implementierung von gtag.js in die Website nur Anpassung und IT Aufwand, der in solchen Fällen aber i. d. R. nicht geleistet werden kann - aus verschiedensten Gründen.

Daher halte ich Google Tag leider vor allem für ein Werkzeug, um auch auf Sites, denen es schwerfällt, vollständiges Ads - Tagging und aktives Anliefern von Hashes für Mailadressen etc. einzurichten, dennoch an möglichst viele Daten zu kommen. Diese spezielle Option, die in der Abbildung zu sehen ist, ist daher auch m. E. der Hauptgrund, warum man diese Konfigurationsschicht eingeführt hat, die nun zwischen dem gtag.js Script im Browser und den "Destinations" sitzt.

...oder doch mehr?

Obschon ich hoffe, dass ich da was übersehen habe oder noch sinnstiftende Dinge kommen. Schlussendlich sind gtag.js und der Tag Manager nicht sooo weit voneinander entfernt und die zentrale Konfiguration des Google Tag könnte ähnliche Funktionen bekommen. Oder irgendwann vielleicht doch auch den Endpunkt konfigurierbar machen, so dass jede direkte Implementierung dennoch einen server-side GTM nutzen kann.

Und der Datenschutz?

Wenn es eine Option gibt, die automatisch, per Code oder CSS Selektor persönliche Daten auf einer Website einsammelt, muss man sich diese Frage immer stellen. Genau wie beim Einsatz von Consent Mode oder anderen Datenschutz-versus-wir-brauchen-das-aber-Features von Google.

Während man im Google Tag Manager zumindest technisch die Möglichkeit hat, die Anlieferung solcher Identifier nur dann stattfinden zu lassen, wenn es auch der Zustimmungslage entspricht, gibt es hier nur ein Schwarz oder Weiß. Das würde jede dieses Feature nutzende Setup aus der (ohnehin zweifelhaften) "Statistik"-Kategorie für Google Analytics in die "Marketing"-Ecke schieben.

Gepaart mit einer Option, die nur generell ein- oder ausgeschaltet werden kann, sehe ich hier vor allem eines: Großes Potential zum (nicht zwingend absichtlichen / bewussten) Unterwandern von mit dem Datenschutz-Menschen abgestimmten Setups bzgl. Consent.

Inwiefern solche Daten z. B. auch zum Endpunkt wandern, wenn diese Option zur Anlieferung von "user-provided" Zeugs aktiv und der Consent Mode genutzt wird, muss man sich ansehen... aber es würde mich nicht wundern, wenn diese Parameter wie alle anderen in den "Pings" enthalten sind, die bei Consent Mode Betrieb den Browser verlassen. Wobei "user-provided" dann eben meint, dass jemand seine Mailadresse in ein Formularfeld eingegeben hat. Ob das dann wirklich mit dem Wissen oder gar der Absicht geschehen ist, diese Daten nicht nur der besuchten Website, sondern (wenngleich "nur" als Hash) auch mit anderen zu teilen, darf man getrost anzweifeln.