Implementierung und Verifikation von Erweiterten Conversions für Google Ads

Dass Cookies auf dem absteigenden Ast sitzen, ist nichts neues. Ebenso wenig - eigentlich - die Enhanced Conversions für Google Ads, Meta und viele anderen Anbieter, die anhand von E-Mail-Adressen im Klartext oder als Hashwert gern die Lücke im Tracking schließen wollen, wenn keine Referenz in Form einer Klick-ID o. Ä. in einem Cookie zur Hand ist.

Telefonnummern, Namen und Adressen gehören ebenfalls zu diesen Nutzerdaten, die durch Abgleich mit der eigenen Datenbank die Verbindung zwischen Aktion und Ergebnis schaffen sollen. Das kann z. B. der Anzeigenklick bei Google oder Meta im angemeldeten Zustand sein. Findet sich z. B. zu einem an einer Conversion hängenden E-Mail-Hash ein Treffer zu einer Aktion auf der eigenen Plattform, kann der Empfänger (also z. B. Google Ads) den zuvor erfolgten Klick mit der Conversion auch ohne Cookies verknüpfen. Die Umsetzung ist allerdings nicht immer ohne Hürden und Missverständnisse zu erledigen. In diesem Beitrag geht es daher vor allem um die Implementierung und Verifikation von Nutzerdaten für Google Ads.

Nutzerdaten? Senden die meisten Websites schon lange (ohne es zu wissen)

Wer ein Meta-Pixel auf seiner Website verbaut, hat i. d. R. eine Funktion aktiv, die sich Automatic Advanced Matching schimpft. Diese macht nichts anderes, als alles, was nach einer Mailadresse oder anderen verwertbaren Daten aussieht, an Facebook zu senden. Das kann z. B. nach der Eingabe einer Mailadresse in einem Newsletterabo-Formular sein. Schon vor dem Senden des Formulars hat die Adresse dadurch i. d. R. schon den Browser verlassen.

Wer jetzt denkt: "Pfui, typisch Facebook": Vorsicht! Um zum Thema Google Ads (und in Teilen Google Analytics) zu kommen - dort gibt es exakt die gleiche Funktion beim Google-Tag. In den Einstellungen des Tags findet sich die Option "Funktionen für von Nutzern bereitgestellten Daten zulassen".

Diese Option ist im Standard eingeschaltet bei Google-Tags (egal ob Google Ads oder Google Analytics - oder vermutlich bald ebenso Google Tag Manager) und sammelt Mailadressen, Telefonnummern und Adressen. Durch die automatische Erkennung werden zumindest Mailadressen recht gut erfasst. Diese Daten fließen also bereits ohne Variable vom Typ "Von Nutzern bereitgestellte Daten" und / oder das entsprechende Tag im Google Tag Manager bzw. andere Ergänzungen in das Tracking für Google Ads ein! Wer sein Google-Tag für Google Analytics mit einer weiteren Destination versehen hat und so auch Google Ads mit diesem Tag bespielt: Die gleiche Nummer.

Und dennoch sehe ich in Tag Manager Containern häufiger eine solche User-provided Data-Variable (ab hier Nutzerdaten-Variable), die explizit auf automatisch steht, nur um dann ein Tag vom Typ Google Ads User-provided Data Event zu füttern, welches dann parallel zum Conversion-Tag ausgelöst wird. Effekt ist freilich gleich Null. Erst wenn hier manuelle Konfiguration mit explizit aus Formularen oder der Datenschicht entnommenen Daten geschieht oder generell Mailadresse & Co. nach Anmeldung per Username (also keine Mailadresse im Browser selbst zu sehen) aus dem Datalayer verwendet werden sollen, hat ein solches Tagging einen tatsächlichen Mehrwert!

"Automatikmodus" verlassen

Davon ausgehend, dass alles außer der Mailadresse eigentlich nur noch einen geringen zusätzlichen Effekt auf das Matching hat (das sollten die meisten bestätigen können, die mit Erweiterten Conversions arbeiten), fängt es erst dann an, sinnvoll zu werden, wenn selbst die Kontrolle übernommen wird. Wenn z. B. nur auf der Bestellbestätigungsseite eine Mailadresse (und nichts anderes) übergeben werden soll, kann und sollte man dies im Tag Manager auf dem o. a. Weg tun. Eher der Vollständigkeit halber soll hier auch erwähnt werden, dass man über die oben abgebildeten Optionen beim Google-Tag ebenso aktiv per CSS-Selektor und / oder dem Namen einer globalen Variable bestimmen kann, wo die Mailadresse herkommen soll. Man sollte dies aber bestenfalls als letzten Ausweg betrachten. Wenn es z. B. keinen Tag Manager gibt, sondern das Tracking auf anderem Weg implementiert wurde.

Telefonnummern und Adressen?

Wenngleich an die Telefonnummer und vor allem Adressdaten mehr Anforderungen bestehen, als man denken mag, ist es verlockend. Solche Daten können, wenn zuverlässig erkannt, "stückweise" das Puzzle füllen. Meint: Auch nur ein Name würde auf diesem Weg gesendet werden oder ein Vorname, wenn man dies definiert. Damit die Daten (ggf. auch ohne Mailadresse) eine Chance haben, eine Verbindung zu einem Klick zu liefern, müssen diese Bruchstücke einen Mindestumfang haben - entweder in Summe oder nacheinander gesendet. Wenn man daher z. B. versucht, Selektoren für den Namen und Vornamen anzugeben, aber weder PLZ noch Land anbieten kann, weigert sich sowohl die Konfiguration beim Google-Tag als auch die Nutzerdaten-Variable im Tag Manager bei der manuellen Bestückung, wenn zur Adresse nicht wenigstens diese Mindestangaben vorhanden sind. Hier am Beispiel des Google-Tags:

An dieser Stelle ist eine Konfiguration allerdings weniger sinnvoll, als im Google Tag Manager. Heute noch über die dazu vorgesehene Variable und das Tag, morgen ggf. ebenfalls nur noch via Tag-Einstellungen des Tag Managers - wir werden es sehen.

Automatikmodus: Oft weniger, als man erwartet

Wer auf automatisch gesammelte Daten setzt, ohne dass spezielle Konfiguration im Einsatz ist, sendet übrigens ggf. weniger, als man nach dieser Beschreibung erwarten kann. Am Beispiel einer Testseite soll dies demonstriert werden. Auf gleiche Weise kann übrigens auf der eigenen Website verifiziert werden, ob und welche Nutzerdaten bereits verarbeitet werden.

Auf einer Testseite ist dazu ein einfaches Formular eingebunden, wie man es in ähnlicher Form auf jeder Website finden kann.

Wird auf dieser Seite ein Google-Tag mit automatischer Erfassung geladen und ist der Consent Mode passend initialisiert (siehe unten), werden nach dem Ausfüllen (ja, Autofill durch den Browser genügt) schon vor dem Senden des Formulars mehrere Requests den Browser verlassen.

Debugging im Tag Assistant

Um die entsprechenden Requests zu sehen und zu kontrollieren, kann der Google Tag Assistant verwendet werden. Dazu muss kein GTM im Einsatz sein. Auch ein Google-Tag, das auf anderem Weg auf der Seite implementiert wurde, kann auf diese Weise untersucht werden, ohne dass man den Netzwerk-Tab durchsuchen muss. Wird die obige Testseite geöffnet und besteht Zustimmung, kann man nicht nur den dortigen Tag Manager und dessen Tags kontrollieren, sondern alles, was die verbauten Google-Tags so anstellen. Oben kann dazu auf das entsprechende Tag geklickt werden. In der Zusammenfassung (oder wie hier beim passenden Ereignis) zeigt der Tag Assistant dann unter "Gesendete Treffer" an, was den Browser verlassen hat.

Üblicherweise sind dies zwei Requests an unterschiedliche Endpunkte und einer davon enthält den Parameter em mit den erfassten Nutzerdaten. Per Klick können diese eingesehen werden.

Wer sich den Parameter anschaut, wird schnell erkennen: Obschon im Formular in diesem Beispiel Mailadresse, Telefonnummer, Vorname und Nachname angegeben wurden, scheint nur die Mailadresse den Browser zu verlassen. Wer mehr wissen will, kann sich z. B. meine dazu vorgesehene Chrome Erweiterung "Enhanced Conversion Data Validator" über den Chrome Webstore installieren. Darin kann der Wert des em-Parameters kontrolliert werden. Und da ein Hash nichts ist, aus dem man die Mailadresse wieder zurückrechnen kann, bietet der Validator für alle Parameter, die gefunden wurden, ein Eingabefeld mit dem Klartext an, so dass der Hash mit der Eingabe verglichen werden kann.

Da der Validator eine Funktion zum Aufzeichnen der Requests für Userdaten und Google-Ads Conversions hat, kann man sich damit zudem den Umweg über den Tag Assistant sparen, wenn man Validierung von Ads-Tracking (wie ich) häufiger auf dem Tisch hat 😉 Wir kommen später darauf zurück...

EC Data Validator Chrome Extension installieren

Voraussetzungen für Enhanced Conversions

Damit der Versand von Nutzerdaten stattfinden (und beobachtet werden) kann, müssen folgende Voraussetzungen erfüllt sein:

• Wer per Google-Tag, explizitem Google Ads User-provided Data Event im Tag Manager oder als user_data-Parameter einer Google Ads Conversion Tag beigefügt Nutzerdaten an Google Ads senden will, muss zwingend den Empfang im Ads-Konto aktiviert haben (z. B. unter "Conversions - Einstellungen"). Ich habe es mit einem Konto mit aktiver und einem ohne aktive Option probiert - ohne Aktivierung wird der für die Nutzerdaten zuständige em-Parameter fehlen.
• Aus gleichem Grund kann es nicht klappen, wenn die Conversion ID eines UPD Tags nicht stimmt, denn dann führt sie sehr vermutlich nicht zu einem echten Ads Konto mit aktiver Option.
• Im Browser muss der Consent Mode per default oder update mit dem Wert granted für ad_storage, ad_user_data und ad_personalization ausgestattet sein. Wenn eine dieser Voraussetzungen nicht erfüllt ist, fehlen die Nutzerdaten an den ausgehenden Tracking-Requests.
• Wenn eine CSP das Senden verhindert, geht - logisch - nichts raus.

Üblicherweise fehlt bei falscher Konfiguration des Ads Kontos oder der Nutzerdaten "nur" der em-Parameter, nicht der ganze Request. Wenn also nichts feuert, stimmt das Setup im GTM nicht oder die CSP ist schuld.

Nutzerdaten im Google Tag Manager steuern

Wie oben gezeigt ist die Automatik nicht ideal und lässt Daten ggf. aus. Daher empfiehlt es sich, den Tag Manager zu verwenden und selbst dafür zu sorgen, dass verfügbare Daten möglichst zuverlässig zur Zuordnung von Conversions genutzt werden können. Dabei können mehrere Ansätze verwendet und beliebig miteinander kombiniert werden:

• Transport über das Google-Tag und dessen Einstellungen (wie oben gezeigt)
• Verwendung eines Google Ads User-provided Data Event nach einem Login oder erfolgreichem Formularversand etc.
• Anreichern einer Google Ads Conversion mit Nutzerdaten

Nutzerdaten-Variable

