Enhanced Conversions mit HubSpot und GTM einrichten – falscher vs. richtiger Trigger, Data Layer und em-Parameter

Enhanced Conversions mit HubSpot-Formularen in GTM richtig einrichten – warum es komplizierter ist als gedacht

Mit Enhanced Conversions soll die Qualität der Leads aus Google Ads verbessert werden. Das ist in aller Regel schnell eingerichtet. Ganz sieht es aus, wenn mehrseitige Hubspot-Formulare eingesetzt werden. So schreibt zum Beispiel User Rebshu im Hubspot-Forum: “I’ve been struggling to set up Google Enhanced Conversions in Hubspot.” Verständlich, denn wider Erwarten ist das überraschend kompliziert. Und ich musste eine Weile tüfteln. Doch ich habe eine robuste Lösung gefunden. Diese findest du hier.

Was Enhanced Conversions überhaupt macht

Kurze Wiederholung für alle, die direkt zur Praxis wollen: Mit Enhanced Conversions for Web von Google wird dein bestehendes Conversion-Tracking verbessert. Dabei werden beim Form-Submit die E-Mail-Adresse aus dem Lead-Formular (und optional Name/Telefon) gehasht und an Google gesendet wird. Google matcht diesen SHA256-Hash mit eingeloggten Google-Accounts und kann so Conversions zuordnen, die durch Cookie-Verlust (iOS, Firefox, Ad-Blocker) sonst verloren gehen würden.

Wichtig: Das ist Enhanced Conversions for Web – nicht zu verwechseln mit Enhanced Conversions for Leads, das für Offline-Conversion-Uploads via CRM gedacht ist. Der Unterschied:

Enhanced Conversions (Web) Enhanced Conversions for Leads
Conversion-Zeitpunkt Online, sofort Offline, später
Zweck Bessere Attribution bei Cookie-Verlust Online-zu-Offline-Tracking
Datenfluss Website → Google (gehasht) Website → CRM → Google (Upload)
Typischer Use Case Direkte Leads, E-Commerce B2B Sales, längere Sales Cycles

Allerdings ist im Fall von mehrseitigen Hubspot-Formularen die Anleitung unbrauchbar. Die offizielle Google-Dokumentation reicht für HubSpot-Formulare schlicht nicht aus.

Voraussetzungen

  • Google Ads mit aktivierten Enhanced Conversions for Web (unter Ziele → Conversion-Einstellungen)
  • GTM auf der Website
  • HubSpot-Formular als Embed (nicht native HubSpot-Seite)
  • Das HubSpot-Formular pusht bereits Daten in den dataLayer – dazu gleich mehr

Warum nicht einfach die native HubSpot-Integration verwenden?

Berechtigte Frage. HubSpot hat tatsächlich eine native Google Ads Integration – und die unterstützt auch Enhanced Conversions. Aber es gibt drei wichtige Einschränkungen:

1. Nur für Marketing Hub Pro und Enterprise
Die Enhanced Conversions Funktionalität in HubSpot ist nicht für alle Kunden verfügbar. Wer Marketing Hub Starter oder Free nutzt, hat keine native Option.

2. Falscher Use Case
Die native HubSpot-Integration implementiert primär Enhanced Conversions for Leads – also das Zurückspielen von CRM-Daten (Lifecycle Stage-Änderungen) zu Google Ads. Das ist nützlich, um Google zu sagen “dieser Lead ist jetzt ein Kunde geworden” – aber es ist nicht dasselbe wie Enhanced Conversions for Web, die wir hier aufbauen.

Enhanced Conversions for Web passiert im Moment der Form-Submission im Browser und verbessert die Attribution von Klicks auf Conversions. Das ist ein anderer Mechanismus, der nicht durch die native HubSpot-CRM-Integration abgedeckt wird.

3. Bekannte Probleme
In der HubSpot Community gibt es zahlreiche Berichte über Schwierigkeiten mit der nativen Integration – und der häufigste Ratschlag ist, GTM als zuverlässigere Alternative zu verwenden.

Fazit: Was wir hier aufbauen ist kein komplizierter Umweg – es ist schlicht die direkteste und zuverlässigste Methode für Enhanced Conversions for Web mit HubSpot-Formularen, unabhängig vom HubSpot-Abo.

Schritt 1: Prüfen, was im dataLayer steht

Bevor du irgendwas baust: GTM Preview öffnen, Formular absenden, und beim form_submission-Event in der Datenschicht nachschauen. HubSpot-Embeds pushen nämlich von Haus aus bereits ein ordentliches form_submission-Event mit allen Feldern:

dataLayer.push({
  event: "form_submission",
  form_id: "...",
  conversion_id: "...",
  form_data: {
    email: "user@example.com",
    firstname: "Max",
    lastname: "Mustermann",
    // ... weitere Felder
  }
})

