Markus Baersch

Google hat es mal wieder geschafft: Eine Mail wirft mehr Fragen auf, als sie beantwortet. Ähnlich wie beim Thema Consent Mode haben viele Nutzer eines Google Tools - diesmal des Tag Managers - eine verwirrende Mail zu einer anstehenden Änderung erhalten, die das Google-Tag betrifft. Dieser Beitrag beleuchtet die Hintergründe und zeigt vor allem, was konkret zu tun ist, wenn man sich nicht auf den in wenigen Wochen geänderten Automatismus verlassen mag.

Worum geht es?

Google kündigt an, ab dem 10. April 2025 das Verhalten von Google Tags zu Werbezwecken im Tag Manager anzupassen.

Es geht dabei also um das Google-Tag, welches für das Ads Konto implementiert werden soll. Es wird im Container vorgeschlagen, das Tag selbst hinzuzufügen. Wenn dies nicht passiert, wird keine weitere Änderung im Container automatisch erfolgen, sondern es ändert sich nur das Verhalten der vorhandenen Tags, wenn es darum geht, welche Version der Tracking-Bibliothek gtag.js geladen wird (dazu später mehr).

Das "Google-Tag" im GTM kennen die meisten hauptsächlich deshalb, weil das zuvor genutzte Tag vom Typ "GA4 Konfiguration" gegen ebendieses Google-Tag ausgetauscht wurde. Der alte Tag-Typ existiert schlichtweg nicht mehr und so haben viele GTM Container ein Google-Tag.

Das alte wie das neue Tag haben den gleichen Zweck: die allumfassende Bibliothek gtag.js zu laden, welche nicht nur für Google Analytics, sondern auch Google Ads, Floodlight und ein paar andere Dinge zuständig ist (wie z. B. Google Partner-Badges). Google braucht diese Bibliothek also generell für alles, was irgendwie mit Tracking zu tun hat. Dazu gehört freilich das Versenden von GA4 Ereignissen, Remarketing-Daten oder Conversions für die Werbeplattformen etc.

Ein Tag für mehrere Empfänger

Zusätzlich ist mit der Einführung die Möglichkeit geschaffen worden, ein Google-Tag mit verschiedenen Empfängern zu versehen, so dass Daten, die mit dem Google Tag des Datenstreams einer GA4 Property zeitgleich Daten an andere GA4 Properties oder - was sinnvoller ist - eben auch ein Google Ads Konto gesendet werden können.

Wenn man auf diese Weise z. B. einem Google Tag dem G-12345 für eine GA4 Property mitgibt und dieses Tag mit einem Ads Konto verbunden ist, werden Daten zusätzlich an dieses Ads Konto gesendet. Man kann sogar ein neues Google-Tag erzeugen und selbst bestimmen, welche Empfänger die Daten bekommen sollen. Die ID eines solchen Tags beginnt mit GT, also z. B. GT-12345.

In einem Google-Tag, das zu einem Google Ads Konto gehört, findet sich wiederum eine ID wie AW-12345. Meint: Ungeachtet dessen, wie ein Tag benannt ist und ob es per ID aussieht, als sei es ein Tag für GA4 oder Google Ads, können verschiedene Dienste Empfänger der Daten sein, die dieses Google Tag - z. B. via Google Tag Manager - nutzen (dazu folgen später noch mehr Details).

Status Quo: Google-Tag für Ads Konten kaum verbaut

Da diese Möglichkeit der Verbindung in der Praxis selten genutzt wird und Google keine automatische Umstellung von bestehenden Ads- oder Floodlight-Tags zu Google Tags vorgenommen hat, findet man kaum ein Google-Tag in Containern, die für Google Ads Datenströme dort implementiert wurden und die dann z. B. die entsprechende AW-xxxxx ID aus dem eigenen Google Ads Konto beinhalten.

Eine solche Umstellung wäre auch nicht so einfach, denn die einzigen Tags, die sich dafür theoretisch anbieten würden, erfüllen nicht alle Voraussetzungen. Ab Beispiel Google Ads:

• Conversion Linker Tags sind nicht überall zu finden
• Google Ads Remarketing Tags nutzen ggf. dynamische Remarketing-Daten und feuern daher ggf. nicht früh und / oder nur auf bestimmten Seiten