Der Kern des Setups im GTM ist (mindestens) eine Variable vom Typ "Von Nutzern bereitgestellte Daten". Hier wird (wie gezeigt) entweder die gleiche Automatik wie beim Google-Tag verwendet oder es erfolgt eine manuelle Konfiguration bzw. eine Angabe der Nutzerdaten als JavaScript Objekt im passenden Format (Option "Code").

Wird dabei auf die Automatik gesetzt, kann man so bestenfalls dafür sorgen, dass der Klick auf einen Button o. Ä. zum Anlass genommen wird, die einem Formular enthaltenen Daten (ggf. erneut) auszulesen, wenn dazu ein Google Ads User-provided Data Event verwendet wird. Wer ohnehin im Tag Manager operiert, wird mindestens die manuelle Konfiguration wählen wollen, um Dinge wirklich zu verbessern.

Manuelle Konfiguration

Wer in der Variable selbst bestimmen will, woher eine Mailadresse, Telefonnummer oder Anschrift kommen soll, kann dazu im einfachsten Fall auf passende Datenschichtvariablen zugreifen, die eine Adresse aus einem Schlüssel im dataLayer entnehmen kann. Verwendet ein CMS dazu eine globale JS Variable, gibt es dazu einen passenden Variablentyp im Tag Manager. Oft genug aber stehen die Daten im DOM einer bestimmten Seite wie der Bestellbestätigung in einem Shop, Versandbestätigung eines Online-Formulars o. Ä.

Wenn beim Aufruf dieser Seite ein Ereignis an Ads gesendet oder eine Conversion ausgelöst werden soll, die diese Daten mitnimmt, kann eine (ggf. extra für diese Seite separat definierte) Nutzerdaten-Variable passend zum Aufbau der Seite angelegt werden.

Dabei gelten die gleichen Einschränkungen wie bei Google-Tag: Wer keine PLZ und Ort anbieten kann, kann die Konfiguration nicht speichern. Ein klares Signal, dass Google bei der Adresse die o. a. Mindestkonfiguration erfordert, um mit den Daten etwas anzufangen. Wer hier also eine undefined Variable zuordnet, kann zwar speichern, wird allerdings nichts damit erreichen und nur mit Mailadresse und / oder Telefonnummer punkten können.

Um z. B. die Mailadresse aus einem Element (sei es ein span, input oder was auch immer) mit der id echo-email aus dem DOM auszulesen, kann z. B. eine DOM Variable verwendet werden. Andere Felder sind ggf. mit einem CSS-Selektor erreichbar oder benötigen eine JS-Variable (für globale Variablen) oder ein Benutzerdefiniertes JavaScript zur Ermittlung der Mailadresse über komplexere Vorgänge.

Wenn hingegen der dataLayer als Quelle verwendet werden kann, kann mit einer passenden Variable eine Adresse aus einem beliebigen Datenschicht-Schlüssel gelesen werden.

Option "Code"

Spätestens bei Verwendung des dataLayer bietet es sich allerdings an, die Daten gleich in einem passenden Format bereitzustellen und den ganzen user_data-Block 1:1 per Datenschichtvariable auszulesen und hier als fertiges Objekt zu übergeben. Dazu dient die Option "Code".

Bei Daten aus dem DOM kann alternativ diese Methode verwendet werden, um nicht einzelne Felder per Option "Manuell" zu belegen, sondern ein fertiges Objekt zur Verfügung zu stellen. Dabei ist eine bestimmte Struktur erforderlich, in der in vorgegebenen Schlüsseln entweder Daten im Klartext oder - das ist der eigentliche Vorteil - als Hashwert zu finden sein müssen.

Ein weiterer Vorteil der Code-Methode ist die Tatsache, dass die o. a. "Mindestregel" nur vom UI durchgesetzt wird, wenn die manuelle Methode verwendet wird. Wer bei der "Code" Option nur Namen und Vornamen angibt, wird diese auch im Request finden. Dennoch gilt, dass unvollständige Daten (ggf. über die ganze Session hinweg in Teilen gesendet)vermutlich kaum einen Effekt haben werden, wenn es um die Zuordnung von Conversions geht. Das weiß aber nur Google selbst genau und die Hilfe schweigt sich zu solchen Details aus.

Felder für Enhanced Conversions

Folgende Daten können in den folgenden Schlüsseln im Code übergeben werden:

• E-Mail-Adresse: email (Klartext) oder sha256_email_address (gehashed). Dies ist das bevorzugte Feld.
• Telefonnummer: phone_number (Klartext) oder sha256_phone_number (gehashed). Sie muss im E.164-Format vorliegen (z. B. +11231234567).
• Vorname: address.first_name (Klartext) oder address.sha256_first_name (gehashed).
• Nachname: address.last_name (Klartext) oder address.sha256_last_name (gehashed).
• Straße: address.street oder address.sha256_street (gehashed... auch wenn nicht jede Hilfeseite das erwähnt)
• Stadt: address.city (nur Klartext).
• Region/Bundesland: address.region (nur Klartext).
• Postleitzahl: address.postal_code (nur Klartext).
• Land: address.country (nur Klartext, 2-stelliger Ländercode nach ISO 3166-1 alpha-2). Also nicht "Deutschland", sondern nur "DE"

Beispiel

Ein Beispiel eines solchen Objekts aus der Google Hilfe, welches mit einem formSubmitted-Ereignis in den dataLayer gepushed wird und dabei die Nutzerdaten im Key leadsUserData enthält:

  dataLayer.push({
    'event': 'formSubmitted',
    'leadsUserData': {
      'email': '[email protected]',
      'phone_number': '+11234567890',
      'address': {
         first_name: 'John',
         last_name: 'Doe',
         street: '123 Lemon',
         city: 'Some city',
         region: 'CA',
         country: 'US',
        postal_code: '12345',
       },
     },
  });