Das bedeutet: Du brauchst keinen eigenen Listener-Tag. Die E-Mail ist bereits unter form_data.email verfügbar.

Schritt 2: Data Layer Variable anlegen

In GTM eine neue Variable anlegen:

  • Typ: Datenschichtvariable
  • Name der Datenschichtvariable: form_data.email
  • Version: Version 2

GTM löst den Punkt-Pfad automatisch auf. Variable sinnvoll benennen, z.B. DLV - HubSpot Form Users Email.

Schritt 3: Die „Von Nutzern bereitgestellte Daten”-Variable konfigurieren

Neue Variable anlegen:

  • Typ: Von Nutzern bereitgestellte Daten
  • Type: Manual configuration
  • E-Mail: {{DLV - HubSpot Form Users Email}}

Benenne diese Variable am besten enhanced conversions (ohne geschweifte Klammern) – also so wie sie im Tag später referenziert wird. Das vermeidet Verwirrung in Schritt 4.

Vorname und Nachname könnten die Match-Rate leicht verbessern – aber nur wenn du auch Land und Postleitzahl mitgibst, sonst blockiert GTM das Speichern. Die E-Mail allein reicht für eine solide Match-Rate.

Ein kurzer Hinweis zur GCLID: Du könntest hier zusätzlich die Google Click ID mitgeben, was die Zuordnung in bestimmten Fällen verbessern kann. Pflicht ist das aber nicht – Google matcht primär über die E-Mail.

Schritt 4: Den richtigen GTM Tag-Typ für Enhanced Conversions wählen

Hier liegt der erste grosse Irrtum: Enhanced Conversions konfiguriert man nicht im bestehenden Conversion-Tag. Es gibt einen eigenen Tag-Typ:

Google Ads User-provided Data Event

Den findest du in GTM unter Tags → Neu → Google Ads → Google Ads User-provided Data Event.

Konfiguration:

  • Conversion-ID: Deine AW-XXXXXXX ID
  • Von Nutzern bereitgestellte Daten: {{enhanced conversions}} (oder wie auch immer du deine Variable oben genannt hast)

Schritt 5: Den richtigen Trigger verwenden – und warum das knifflig ist

Hier liegt der grösste Fallstrick bei HubSpot-Formularen. Es gibt zwei Formular-Typen mit unterschiedlichem Verhalten:

HubSpot Form Editor (neu)

Der neue Form Editor pusht form_submission mehrfach – einmal je Formular-Seitenwechsel (wenn der User auf “Weiter” klickt) und einmal bei der erfolgreichen finalen Submission am Ende:

  1. mechanism: "synthetic_click_start" – beim Klick auf “Weiter” zwischen den Schritten
  2. mechanism: "native_submit_start" – das sogenannte “native Submit-Event”: Der Browser versucht das Formular auf dem normalen Weg abzuschicken, HubSpot fängt das ab und verarbeitet es selbst weiter. Das ist ein technisches Zwischenereignis, kein echter Abschluss.
  3. Ohne mechanism – die echte finale Submission, erkennbar an der vorhandenen conversion_id

Wenn du einfach auf form_submission triggerst, feuert der Tag mehrfach. Das willst du nicht.

Die Lösung: Filtern auf conversion_id. Nur die echte finale Submission hat eine conversion_id.

Dafür eine neue Data Layer Variable anlegen:

  • Name: DLV - conversion_id
  • Datenschichtvariablenname: conversion_id
  • Version: Version 1 (wichtig – liest den aktuellen Push, nicht den kumulativen State)

Dann den Trigger konfigurieren:

  • Typ: Benutzerdefiniertes Ereignis
  • Ereignisname: form_submission
  • Filter 1: {{DLV - conversion_id}} stimmt überein mit regulärem Ausdruck .{5,}
  • Filter 2: {{DLV - conversion_id}} ist nicht gleich null
  • Filter 3: {{DLV - conversion_id}} ist nicht gleich undefined

Warum drei Bedingungen? GTM wandelt JavaScript-Werte wie null und undefined in Strings um – "null" hat 4 Zeichen, "undefined" hat 9 Zeichen. Ohne die expliziten Ausschlüsse würden diese Werte den RegEx-Filter passieren und den Tag fälschlicherweise auslösen.

HubSpot Legacy Form Editor

Der Legacy Form Editor verhält sich komplett anders – er pusht kein form_submission Event, sondern hubspot-form-success, und zwar nur einmal bei erfolgreicher Submission:

dataLayer.push({
  event: "hubspot-form-success",
  "hs-form-guid": "952f8b71-00ad-448d-914f-2b7e48692bd9"
})

Dafür einen separaten Trigger anlegen:

  • Typ: Benutzerdefiniertes Ereignis
  • Ereignisname: hubspot-form-success
  • Alle benutzerdefinierten Ereignisse (kein Filter nötig)