Dennoch sind beide evtl. geeignete Kandidaten für eine manuelle Umstellung (siehe unten).

Im Ergebnis sind in den meisten GTM Containern keine Google-Tags für Ads oder Floodlight verbaut. Der Anteil bei Containern, auf die ich Zugriff habe, lag bis zum Eintreffen der ersten Mail-Welle von Google bei Null Prozent.

Warum Google das nicht okay findet und nun Änderungen wünscht, erklärt sich am besten im Vergleich von typischem Tagging für Google Analytics und Google Ads.

Was passiert, wenn ein Google-Tag "für Analytics" geladen wird?

Wenn gtag.js als Tracking-Bibliothek mittels einem Google-Tag für einen GA4 Datenstrom geladen wird, wird die ID des GA4-Datenstroms beim Aufruf mitgeliefert. Das sorgt dafür, dass die für diese GA4 Property erforderlichen Einstellungen geladen werden. Denn sehr viele Dinge, die man in GA4 einstellen kann, werden mittels gtag.js in den Browser transportiert, so dass entsprechende Daten erzeugt werden können, die bestimmte Einstellungen der Property bzw. des Datenstroms berücksichtigen. Das sind Dinge wie

• Session Timeout
• Cookie Einstellungen
• Verweisausschlüsse
• Cross-Domain Setup
• Definition von Schlüsselereignissen
• Erstellte Events (bitte nicht nutzen! ;))
• ...

Zu den weiteren Dingen gehören die Datenschutzeinstellungen des zum Datenstrom gehörenden Google Tags. Und hier liegt der Grund für die von Google angekündigte Änderung und den Druck, ein Google Tag für Google Ads zu verbauen.

Was passiert (noch), wenn ein "Ads-Tag" geladen wird?

Wenn in einem Tag Manager ein Remarketing-Tag oder ein Conversion-Tag verbaut wird, benötigt dieses wie im Fall von GA4 ebenso die gtag.js Bibliothek. Ist diese nicht bereits durch ein Google-Tag für das Ads Konto geladen worden (das wie o. a. nur sehr selten da ist), muss das Remarketing- oder Conversion Tag also die gtag-Bibliothek vorher laden.

Dabei wird bisher allerdings nicht die Konfiguration des Google-Tags für das Ads Konto geladen, sondern eine in den Einstellungen eher "verkrüppelte" Version. Ich bin durch diesen Vorgang ehrlich gesagt erst durch den hervorragenden und sehr zeitnah erschienenen Beitrag von Simo Ahava auf diesen Umstand aufmerksam geworden. Meine Erwartungshaltung war bisher eigentlich, dass die Einstellungen des Ads-Kontos dabei durchaus berücksichtigt werden, denn über die Conversion ID ist ja eine (eigentlich) eindeutige Referenz zum Ads-Konto vorhanden, habe mir auf der anderen Seite über fehlende Events wie scroll & Co. keine Gedanken gemacht, obschon man diese ja im Google-Tag konfigurieren kann.

Derzeit wird eine Fassung geladen, die weder einen Seitenaufruf versendet, noch die Einstellungen des zugehörigen Google-Tags zu weiteren Events (scroll, click, form_start und all das gute Zeugs) berücksichtigt. Über diesen Umstand habe ich mir ebenso wenig Gedanken gemacht wie viele andere vermutlich ebenfalls, so dass wir mit den Signalen zufrieden waren, die wir über die Remarketing- und Conversion Tags gesendet haben.

Was Google mit "verlässlicheren Daten" meint

Wird künftig ein Google-Tag für das Ads Konto explizit per hinzugefügtem Tag im GTM oder automatisch geladen, werden all die o. A. Ereignisse, die wir aus GA4 beim Datenstrom aus dem Bereich "Optimierte Analysen" kennen, neben Seitenaufrufen an das Ads Konto gesendet. Wobei: Sowas wie ein scroll-Event konnte ich bei ersten Tests im Debugger nicht finden, aber es mag entweder mein Fehler sein oder erst nach dem Stichtag einsetzen / aktiviert werden.