Mit einer Datenschichtvariable für leadsUserData kann so der ganze erforderliche Block ausgelesen und der Nutzerdaten-Variable über die Option "Code" bereitgestellt werden.

Hashing und Normalisierung

Egal ob als Hash oder Klartext: Wenn Formatvorgaben nicht eingehalten sind, wird es problematisch. Denn auch Daten ohne Hash als Eingangswert werden ja in vielen Fällen - und vor allem der Mail und der Telefonnummer - vor dem Versand in einen Hash umgewandelt und nicht als Klartext-Mailadresse etc. an Google gesendet.

Dennoch ist vor allem beim manuellen Hashing die Normalisierung wichtig, denn das kann die Nutzerdatenvariable nicht mehr selbst übernehmen. Wer Daten selbst hashen und dann in die Datenschicht schreiben will, muss diese vorher normalisieren. Das bedeutet z. B.

• Leerzeichen in der Telefonnummer (und im Fall führender oder nachfolgender Leerzeichen auch in allen anderen Daten) entfernen, Ländervorwahl hinzufügen (E.164-Format. Beispiel: +491771234567890)
• Kleinschreibung bei Mailadressen
• ein Sufffix mit einem + in der Mailadresse (nur bei Gmail-Adressen!) vorher entfernen, weil dieses nicht Teil der Hashwerte bei Google anhand dieser Gmail-Adresse sein wird. Gleiches gilt für Punkte. Eine eingegebene Mailadresse wie "[email protected]   " würde demnach zu "[email protected]"
• SHA256-Algorithmus im Hex-Format

Dies ist zu beachten, wenn Hashing entweder systemseitig erfolgen soll, so dass bereits ausschließlich gehashte Daten im dataLayer ankommen... oder wenn im GTM per JavaScript ein Objekt "zusammengebaut" wird.

Hinweis: Hex ist wie oben beschrieben die die Vorgabe für selbst gehashte Eingaben. Die Tags machen daraus aber gegebenenfalls Base64URL. Der Validator in der Chrome Extension prüft daher beide Encodings und zeigt die Variante als "pill" an.

Dank eines LinkedIn-Kommentars bin ich auf eine weitere typische Fehlerquelle hingewiesen worden, wenn die Validierung eines Klartext-Vergleichswertes für eine Telefonnummer in der Chrome Extension Alarm schlagen sollte: Google benötigt eine Telefonnummer inkl. führendem "+" vor der Länderkennung. Meta hingegen nicht. Wenn eine Telefonnummer also z. B. "+49 177-123 4567 890" lautet, ist diese nach Normalisierung für Google Ads zu "+491771234567890" geworden. Für Meta hingegen ist der passende Eingangswert "491771234567890". Da beide unterschiedliche Hashwerte ergeben, kann es sein, dass man nur den "falschen Hash" aus der Datenschicht gelesen hat, um diese an Google Ads zu senden. Wer beide Dienste bedienen will und mit Hash statt Klartext arbeitet, wird vermutlich beide Formate in unterschiedlichen Keys im dataLayer vorhalten. Oder besser: Das sollte so sein, denn sonst erhält einer der Empfänger keine passenden Daten. Es fällt nur vermutlich kaum auf, weil Telefonnummern einen geringeren Effekt haben im Vergleich zu Mailadressen.

Das "Google Ads User-provided Data Event" Tag

Seit einiger Zeit schon bietet der GTM ein eigenes Tag an, um die so in einer Variable gesammelten Daten zu übertragen: Das Google Ads User-provided Data Event (oder hier kurz: UPD-Event). Hierin wird - wie bei einer Conversion - eine Conversion ID (die für ein Konto stets gleich ist, so dass dazu keine neue, eigene Conversion mit eigenem Label angelegt werden muss) eingetragen. Dazu wird die / eine Nutzerdaten-Variable zugewiesen und das Ganze bei einem passenden Trigger ausgelöst. Dieser Trigger ist so zu wählen, dass sichergestellt ist, dass die Nutzerdaten tatsächlich vorhanden sind (aus dem DOM oder der Datenschicht).

Ein typisches Beispiel sind Schritte in einem Checkout oder mehrstufigen Formular, nach dem Login oder zu anderen Zeitpunkten, zu denen Nutzerdaten (erstmals) verfügbar sind, ohne dass bereits eine separate Google Ads Conversion ausgelöst werden müsste. Soll z. B. nach einem Login ein Ereignis an GA4 gehen, aber keine eigene Ads Conversion, ist das Auslösen eines UPD-Events für Google Ads eine gute Option.

Auch bei einer Ads Conversion ist das parallele Triggern eines UPD-Events eine Option. Diese mag dann sinnvoll sein, wenn mit der Conversion zahlreiche Produktdaten etc. an Ads gesendet werden und man sicherstellen will, dass der Request nicht zu groß wird. In 99% der Fälle können die Daten genauso gut direkt an die Conversion "gehängt" werden.

Nutzerdaten an Ads Conversions

Um einer Conversion die Informationen aus der Nutzerdaten-Variable zuzuweisen, wird - genau wie bei einem GA4-Ereignis - ein Ereignisparameter namens user_data verwendet. Wird dieser angegeben, sind ausschließlich Nutzerdaten-Variablen zu verwenden.

Wenn zum Zeitpunkt der Conversion Nutzerdaten verfügbar sind, werden diese den Browser gemeinsam mit der Conversion als em-Parameter verlassen - genauso, wie es bei einem UPD-Event-Tag der Fall wäre oder wenn das Google-Tag eine Mailadresse o. Ä. automatisch erkannt hat.

Nutzerdaten an GA4 Events hängen