Beide Trigger bei allen Tags eintragen

Beide Trigger – form_submission mit Filter und hubspot-form-success – müssen als auslösende Trigger bei allen relevanten Tags eingetragen werden (GA4, Google Ads Conversion, Enhanced Conversions, Bing etc.). GTM verknüpft sie automatisch mit “ODER”.

Schritt 6: Auch den Conversion-Tag auf denselben Trigger umstellen

Das ist der Schritt, der in keiner Anleitung steht: Der Google Ads Conversion-Tag und der User-provided Data Event Tag müssen gleichzeitig feuern – auf demselben Event. Sonst kann Google die Nutzerdaten nicht mit dem Conversion-Hit verknüpfen, und der em-Parameter bleibt leer.

Was ist der em-Parameter? Das ist der Parameter im Google Ads Request, der den gehashten E-Mail-Wert enthält. Google sendet beim Conversion-Hit im Hintergrund einen Request an googleadservices.com – und in diesem Request steckt unter dem Key em der SHA256-Hash der E-Mail. Nur wenn dieser Parameter befüllt ist, weiss Google, welchem User die Conversion zugeordnet werden soll.

Also: Alle Conversion-Tags (GA4, Google Ads, Bing etc.) auf die neuen Trigger umstellen – sowohl form_submission mit Filter als auch hubspot-form-success für Legacy-Formulare.

Verifikation in den DevTools

Nach dem Publishen: Formular absenden, DevTools öffnen, Netzwerk-Tab, “Protokoll beibehalten” aktivieren (wichtig, sonst verschwinden die Requests beim Redirect auf die Danke-Seite), Filter auf googleadservices, dann die Suchfunktion (Lupe oben links im Netzwerk-Tab) und nach em suchen.

Du wirst wahrscheinlich eine längere Liste von Treffern sehen – em taucht in vielen Requests auf, meist mit dem Wert tv.1 ohne weiteres Anhängsel. Das bedeutet: der Parameter wird zwar gesendet, aber leer. Du musst jeden Eintrag einzeln anklicken und in der Nutzlast nachschauen, was nach tv.1 kommt.

Was du sehen willst:

em: tv.1~em._chKJ_GFbgym3SZhprgYYmX...

Der Wert beginnt mit tv.1~em. gefolgt von einem langen String. Das ist der SHA256-Hash der E-Mail, URL-safe Base64-kodiert. Diesen findest du typischerweise im fetch-Request des User-provided Data Event Tags.

Zur Verifikation: Den SHA256-Hash der E-Mail auf emn178.github.io/online-tools/sha256.html generieren (Output: Hex Lower Case), dann auf base64.guru/converter/encode/hex in Base64 umrechnen. Google ersetzt / durch _ und lässt das abschliessende = weg – das ist URL-safe Base64 und völlig korrekt.

Wenn nur tv.1 ohne langen Hash-String steht: Die Variable war zum Zeitpunkt des Tag-Feuerns leer.

Zusammenfassung der Fallstricke

Problem Ursache Fix
E-Mail nicht im dataLayer Falsches Event oder falscher Zeitpunkt Auf form_submission triggern, nicht gtm.formSubmit
Tag feuert mehrfach HubSpot Multi-Step pusht form_submission mehrfach Filter auf conversion_id mit drei Bedingungen
null oder undefined matcht RegEx GTM wandelt JS-Werte in Strings um Explizit ist nicht gleich null und ist nicht gleich undefined als Filter
em bleibt leer Conversion-Tag und User-provided Data Tag feuern auf verschiedenen Events Beide auf denselben Trigger umstellen
Variable lässt sich nicht speichern Vorname/Nachname ohne Land/PLZ Nur E-Mail verwenden
Legacy-Formulare werden nicht erfasst Legacy Form Editor pusht hubspot-form-success statt form_submission Zusätzlichen Trigger für hubspot-form-success anlegen
tv.1 ohne Hash Nutzerdaten nicht verfügbar zum Feuerzeitpunkt Trigger-Reihenfolge prüfen

Fazit

Bei Standard-Setups ist Enhanced Conversions wirklich schnell eingerichtet. Bei HubSpot-Formularen kommen ein paar HubSpot-spezifische Eigenheiten dazu, die in der offiziellen Google-Dokumentation nicht vorkommen. Die wichtigsten Punkte: form_submission mit dreifachem conversion_id-Filter für den neuen Form Editor, hubspot-form-success für Legacy-Formulare, und beide Tags müssen auf denselben Trigger – nicht gtm.formSubmit.

Nach 48–72 Stunden kannst du in Google Ads unter Ziele → Conversion-Aktionen → Diagnose prüfen, ob Enhanced Conversions Matches findet und wie hoch die Coverage-Rate ist.