Um die aktuellen Einstellungen zu kontrollieren, kann man entweder über das Ads-Konto (unten ist der Weg genauer beschrieben) die Einstellungen des verwendeten Google-Tags öffnen oder das Tag im Tab "Google-Tags" (statt "Konten") der Google Tag Manager Startseite heraussuchen und dann die Konfiguration einsehen.

Die "Automatische Ereignisermittlung" beinhaltet i. D. R. aktive Haken bei allen Ereignissen. Während der neu hinzukommende Seitenaufruf ggf. redundant zu einem Remarketing-Hit sein mag, wenn hier keine dynamischen Parameter im Spiel sind, sind alle anderen Ereignisse ein direkter Zugewinn an Daten für das Ads Konto.

Vor allem werden künftig die Einstellungen zur Erhebung von "von Nutzern bereitgestellten Daten" verwendet. Da diese bei einem Ads Tag üblicherweise dem Standard entsprechen, wird in diesem Fall alles, was wie eine E-Mail-Adresse aussieht, als Hash an das Ads Konto gesendet, damit dort ggf. eine Brücke zwischen Klick und Verhalten geschlagen werden kann.

Aus Sicht des Ads Kontos also eine durchaus wünschenswerte Änderung. Nur haben nach meiner Erfahrung viele die o. A. Einstellungen für den GA4 Datenstrom durchaus gezielt angepasst und z. B. irrelevante Events deaktiviert sowie die Sammlung von Mailadressen unterbunden (oder zumindest kontrolliert, indem diese Daten aktiv per Tag Manager gesendet werden).

Wer demnach nichts weiter tun will (siehe nächsten Abschnitt), sollte zumindest die Einstellungen seines Google-Tags für das Ads-Konto kontrollieren und den eigenen Datenschutzansprüchen gemäß gestalten, denn sonst geht das Hash-Gemetzel im April los.

Was passiert ab April, wenn man garnichts macht?

Weil dieses "reduzierte Basistagging" durch ein (passend konfiguriertes) vollwertiges Google-Tag und dessen Einstellungen deutlich mehr Daten "automatisch" erheben könnte, wird Google diesen "Fehler" im April korrigieren und bei allen Containern, in denen nichts geändert wird, die volle Konfiguration des Google-Tags für das Ads-Konto nutzen.

Streng genommen passiert also nach dieser Umstellung nur das, was man vorher schon hätte erwarten können - insofern ist es sogar zu begrüßen, dass wir nun durch diese Aktion darauf aufmerksam gemacht worden sind, dass die Einstellungen des Google-Tags für Ads oder Floodlight echte Gültigkeit bekommen, bevor dies passiert. Nur hat Google es leider (und vermutlich absichtlich) versäumt, uns explizite Handlungsaufforderungen bzgl. Der Konfiguration mitzugeben. Jedenfalls jenseits der vollkommen unbrauchbaren Implementierung, die im Tag Manager vorgeschlagen wird.

Es gibt demnach gute Gründe, sich nicht voll auf den Automatismus zu verlassen. Außerdem ist das von Google vorgeschlagene Google-Tag in der bestehenden Form als Alternative zum Nichtstun sogar noch gefährlicher. Daher richtet sich der Rest dieses Beitrags zwar primär an alle, die bereits der Empfehlung zur Anpassung im Container gefolgt sind oder (was ich empfehle) selbst eine gezielte Anpassung vornehmen wollen.

Anpassungsvorschlag von Google: leider ungeeignet

In betroffenen Containern (und offenbar einigen, die weder Ads- noch Floodlight Tags haben) findet sich ein Hinweis zum fehlenden Google-Tag, der zur "Reparatur" des Problems mit wenigen Klicks einlädt.

Wählt man die "Korrektur", kann dem Workspace ein Tag hinzugefügt werden. Die ID in diesem Tag hat der Assistent anhand des bestehenden Taggings für das Ads Konto ermittelt. Es muss nicht unbedingt die passende ID oder einzige sein (siehe unten)!

Am Ende steht man mit einem neuen Tag da, das man veröffentlichen soll. Es sieht in etwa so aus:

Das Problem mit diesem Tag ist vor allem der Trigger, denn hier feuert das Tag ungeachtet aller Zustimmung. Per Consent Mode findet dies dann ggf. im Advanced Modus statt, so dass keine Cookies entstehen, aber es bleibt dabei, dass dieser Trigger nur für eins gut ist: Er stellt (relativ) sicher, dass das Tag vor anderen geladen wird. Das ist definitiv keine Lösung und ich würde es selbst dann nicht so machen, wenn der Advanced Consent Mode eingesetzt werden soll. Denn selbst dann hat man i. D. R. ein anderes Trigger-Konzept als das Feuern zum frühestmöglichen Zeitpunkt. Hoffentlich zumindest.

Außerdem müssen ggf. mehrere Tags verbaut werden und / oder eine dynamische ID für das Tag verwendet werden.

Vorbemerkung: Wenn hier von Google Ads die Rede ist, dann ist zeitgleich Floodlight und die damit verbundenen Tags gemeint. Ebenso gibt es für Google Ads weitere Tags für "User-provided Data" oder Anrufconversions. Ich lasse diese hier bewusst aus, weil es sonst zu komplex wird. Die Betrachtung beschränkt sich auf typisches Conversion-Tracking und Remarketing (was in den meisten Containern das gesamte Ads Tagging umfasst). Wer Floodlight oder die anderen Tags nutzt, kann aus den Hinweisen sicherlich ableiten, was zu tun ist.

Varianten zur gezielten Implementierung

Wer die Kontrolle über die Ausspielung haben möchte, hat theoretisch folgende Möglichkeiten:

• als zusätzliches Tag
• als Ersatz für den Linker
• statt Remarketing
• per Tag-Sequencing
• per Konfiguration des bestehenden GA4-Datenstroms

Welche Option die passende ist, hängt von zwei Faktoren ab:

• Wozu wird Zustimmung abgefragt?
• Wie viele Daten will man eigentlich senden?

Zustimmung

Wer Google Ads Tags aller Art dann ausspielt, wenn eine einzelne Zustimmung zu "Google Ads" oder "Marketing" im Allgemeinen eingeholt wurde, hat im Prinzip die Wahl zwischen allen Varianten, solange sichergestellt ist, dass das Google Tag nur dann ausgespielt wird, wenn diese Zustimmung gegeben ist. Problematisch wird es nur dann, wenn das Google-Tag für GA4 künftig per Tag-Konfiguration ebenfalls Daten an das Ads-Konto als weiteren Empfänger senden soll und dieses Google-Tag bisher bei Zustimmung zu "Google Analytics" oder "Statistik" feuert. Denn sobald eine solche Verbindung besteht, kann das GA4 Tag (also das Google-Tag für den GA4 Datenstrom) nur noch dann geladen werden, wenn zusätzlich die Zustimmung zu Google Ads / Marketing besteht.

Nicht immer ist nur ein Zustimmungstyp für das Ads Tagging zuständig. So ist es nicht unüblich, Remarketing und Conversiontracking als getrennte Zustimmungen zu verwalten. Sei es per "Personalisierung" als Kategorie für das Remarketing-Tag oder über tatsächlich getrennte Einträge, wie es in Usercentrics z. B. konfigurierbar ist. Hier ist übrigens sogar der Conversion Linker als eigener Dienst verfügbar, so dass ggf. für Remarketing, Conversion-Tracking und den Linker getrennte Zustimmungen eingeholt werden (was ich vollkommen unsinnig finde, weil beide letztgenannten dem gleichen Zweck dienen).

Wer also einen der unten beschriebenen Wege geht, muss dies ggf. mit seinem Consent-Setup abstimmen.

Umfang

Wenn es darum geht, wie viele Daten gesendet werden sollen, ist neben dem Umfang der oben gezeigten Einstellungen zu Mailadressen und Events vor allem die Wahl des Triggers maßgeblich. Die unten stehenden Beispiele zur Implementierung gehen separat darauf ein.

Google-Tag zusätzlich

Wer das Google-Tag mit der ID für das Ads-Konto nun - wie von Google vorgeschlagen, dann bitte wenigstens nur bei Zustimmung - auf allen Seiten ausspielt, sendet ggf. redundante Daten zu einem (allgemeinen) Remarketing-Tag oder zumindest ungewollte Mail-Hashwerte oder weitere Events, wenn die Einstellungen nicht angepasst wurden. Zudem muss man sich bei mehreren Kategorien für Google Ads (siehe oben) für eine passende Zustimmung entscheiden. Es passiert deutlich mehr als beim Linker und nur dem Conversion-Tracking dient das, was das Google-Tag auf der Seite treibt, auch nicht. Daher muss bei getrennten Zustimmungen vermutlich auf "Remarketing" gewartet werden. Im Zweifelsfall daher immer mit der datenschutzbeauftragten Person absprechen.