Auf gleichem Weg (als Ereignisparameter) kann jedes beliebige GA4-Ereignis genutzt werden, um Nutzerdaten zu versenden. Ausgehende Requests an den /collect-Endpunkt von Google Analytics direkt aus dem Browser kann der Validator erkennen und zeigt diese gemeinsam (wenn nicht deaktiviert) mit den Google Ads Requests an, wenn Nutzerdaten anhängen.

Aber erscheint hier nichts, muss das ausnahmsweise nicht bedeuten, dass es nicht dennoch funktioniert. Der Grund ist rein technisch: meine Browser Extension soll nicht einfach für alle Domains Rechte zum Zugriff auf den Netzwerkverkehr anfordern. Das ist der Grund, warum der Recorder explizit Berechtigungen anfordert, bevor die Aufzeichnung stattfinden kann. Wenn also Mittel wie ein "Custom Loader", das Google Tag Gateway oder ein anderer First Party Endpunkt via server-side GTM im Einsatz ist, "sieht" die Chrome Extension diese Requests daher nicht. Die Lösung: Ausnahmsweise statt der Extension doch auf den Tag Assistant setzen oder direkt im Netzwerkverkehr nach &em= filtern, wenn nicht die Standard-Endpunkte im Spiel sind. Funktioniert die Weitergabe, wird man dort die Google Analytics Ereignisse inkl. des Parameters finden. Die Verifikation korrekter Daten mittels Klartextvergleich funktioniert dann wie oben bei den automatischen Events beschrieben durch Copy & Paste dennoch.

Ein anderer wesentliche Unterschied bei Gooogle Analytics ist, dass die zusätzliche Übergabe als "echte" Ereignisparameter (ep.xxx) nur dann stattfindet, wenn ein serverseitiger Google Tag Manager im Einsatz ist und als Empfänger der Daten dient. Wer GA4-Ereignisse allerdings direkt aus dem Browser an Google sendet, wird die Ereignisparameter wie ep.user_data.email, ep.user_data.address.name etc. umsonst suchen: Das Google-Tag verwirft diese beim Versand. Der Grund ist, dass GA4 hier nur als Datenlieferant für den ssGTM dient, wo wiederum die Nutzerdaten von serverseitigen Ads Tags, der Meta CAPI und anderen "Verbrauchern" verarbeitet werden können. Direkt über GA4 ohne ssGTM einen purchase an GA4 zu senden und diesen inkl. Nutzerdaten in Ads zu importieren, ist trotzdem möglich, da die Attribution nicht an diese Ereignisparameter, sondern den em-Parameter gebunden ist.

Voraussetzung für die Nutzung dieses Weges (senden als em-Parameter) ist wie bei Google Ads die Aktivierung in den Einstellungen des Google Tags beim Datenstream für die Google Analytics Property, welche zudem (logisch) mit dem Google Ads Konto verbunden sein sollte (was allerdings bei Fehlen nicht verhindert, dass dennoch em-Parameter  entstehen).  Wesentlich ist vor allem die Aktivierung der Option zur "Erhebung der von Nutzern bereitgestellten Daten" in der GA Property:

Ist diese nicht aktiv, wird es bestenfalls über den Umweg eines serverside GTM gehen. Einen em-Parameter wird man aber vergeblich suchen.

Was man allerdings vor der Aktivierung bedenken sollte: Wenn mit User-IDs bereits gearbeitet wird (vor allem für BigQuery relevant!), hat die Aktivierung dieser Funktion unschöne Auswirklungen auf die Daten in BigQuery: Die User-ID wird nach dem Einschalten gar nicht mehr nach BQ exportiert und nicht nur dann, wenn diese auf Hashwerten basiert!

Die gesendeten Nutzerdaten haben zudem offensichtlich, wenn aktiviert, Vorrang vor der eigentlichen User-ID (warum auch immer). Da der Schaden für die User-ID in BQ nicht durch einfache Deaktivierung reversibel scheint, wenn der Stand der  Warnung von Simo Ahava dazu auf LinkedIn noch Bestand haben sollte, ist deshalb genau abzuwägen, ob die Verwendung von GA4 als Lieferant für Nutzerdaten wirklich sinnvoll ist. Selbst der folgende Hinweis in der Google-Hilfe zu diesem Feature macht wenig Hoffnung, wenn man bedenkt, dass 2025 danach nichts mehr passiert zu sein scheint: "Updates, die diese Überlegungen berücksichtigen, werden im Laufe des Jahres 2025 nach und nach veröffentlicht, bevor die Funktion zur Erhebung der von Nutzern bereitgestellten Daten mit „General Availability“ gekennzeichnet wird.". Passiert ist aber nichts und Stand heute ist immer noch ein "Beta"-Label an dieser Option. Weißt Du mehr? Dann sende mir gern einen Hinweis, damit dieser Abschnitt nicht in die Irre führt.

So oder so erscheint es mir aber empfehlenswert, Google Analytics angesichts der zahlreichen Dinge, die bei der Attribution von Traffic aus Google Ads dort schieflaufen können, GA4 nicht als Lieferant für primäre Makro-Conversions zu verwenden, sondern dafür ein separates Google Ads Tagging zu implementieren. Entweder im Client oder "am Server" (obgleich auch diese Variante nicht ohne Requests aus dem Browser auskommt).

Wann user_data für das Google-Tag sinnvoll ist

Kurze Antwort: Meistens nicht. Wenngleich ein (Google Ads oder Google Analytics) Google-Tag ebenfalls Ereignisparameter entgegennimmt, die für den automatisch versendeten page_view und alles andere verwendet werden, was im Bereich "Optimierte Analysen" beim Datentream aktiviert ist und vom Google-Tag versendet wird, sind beim Auslösen des Tags selten bereits irgendwo Nutzerdaten vorhanden. Jedenfalls nicht bei jedem Seitenaufruf. Dass es sich im Einzelfall dennoch lohnen kann (je nach Setup kann dies in einer Single Page Application z. B. der Fall sein), ist unstrittig. Dennoch bleibt ein separates Google-Ads-Tagging mittels UPD-Tags und Conversions im GTM der beste Weg, um Google Ads wirkungsvoll mit Daten zu bedienen.