Google-Tag statt Linker

Hat man ein Tag vom Typ "Conversion-Verknüpfung" im Container, kann dieses u. U. entfallen und gegen ein Google-Tag ausgetauscht werden. Denn das Google-Tag übernimmt die Aufgabe der Persistierung von Klick-IDs genauso gut wie der Linker. Aber:

Ersetzt ein Google-Tag einen Conversion Linker, der auf allen Seiten ausgespielt wurde (als Pendant zu mindestens einem Conversion-Tag, welches bei bestimmten Aktionen feuert) und es war vorher kein Remarketing Tag auf allen Seiten…

• wird nun nicht nur eine ggf. vorhandene Klick-ID beim Eintritt in Cookies und / oder localStorage geschrieben (was Aufgabe des Linkers ist), sondern
• es werden Informationen über sämtliche Seitenaufrufe aktiv an Google Ads gesendet.

Das ist a) ähnlich wie beim Ausspielen eines Remarketing-Tags auf allen Seiten und b) werden darüber hinaus die per Einstellungen des Google-Tags weiteren Events erhoben. Es entstehen also tatsächlich mehr Daten als vorher.

Will man das nicht, behält man den Linker besser bei und spielt das Google-Tag nur per Tag-Sequencing vor dem Conversion-Tag aus, damit dieses das nicht (bald) automatisch tun muss. Denn gegen den Automatismus spricht, dass dann übermorgen ggf. Tag-Einstellungen verwendet werden, die nicht mit den eigenen Vorstellungen übereinstimmen.

Statt Remarketing-Tag

Wer ausschließlich dynamisches Remarketing nutzt und daher Tags (z. B. mit Daten zu E-Commerce-Ereignissen) sendet, wird dieses nicht durch ein Google-Tag ersetzen wollen. Ist aktuell ein Remarketing-Tag ohne dynamische Parameter im Container vorhanden, welches ohnehin auf allen Seiten ausgespielt wird, kann das Google-Tag dessen Aufgaben komplett übernehmen. Ich habe mir dazu sowohl ausgehende Hits als auch die Ergebnisse im Ads Konto angesehen und bin ziemlich sicher, dass diese Methode valide ist. Hier ein Beispiel, das neben dem "Google Ads-Seitenaufruf" des Google-Tags auch die weiteren Hits zeigt, die sonst ein Remarketing-Code auslösen würde (Ja, "Conversion" ist hier im Tag Assistant irreführend):

Hat man ebenso einen Linker im Container, kann dieser sogar entfallen, solange damit nicht das o. A. Consent-Problem entsteht.

Tag-Reihenfolge

Die "schonendste" Methode der Implementierung ist die Verwendung eines Google-Tags ohne eigene Trigger. Wird dieses auf "einmal pro Seite" statt "einmal pro Ereignis" umgestellt, kann es bei bestehenden Ads-Remarketing-Tags, die nur auf einzelnen Seiten feuern oder Ads-Conversion-Tags in den Einstellungen unter "Tag-Reihenfolge" als "Setup Tag" definiert werden:

Auf diese Weise passiert genau das, was die Automatik - derzeit noch mit eingeschränkter Konfiguration - macht: Es lädt das Google-Tag (einmalig je Seite) vor dem Auslösen und verhindert damit das Laden per Automatik. Ungehindert der Tatsache, dass dies alles asynchron passiert, scheint das eine durchaus valide Option zu sein und ich habe bei Tests bisher keine Probleme (AKA mehrfache Varianten von gtag.js) festgestellt.

Der Vorteil hier ist, dass sich das Laden des Google-Tags zumindest auf die Seiten beschränkt, auf denen vorher ebenfalls ein Ads-Tag der einen oder anderen Art vorhanden war. Hat man keine Zustimmung zu Remarketing, aber zu Conversion-Tracking in einer gemischten Zustimmungslage, muss man allerdings selbst entscheiden, ob das Google-Tag dann blockiert werden soll oder nicht. Ein Laden (mit voller Funktionalität) durch das Conversion-Tag ist ohnehin ab Mitte April nicht mehr zu vermeiden. Eine Falle, die ich hier und jetzt nicht auflösen kann. - Sorry.

Über ein vorhandenes / anderes Google-Tag

Das Laden per Huckepack-Verfahren, z. B. über das auf allen Seiten vorhandene Google-Tag für GA4, ist die letzte Option. Dazu wird in den Einstellungen des Google-Tags des GA4-Datenstroms ein weiterer Empfänger für die Daten definiert.

Diese (zumindest allein) ist aber m. E. aus mehreren Gründen nicht zu empfehlen. Wer dennoch darauf setzen möchte, sollte sicherstellen, dass es keine Consent-Konflikte geben kann (siehe oben) und dass der Umfang der gesendeten Events an diesen Datenstrom wirklich zu dem passt, was man für das Ads-Konto benötigt. Die fehlende Transparenz allein aber ist m. E. Grund genug, statt einer solchen Verknüpfung lieber explizit selbst ein Google-Tag für den gewünschten Empfänger im Tag Manager Container zu verbauen.

Tag(s) identifizieren

Im Normalfall wird durch die Meldung und den Vorschlag im GTM Container bereits die richtige - und einzige - ID angezeigt, die zum im Container bedienten Ads-Konto gehört. Das muss aber nicht unbedingt stimmen. So wird nicht zwingend immer nur das gleiche Ads-Konto in einem Container bedient: Multi-Site, getrennte Sprachen oder mehrere Konten, die parallel mit Daten versehen werden (durch mehrere Tags) sind nicht unüblich.

Zudem lohnt sich die Kontrolle im eigenen Ads Konto selbst dann, wenn man nur dieses eine hat. Denn obschon sich die ID des Google Tags üblicherweise aus der Conversion ID aus einem Conversion- oder Remarketing-Tag ableiten lässt, muss diese ID nicht zwingend stimmen.

Meint: Ist die Conversion ID eines Ads-Kontos 123456789, ist diese für alle Conversions (und dem allgemeinem Remarketing-Code) stets gleich. Das zugehörige Google-Tag hat - wahrscheinlich - die gleiche Nummer, angeführt von "AW", also "AW-123456789". Wenn dem Ads-Konto ein anderes (z. B. ein neues) Google Tag zugeordnet wurde, mag die ID stattdessen mit "GT" anfangen und nichts mit der Conversion ID gemein haben. Oder es findet sich hier die ID eines anderen Datenstroms, der verbunden ist mit dem Ads-Konto.

Daher ist es eine gute Idee, in Google Ads selbst nachzusehen.

Im Data Manager in den Tools findet sich dazu ein Eintrag für das Google Tag. Ein Klick auf Verwalten öffnet die Einstellungen und die ID kann eingesehen werden. Ebenso kann man kontrollieren, ob hier weitere Empfänger zu sehen sind (wie im Beispiel zu verbundenen Tags oben bei den Varianten).

In seltenen Fällen stehen hier ggf. sogar mehrere IDs, so dass diese gar nicht mehr so eindeutig ist. Das unten stehende Beispiel ist ein Google-Tag, das auf einen "GA4-Namen" und einen "Ads-Namen" hört, aber nur (noch) einen Datenempfänger hat.

Die hier gefundene ID ist diejenige, die im Tag Manager verwendet werden sollte (bei mehreren wie im Beispiel vermutlich besser die passendere AW-123456789), wenn ein Google-Tag für dieses Ads-Konto verbaut wird.

Wer mehrere Ads-Konten parallel mit Daten versorgt, also mehr als ein Konto z. B. über den Aufruf einer Produktdetailseite per dynamischem Remarketing informieren will, muss das ganze Spiel für alle beteiligten Konten wiederholen und die Implementierung (als sitewide Tag, Ersatz eines anderen oder per Tag-Reihenfolge) mehrfach und passend zum jeweiligen Konto vornehmen.