Validierung

Auf welchem Weg ein em-Parameter für Google Ads entstehen mag und egal, ob er an einem UPD-Event oder einer Conversion hängt: Kontrolle ist nicht immer einfach. Im Tag Assistant kann wie oben beschrieben der Parameter "manuell" kontrolliert werden... oder über die Chrome Extension. Gerade bei mehreren Tags, die kontrolliert werden sollen, ist die Extension eine gute Hilfe, denn es gibt eine Funktion zum Aufzeichnen aller entsprechenden Requests.

Wenn die Erweiterung angeklickt wird, wird dazu für die Domain des akt. Tabs eine Freigabe zum Aufzeichnen mittels "Permit & Record" gegeben. Danach können die entsprechenden Schritte auf der Website durchgeführt werden. Alle Requests für Conversions und UPD-Events (je nach Option zusätzlich diejenigen ohne Nutzerdaten) werden dabei als "Karten" im unteren Bereich gesammelt.

Zur Erinnerung: Üblicherweise gehen mehrere Requests raus (pagead/form-data (ohne em) vs. ccm/form-data (mit em+ecsid). Bei Conversions sieht man zusätzlich Anfragen an pagead/conversion/, ccm/conversion/, pagead/1p-conversion/ mit vollem em-Parameter.

Die enthaltenen Nutzerdaten werden als Kürzel angegeben. Ein Klick auf die Karte öffnet die akt. Parameter oben im Decoder, der wiederum genutzt werden kann, um die Daten gegen "Solldaten" in Klartextfeldern zu verifizieren, wenn gewünscht. Ein Klick auf das "i" oben rechts öffnet eine Detailansicht aller Request-Parameter. POST Nutzlasten werden zusätzlich ausgewertet, obschon ich noch keinen Fall gesehen habe, wo Nutzerdaten nicht direkt als Parameter zu finden waren. Was denkbar ist (wenn nicht heute, dann morgen): Moderne Browser erlauben den Versand von Requests über Worker. Deren Aktivität ist nicht direkt im Network-Tab zu sehen und wäre auch für die Extension unsichtbar.

Eine finale Verifikation liefert ohnehin der Reiter "Diagnose" bei den Conversions im Google Ads Konto. Für die Kontrolle der Implementierung ist die Extension m. E. deutlich hilfreicher als die Google-eigene Erweiterung EC-Assist, welche zwar Conversions auf ähnliche Weise unter die Lupe nimmt, aber eben leider nur Conversions und keine UPD-Events oder vom Google-Tag erzeugte Nutzerdaten-Requests.

Wenn es nicht funktioniert: Objekt-Analyse

Ein weiterer Reiter in der Erweiterung erlaubt eine ähnliche Analyse der Daten, schon bevor ein Tag feuert. Speziell für einen Fall, in dem also alles okay zu sein scheint und dennoch der gewünschte em-Parameter fehlt, kann man hierüber sowohl Objekte aus dem dataLayer, ganze dataLayer-Pushes oder den Inhalt einer Nutzerdaten-Variable aus dem Tag Assistant hier in ein Textfeld kopieren und die Daten auslesen und kontrollieren. Wie beim EM-Decoder gibt es Textfelder für Klartext zur Überprüfung korrekter Hashwerte, wenn vorhanden. Fehlende Angaben oder Formatfehler werden moniert und helfen so bei der Zusammenstellung gültiger Nutzerdaten.

Hier kann ein einzelner Schlüssel aus der Datenschicht, ein kompletter dataLayer-Push oder der Inhalt einer Variable (auch der Nutzerdaten-Variable wie hier im Screenshot) inkl. der durch "+" getrennten Feldwerte eingegeben werden. Erkennt der Validator Probleme, werden entsprechende Fehler oder Warnungen ausgegeben. Auch Formatunterschiede wie das Array, das bei der Nutzerdaten-Variable stets um Adressen-Blöcke gelegt wird, werden sauber erkannt. Die Prüfung deckt Mindestanforderungen ebenso ab wie typische Formatfehler, wenn Hash-Werte mit Klartexteingaben vergleichen werden. Auch die o. a. Falle des unterschiedlichen Hash-Formats für Telefonnummern bei Google vs. Meta wird geprüft und ggf. ein Hinweis ausgegeben:

Dieses Array kann übrigens schon in den Eingangsdaten per Code verwendet werden, um mehrere Adressen (zwei) zu übergeben. Wie bei Verwendung des Measurement-Protocol können mehrere Mailadressen oder Telefonnummern (je bis zu drei) angegeben werden (siehe Hilfe). Ein entsprechendes Beispiel für ein solches Nutzerdaten-Objekt, das auch im Browser funktioniert:

{
  sha256_email_address: [
    "[email protected]", 
    "[email protected]", 
    "[email protected]"
  ],
  sha256_phone_number: [
    "+49791234567", 
    "+49791234560", 
    "+41791234568"
  ],
  address: [{
    first_name: "Hans",
    last_name: "Wurst",
    street: "Strasse 1",
    city: "Stadthausen",
    region: "NRW",
    postal_code: "41234",
    country: "DE"
  },{
    first_name: "Franz",
    last_name: "Käse",
    street: "Am Bahnhof 42",
    city: "Musterstadt",
    postal_code: "01234",
    country: "DE"
  }]
}

Solche Konstruktionen können als Objekt oder "em"-Parameter im Tool verifiziert werden und führen in Tests auch zu Nutzerdaten in ausgehenden Requests. Wer aber wirklich mehrere Varianten eines Typs aus dem Browser senden will, sollte allerdings gewarnt sein: In meinen Tests kamen je nach Bestückung ausgerechnet Mailadressen nicht zuverlässig in den Nutzlasten der Requests an! Besonders hier lohnt es sich demnach, alle denkbaren Varianten ausführlich zu testen. Typischerweise werden zum Glück jeweils "nur" eine Mailadresse etc. zur Verfügung stehen.

Gut zu wissen: Wer hier wie im Beispiel Klartext-Daten (z. B. Mailadressen) nicht als email_address, sondern sha256_email_address anliefert, wird dennoch die korrekten Daten im ausgehenden Request finden. In meinen Tests war dies die beste Möglichkeit, mehr als eine Mailadresse und Telefonnummer wirklich in die Requests zu bekommen. Das kann aber bestenfalls als "Hack" dienen und nicht als Empfehlung. Die muss lauten: Wer mehrere Mailadressen oder Telefonnummern senden will, sollte offenbar nicht nur die "sha256_*"-Varianten der Felder verwenden, sondern darin auch wirklich Hashwerte statt Klartext übergeben.

Sollte das alles nicht helfen, hilft nach meiner Erfahrung nichts außer der Kontrolle der oben angegebenen Voraussetzungen, speziell die Einstellung im Ads Konto und vollständig passend initialisierter Google Consent Mode. Und Nein: nur ad_storage reicht nicht!

Verschlüsselt statt Hash: Der eme-Parameter

Unter gewissen Umständen mag der em-Parameter tatsächlich fehlen, obschon alles im Objekt in Ordnung zu sein scheint, alle Einstellungen passen. Und tatsächlich fließen Nutzerdaten in Richtung Google Ads. In diesem Fall kann ein anderer Parameter zum Einsatz kommen, der auf den ersten Blick ähnliche Daten enthält - aber nur auf den ersten Blick. Dies ist der eme-Parameter. Das "e" wird wohl für "encrypted" stehen, denn anders als beim Hash kann auch ein bekannter Wert nicht gegen diese Daten gehalten werden, um sie zu verifizieren. Stattdessen sendet Google "sich" in diesem Parameter eine eindeutige ID (UUID), die (vermutlich) einen serverseitigen Schlüssel referenziert und der Rest der Nutzlast dieses Parameters ist dann die verschlüsselte (nicht nur gehashte) Information.

Unter welchen Bedingungen Google diese zusätzliche Maßnahme ergreift, ist (mir) unklar. Es scheint aber z. B. nur dann möglich zu sein, wenn ein First Party Endpunkt im Spiel ist. Das kann ein Google Tag Gateway im Same-Origin Betrieb sein. Möglicherweise auch mit einem serverseitigen GTM bei gleichem Setup. Auf einer Subdomain betrieben habe ich zumindest nie einen eme-Parameter gesehen. Wenn er aber auftritt und dies in einem "echten" Unterordner auf der untersuchten Domain passiert, wird der EC Data Validator dies mitbekommen und als First Party Request farbig leicht hervorheben. In diesem Beispiel sieht man, wie drei Requests versendet werden, zwei direkt an Google und einer an den eigenen Endpunkt. Alle drei nutzen das abweichende Format mit dem eme-Parameter, die Web-Requests aber unterschiedliche UUID und Payloads als der First-Party-Request. Was drin steckt? Only Google knows!

Warum "Chatty" kaum Hilfe leistet

Das meine ich wirklich ernst. Wenn etwas nicht funktioniert, muss es an einer der oben angesprochenen Voraussetzungen liegen. Wer hingegen den KI-Assistenten seiner Wahl fragt, bekommt nach akt. Stand (Mai 2026) eher unsinnige Tipps und Hinweise, die als Debugging-Hilfe angeboten werden, um meine bzw. Deine Zeit zu verschwenden. Ein paar Highlights:

• Behauptung: "Du musst vorher ein Google-Tag für das Ads Konto feuern". Falsch. Wenn man im Tag Manager explizit ein Nutzerdaten-Tag verwendet oder user_data bei einer Conversion verbaut, geht das auch ohne Google-Tag. Sei es für GA4 oder Ads - ich habe es probiert. Nur das "UPD Tag" allein reicht zum Beispiel aus... was kein Wunder ist, weil Google-Ads Tags aller Art vor dem Feuern ein ggf. noch nicht im GTM aktiv geladenes gtag.js für das entsprechende Konto laden (müssen).
• Behauptung: allow_enhanced_conversions muss auf true gesetzt werden im Google-Tag. Aha. Weil es nachweislich ohne Google-Tag geht: Kann nicht stimmen. Da ich selbst dann Daten senden kann, wenn dieser Parameter in einem vorher feuernden Google-Tag auf false steht, ist die Info offenbar unrichtig, selbst wenn sie direkt aus der Google Hilfe stammt (was nicht unbedingt ein Qualitätskriterium sein muss).
• Behauptung: Wenn ads_data_redaction auf true gesetzt wurde im Google-Tag, geht nichts raus. Das ist ebenso unrichtig. Oder besser: nur bedingt richtig. Da wir alle am Consent Mode nicht mehr vorbeikommen und ad_storage Vorrang vor dieser Einstellung hat, ist sie faktisch zahnlos.

Ebenso in der Google-Hilfe finden sich Beispiele mit falschen Aussagen dazu, ob eine Straße nun als Hash angeliefert werden darf/ soll oder nicht. Oder man kopiert Code aus der Hilfe und wundert sich, warum man nachher mit einem sha265_first_name statt sha256_first_name nichts erreicht.

"Debugging-Tipps" wie "schau in der Konsole nach window.google_tag_data.user_data oder google_tag_manager["GTM-xxxxxxx"].dataLayer.get("google_tag_params")" führen selbst dann zu nichts, wenn das Senden funktioniert hat. Ich habe keine Ahnung, ob das mal anders war, aber hier und heute bekomme ich auch bei funktionierenden Setups nichts als undefined zu sehen.

Also: Lieber bei den Basics nachschauen und nicht auf Zauberparameter hoffen.

Warum überhaupt im Browser?

Wer kein rein clientseitiges Tracking-Setup verwendet, hat die valide Option der Anreicherung mit Nutzerdaten hinter dem Browser und vor dem Versand an Google. Dazu dient z. B. ein serverseitiger Google Tag Manager als First-Party-Zwischenschicht. Dazu ist es allerdings erforderlich, die Nutzerdaten zur Anreicherung irgendwoher zu beziehen.

Üblicherweise geschieht dies anhand eines Schlüssels (Cookiewert, Transaktions-ID des gerade getätigten Kaufs o. Ä) direkt per API aus dem CRM oder über "nah am Server" gespeicherte Daten wie z. B. in einer Firestore Datenbank. Wenn ein CMS eine Conversion nebst Nutzerdaten direkt per Measurement Protocol an einen ssGTM versenden will, kann (vermutlich) das oben angesprochene Format verwendet werden, um dabei mehrere Nutzerdaten-Varianten in Arrays als Referenz zu versenden (ich habe es nicht ausprobiert).  Dieses Thema ist allerdings ohnehin einen eigenen Blogpost wert und soll hier deshalb nur der Vollständigkeit erwähnt bleiben. Nicht zuletzt deshalb, weil sonst das folgende Thema nicht vollständig wäre:

Datenschutz

Es ist zu bedenken, dass die Datenschicht eine "öffentliche" Fläche ist. Während es für Besuchende im eigenen Browser sicher kein großes Problem darstellt, dass die eigene Mailadresse nach Anmeldung ggf. in einer Javascript-Variable oder der Datenschicht landet, gibt es zahlreiche Scripts von Drittparteien, die i. d. R. in diesem Browser ausgeführt werden. Jedes dieser Scripts kann all diese Daten lesen und "nach Hause senden", ohne dass man es unbedingt mitbekommt oder verhindern kann. In der Vergangenheit sind mehrfach Anbieter von Trackingtechologien mit genau diesem Verhalten aufgefallen.

Kein Wunder also, dass datenschutzbeauftragte Personen in Unternehmen oft Bedenken haben. Hier kommt der Unterschied zwischen Klartext und Hash zum Tragen: Während eine Mailadresse im Klartext für jeden einen Wert hat, der sie in die Hände bekommt, muss für einen Hash bereits ein eigener Datensatz bestehen, der zu diesem Hash passt, um mit den Informationen ein Profil anzureichern oder was auch immer anzustellen.

Verständlich also, dass eine Anreicherung mit Nutzerdaten, die erst an einem Server stattfindet (CAPI Direktintegrationen in Systeme, serverseitiger Google Tag Manager mit Firestore oder andere Lösungen) als datenschutzfreundlicher betrachtet werden. Dafür sind sie zweifelsohne technisch aufwändiger. Und wie oben gezeigt, fließen oft durch das Google-Tag bereits Nutzerdaten aus dem Browser zu Google und anderen.

Daher sollte man solche Tags nicht ohne Zustimmung ausspielen. Im Fall von Google "erledigt" sich die Weitergabe der Daten allein schon wegen der Anforderungen an Consent Mode Flags. Meint: im "erweiterten Zustimmungsmodus" fließen zumindest keine Nutzerdaten über Google Ads Tags aus dem Browser. So oder so ist die Verarbeitung der Mailadresse etc. sicher in Datenschutzhinweisen aufzunehmen. Daher ist eine Absprache mit den zuständigen Datenschutzmenschen im eigenen Laden unerlässlich vor einem Einbau! Selbst wenn es bisher ggf. schon ohne Kenntnis über die Automatik stattgefunden haben mag: Je nach Einschätzung muss das Thema im Consent Dialog und / oder Datenschutz behandelt werden, bevor es live geht. Daher nicht "einfach einbauen" (lassen), sondern den Umfang genau bestimmen und dabei berücksichtigen, ob Hash oder Klartext als Eingangswert genutzt werden und ob die Anreicherung im Browser oder am Server passiert. Bei aller Technik sind in diesem Fall Aspekte wie diese keine "Kleinigkeit", sondern mitunter entscheidend, ob man grünes Licht bekommt oder nicht.

Fazit

Erweiterte Conversions mit Nutzerdaten sind bei richtiger Einrichtung sowohl mit dem Datenschutz zu vereinbaren, als auch durchaus nützlich. Jedenfalls dann, wenn man sich mehr Mühe gibt, als nur eine auf Automatik gestellte Nutzerdaten-Variable im Tag Manager zu verwurschteln, nur um "erledigt" rufen zu können. Wenn im Ads Konto zu wenig los ist, werden Enhanced Conversions das Ruder nicht rumreißen. Ab einem gewissen Volumen sind selbst geringe Zugewinne wertvoll, wenn dadurch Kampagnen besser gesteuert werden können. Ob dabei kaum 5% oder die von Google oft versprochenen zweistelligen Zuwachsraten anfallen, hängt ganz davon ab, wie flächendeckend Nutzerdaten in das Tracking einfließen können. Mailadressen sind der größte Hebel, sind allerdings nicht bei jeder Website (für einen nennenswerten Anteil der Besuchenden) bekannt. Schon gar nicht, wenn man Neukunden per Google Ads adressiert, ohne dass ein hürdenarmer Grund besteht, seine Mailadresse preiszugeben. Genau deshalb heißt es "Freebie, Testzugang oder Whitepaper gegen Business-Mailadresse" auf vielen Google Ads Landingpages 😉