Häufiger ist hingegen ein Ads-Tagging für mehrere Accounts zu finden, die an einer Bedingung wie dem Hostnamen oder der Sprachversion des Shops o. Ä. hängen. Kommen die hier zu verwendenden Conversion IDs aus der Datenschicht oder einer Suchtabelle, müssen für das Google-Tag für das passende Ads-Konto ggf. ähnliche Maßnahmen ergriffen werden. Hilfreich kann dabei die Tatsache sein, dass die Tag ID wie oben beschrieben aus der Conversion ID abgeleitet werden kann.

Kontrolle im Google Ads-Konto

Wichtig ist es bei allen Methoden, die empfangenen Signale im Ads-Konto im Auge zu behalten, nachdem eine Umstellung erfolgt ist. Conversions sollten weiter wie im erwarteten Umfang und in gleicher Frequenz wie vorher auftreten. Ist dies nicht der Fall, ist das Triggern schief gelaufen, denn Conversions sollten unabhängig davon, ob nun vorher "das richtige" Google-Tag gefeuert hat oder nur eine Bibliothek nachgeladen wurde, wie gewohnt einlaufen.

Brechen diese nicht ein, sondern werden mit der Zeit immer weniger, hat man es versäumt, auf jeder Seite einen Linker, das Google-Tag oder beides auszuspielen. Feuert weder das eine, noch das andere, fehlt es den Conversions an den Klick-IDs aus dem Cookie.

Wenn das Setup vorher ein Remarketing-Tag beinhaltet hat, das nun gegen das Google-Tag ausgetauscht wurde (oder selbst bei einer Ergänzung des Google-Tags im bestehenden Tagging), sollten nach wie vor Treffer für Zielgruppen in Ads zu finden sein.

In der Zielgruppenverwaltung im Reiter "Datenquellen" findet sich dazu eine Kachel für das Ads-Tagging.

Ein Klick auf "Details" zeigt den aktuellen Verlauf, der von den letzten 7 Tagen (nach Stunden) umgestellt werden kann auf die letzten 30 Tage (als tägliche Werte).

Findet dynamisches Remarketing statt, kann für die einzelnen Parameter eine Kurve erzeugt werden. Selbst ein normaler Verlauf ist hier nicht immer harmonisch, doch sowohl vor als auch nach einer Umstellung im Tag Manager sollte hier eine Kontrolle erfolgen, was empfangen wird und in welchem Umfang.

Ist die Umstellung erfolgt (hier ein Beispiel aus einem anderen Konto), kann man vor allem die Gesamttreffer im Auge behalten…

… und über Umstellen der angezeigten Werte in der Grafik auf gtag.config...

… auch gezeigt werden, ab wann die Ereignisse des Google-Tags eingelaufen sind.

Diese Grafik zeigt ein Beispiel, bei dem das Google-Tag die Arbeit eines bis dahin implementierten allgemeinen Remarketing-Tags übernommen hat (und dessen bisher gesendete Parameter irrelevant und konstant waren - als Bemerkung für alle, denen sich angesichts der Darstellung Fragen stellen ;))

Fazit / Handlungsempfehlung

Kaum überraschend halte ich es für die beste Option, selbst das Heft in die Hand zu nehmen und eine Implementierung nach einer oder oben beschriebenen Varianten zu wählen, die das Gleichgewicht zwischen den eigenen Datenschutzvorstellungen und den Anforderungen des Google-Ads-Kontos hält. Wer sich diese Mühe nicht machen möchte oder kann, ist vermutlich mit dem ab dem 10. April einsetzenden Automatik-Modus besser bedient, als mit der Implementierung der platten "Korrektur", die aus o. a. Gründen nicht haltbar ist - oder zumindest nur in den seltensten Fällen. Der Vorteil der Automatik ist, dass das Google-Tag wirklich nur da geladen wird, wo ein anderes Google-Ads Tag aus dem Container dieses erforderlich macht. Das Ausspielen auf allen Seiten ist zwar aus Sicht der Datenmenge die beste Lösung (ggf. eben auch als Ersatz eines vorhandenen Tags), aber darf nicht erfolgen, ohne dass das Thema Datenschutz mitgedacht wurde. Was im Fall von externer Betreuung bedeutet, dass man zumindest auf die Optionen und deren Auswirkungen hinweisen sollte.