Skip to content
Startseite Guides Analytics
Analytics Fortgeschritten

Erweiterte Conversions in Google Ads einrichten: Web und Leads

Was erweiterte Conversions mit gehashten Kundendaten tun, was sich 2026 an der Einstellung und an der Upload-Schnittstelle geändert hat, wie du sie über Google-Tag, Tag Manager oder Shopify einbaust und wie du die Diagnose liest.

Fabian Weiss, Gründer von FW Delta Fabian Weiss
12 Min. 2 bis 4 Stunden für Web, ein Tag oder mehr für Leads mit CRM-Anbindung
Das Problem

Erweiterte Conversions werden eingeschaltet, ohne dass jemand prüft, ob die Daten sauber normalisiert, mit Einwilligung gesendet und in der Diagnose wirklich angekommen sind

Die Lösung

Verstehen, was die Funktion tut, den passenden Einbauweg wählen, Normalisierung und Einwilligung korrekt umsetzen und das Ergebnis im Diagnosebericht kontrollieren

Google AdsGoogle Tag ManagerData Manager APIShopify

Was erweiterte Conversions tun

Dein Conversion-Tracking funktioniert. Bestellungen und Anfragen kommen im Werbekonto an. Trotzdem fehlt ein Teil der Zuordnung, weil Google beim Klick und bei der Bestellung nicht immer dieselbe Kennung sieht. Diese Lücke sollen erweiterte Conversions verkleinern.

Die Funktion ergänzt das bestehende Conversion-Tag um Kundendaten, die der Besucher dir selbst gegeben hat: E-Mail-Adresse, Telefonnummer, Name und Adresse. Diese Werte werden normalisiert, mit SHA-256 gehasht und so an Google übertragen. Google vergleicht den Hash mit den Daten von Nutzern, die beim Klick auf deine Anzeige in ihrem Google-Konto angemeldet waren. Passt der Hash, kann die Conversion der Anzeige zugeordnet werden, auch wenn Cookie oder Klick-Kennung unterwegs verloren gingen. Google beschreibt das in der Übersicht zu erweiterten Conversions.

Es gibt zwei Ausprägungen:

AusprägungWofürWoher kommen die Daten
Erweiterte Conversions für WebBestellungen und Anfragen, die direkt auf der Website abgeschlossen werdenDie Bestell- oder Dankeseite zum Zeitpunkt der Conversion
Erweiterte Conversions für LeadsAbschlüsse, die erst später im CRM entstehen, zum Beispiel ein qualifizierter Lead oder ein unterschriebener VertragDas Formular auf der Website liefert die Kennung, der Abschluss wird später aus dem CRM hochgeladen

Was erweiterte Conversions nicht tun

Drei Missverständnisse tauchen in fast jedem Projekt auf.

  • Sie ersetzen das Conversion-Ereignis nicht. Die Basis bleibt ein funktionierendes Conversion-Tag oder ein sauberer Upload. Wenn die Basis kaputt ist, wird sie mit Kundendaten nicht heiler. Wie du die Basis einrichtest, steht im Leitfaden Google Ads Conversion-Tracking einrichten.
  • Sie umgehen kein Cookie-Banner. Die Übertragung von Kundendaten zu Werbezwecken hängt im Consent Mode am Signal ad_user_data. Ist es abgelehnt, werden laut Consent-Mode-Übersicht keine gehashten First-Party-Daten für erweiterte Conversions gesendet. Es gibt keinen Weg an der Einwilligung vorbei.
  • Sie liefern nicht mehr Conversions, sondern bessere Zuordnung. Google zählt Conversions, die vorher ohne Zuordnung blieben, jetzt der richtigen Anzeige zu. Wer einen Sprung in der Gesamtzahl erwartet, misst das Falsche.

Was sich 2026 geändert hat

Bis Anfang 2026 musstest du dich im Werbekonto für einen Einbauweg entscheiden: Google-Tag, Tag Manager, API oder Partner. Das ist vorbei. Google hat die Funktion in zwei Schritten umgebaut, dokumentiert in der Ankündigung zu den Änderungen an erweiterten Conversions:

ZeitpunktÄnderung
April 2026Google Ads nimmt Kundendaten gleichzeitig aus Website-Tags, dem Data Manager und API-Verbindungen an. Die Wahl zwischen den Methoden entfällt.
Juni 2026Erweiterte Conversions für Web und für Leads werden zu einer Einstellung mit einem einzigen Ein- und Ausschalter zusammengeführt.
15. Juni 2026Neue Integrationen für Offline-Conversions und erweiterte Conversions für Leads laufen über die Data Manager API. Die Google Ads API nimmt keine neuen Nutzer dieser Funktion mehr an.

Konten, die die Kundendatenbedingungen bereits angenommen hatten, müssen laut Google nichts tun. Neue Konten schalten die Funktion auf Kontoebene oder pro Conversion-Aktion ein.

Für Entwickler zählt der dritte Punkt. Der Beitrag im Google Ads Developer Blog vom 15. Mai 2026 sagt es klar: Ab dem 15. Juni 2026 nimmt die Google Ads API keine neuen Anwender für den Import von Offline-Conversions an, erweiterte Conversions für Leads eingeschlossen. Wer die Funktion dort bereits nutzt, wird per Entwickler-Token freigeschaltet und kann weiter hochladen, während er auf die Data Manager API umzieht. Alle anderen bekommen den Fehler CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE.


Voraussetzungen

Bevor du irgendetwas einbaust, müssen drei Dinge stehen.

1. Kundendatenbedingungen annehmen. Im Werbekonto findest du die Einstellung unter Zielvorhaben, Conversions, Einstellungen. Dort schaltest du erweiterte Conversions ein und bestätigst die Bedingungen für Kundendaten. Ohne diese Zustimmung verwirft Google die Daten, egal wie sauber das Tag ist. Die Schritte stehen in der Anleitung für den Google Tag Manager.

2. Consent Mode mit ad_user_data. Dein Cookie-Banner muss das Signal ad_user_data setzen und erst nach der Einwilligung auf granted stellen. Welche Bannerkategorie auf welches Signal abgebildet wird, ist eine dokumentierte Entscheidung. Der Leitfaden Consent Mode Basic oder Advanced behandelt die vier Signale im Detail.

3. Eine funktionierende Conversion-Aktion. Für Web brauchst du eine Conversion-Aktion vom Typ Website, für Leads eine vom Typ “Website (Import aus Klicks)”. Auto-Tagging muss aktiv sein, damit die Klick-Kennung (GCLID) auf deiner Seite ankommt.


Welche Daten Google erwartet und wie sie normalisiert werden

Die Normalisierung ist der Punkt, an dem die meisten Setups leise scheitern. Ein Hash aus “Anna.Muster@Example.com” und ein Hash aus “anna.muster@example.com” sind zwei verschiedene Zeichenketten. Google kann nur matchen, wenn beide Seiten dieselben Regeln anwenden. Die Regeln stehen in der Anleitung für das Google-Tag und ausführlicher in der Formatierungsanleitung der Data Manager API:

FeldNormalisierungWird gehasht
E-Mail-AdresseKleinschreibung, Leerzeichen entfernen. Bei gmail.com und googlemail.com zusätzlich alle Punkte vor dem @ entfernenJa
TelefonnummerE.164-Format: Pluszeichen, Ländervorwahl, danach nur ZiffernJa
VornameKleinschreibung, Leerzeichen an den Rändern entfernen, keine Anreden wie “Frau”Ja
NachnameKleinschreibung, Leerzeichen an den Rändern entfernen, keine Zusätze wie “jun.”Ja
StraßeKleinschreibung, Sonderzeichen entfernenJa
StadtKleinschreibung, Sonderzeichen entfernenNein
RegionKürzel oder ausgeschriebener Name, KleinschreibungNein
PostleitzahlLeerzeichen an den Rändern entfernenNein
LandZweibuchstabiger Code nach ISO 3166-1 alpha-2, zum Beispiel DENein

Wichtig für die Praxis: Wenn du dem Google-Tag oder dem Tag Manager unverschlüsselte Werte übergibst, übernimmt das Tag Normalisierung und Hashing selbst. Nur wenn du bereits gehashte Werte lieferst, musst du die Regeln selbst anwenden. Beides gleichzeitig ist der klassische Fehler, dazu unten mehr.

Laut der Google-Tag-Anleitung muss mindestens eines dieser Felder vorhanden sein: die E-Mail-Adresse (bevorzugt), die Adresse mit Vorname, Nachname, Postleitzahl und Land oder die Telefonnummer in Kombination mit E-Mail oder vollständiger Adresse. Du kannst bis zu drei Werte für E-Mail und Telefon und zwei Adressen übergeben, um die Trefferwahrscheinlichkeit zu erhöhen.


Weg 1: Google-Tag mit user_data in gtag

Wenn das Google-Tag direkt im Quellcode liegt, ist das der kürzeste Weg. Auf der Bestell- oder Dankeseite setzt du die Kundendaten mit gtag('set', 'user_data', ...), bevor das Conversion-Ereignis gesendet wird. Die Feldnamen sind fest vorgegeben:

gtag('set', 'user_data', {
  "email": yourEmailVariable,
  "phone_number": yourPhoneVariable,
  "address": {
    "first_name": yourFirstNameVariable,
    "last_name": yourLastNameVariable,
    "postal_code": yourPostalCodeVariable,
    "country": yourCountryVariable
  }
});

gtag('event', 'conversion', {
  "send_to": "AW-XXXXXXXXX/XXXXXXXXXXXX",
  "value": 89.90,
  "currency": "EUR",
  "transaction_id": "ORDER-12345"
});

Die Variablen füllst du serverseitig aus der Bestellung, nicht aus dem Formular im Browser, sonst landen Tippfehler und leere Felder im Hash. Gibt dein System die Werte bereits gehasht aus, verwendest du stattdessen die Felder sha256_email_address und sha256_phone_number. Die Reihenfolge ist entscheidend: set vor event, sonst geht das Conversion-Ereignis ohne Kundendaten raus.


Weg 2: Google Tag Manager mit der Variable “Von Nutzern bereitgestellte Daten”

Im Tag Manager läuft alles über eine Variable vom Typ “Von Nutzern bereitgestellte Daten”. Vorher musst du im Google-Tag die Option “Funktionen für von Nutzern bereitgestellte Daten zulassen” aktivieren. Die Variable kennt drei Betriebsarten, beschrieben in der Tag-Manager-Anleitung:

BetriebsartWie sie arbeitetWann sie passt
Automatische ErfassungDas Tag durchsucht die Seite nach Feldern, die wie E-Mail, Telefon oder Adresse aussehenSchneller Start, wenig Kontrolle, riskant bei mehreren Formularen auf einer Seite
Manuelle KonfigurationDu hinterlegst CSS-Selektoren oder JavaScript-Variablen für jedes FeldWenn die Werte im DOM stehen und die Selektoren stabil sind
CodeDu übergibst ein Objekt aus dem Data Layer oder einer eigenen VariableDie sauberste Lösung, wenn ein Entwickler den Data Layer befüllt

Für die Code-Variante schreibt deine Seite die Kundendaten in den Data Layer, bevor das Conversion-Tag feuert:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: "purchase",
  transaction_id: "ORDER-12345",
  value: 89.90,
  currency: "EUR",
  user_data: {
    email: "anna.muster@example.com",
    phone_number: "+49151XXXXXXX",
    address: {
      first_name: "anna",
      last_name: "muster",
      postal_code: "24937",
      country: "DE"
    }
  }
});

Im Tag Manager legst du eine Data-Layer-Variable user_data an, wählst in der Variable “Von Nutzern bereitgestellte Daten” die Betriebsart Code und verweist auf diese Data-Layer-Variable. Im Google Ads Conversion-Tracking-Tag aktivierst du die Übernahme von Nutzerdaten und wählst die Variable aus. Danach prüfst du im Vorschaumodus, ob der Aufruf an Google die gehashten Werte enthält.


Weg 3: Shopify über die Google & YouTube App

Auf Shopify baust du nichts von Hand ein. Die Google & YouTube App übernimmt das Conversion-Tracking und liefert auf Wunsch auch die Kundendaten mit. Laut Anleitung für die Google & YouTube App sind es drei Schritte: In der App den Reiter Einstellungen öffnen, unter den Google-Ads-Einstellungen bei “Erweiterte Conversions” auf Aktivieren gehen und die Kundendatenbedingungen bestätigen. Voraussetzung ist ein verknüpftes Werbekonto und aktives Conversion-Tracking über die App.

Bau daneben kein eigenes Conversion-Tag mit Kundendaten ins Theme oder in Custom Pixels ein. Dann zählt dieselbe Bestellung doppelt. Ein Weg pro Shop.


Erweiterte Conversions für Leads

Bei Leads liegt der Abschluss nicht auf der Website. Der Ablauf hat zwei Hälften, beschrieben in der Anleitung zu erweiterten Conversions für Leads:

Hälfte 1: Das Formular auf der Website. Beim Absenden erfasst ein Tag die Kennung des Interessenten. Mindestens eines dieser Felder muss dabei sein: die E-Mail-Adresse (empfohlen, weil eindeutig) oder die Telefonnummer mit Ländervorwahl. Adressdaten helfen zusätzlich. Im Tag Manager brauchst du dafür den Conversion-Linker und ein Tag vom Typ “Google Ads: Ereignis mit von Nutzern bereitgestellten Daten”, das dieselben drei Betriebsarten kennt wie oben. Google empfiehlt außerdem, die GCLID beim Absenden mitzuspeichern.

Hälfte 2: Der Upload aus dem CRM. Wird aus der Anfrage ein Abschluss, lädst du die Conversion mit dem gehashten Wert derselben Kennung hoch. Jeder Datensatz enthält den Namen der Conversion-Aktion, den Zeitpunkt und mindestens eine Kennung. Google nennt drei Wege: den Data Manager im Werbekonto (empfohlen), die API und Drittanbieter wie Zapier, HubSpot oder Salesforce.

Für den Upload per API gilt seit dem 15. Juni 2026 die Data Manager API. Deren Anleitung für Google Ads Conversions legt fest: Die Conversion-Aktion muss den Typ UPLOAD_CLICKS haben, im Werbekonto “Website (Import aus Klicks)”. Jedes Ereignis braucht einen eventTimestamp. Kennungen wie E-Mail-Adresse, Vorname und Nachname müssen mit SHA-256 gehasht und hexadezimal oder Base64 kodiert sein. Als Kennung reicht die GCLID oder mindestens eine gehashte Nutzerkennung, beides zusammen ist besser.

Die Einwilligung nimmt die API pro Ereignis in einem consent-Objekt entgegen. Laut Referenz des Consent-Objekts hat es die Felder adUserData und adPersonalization mit den Werten CONSENT_GRANTED, CONSENT_DENIED oder CONSENT_STATUS_UNSPECIFIED. Google bezeichnet das Befüllen in der Leads-Anleitung als dringend empfohlen. Dein CRM muss den Consent-Zustand also vom Formular bis zum Upload mitführen.


Prüfen: Der Diagnosebericht

Nach dem Einbau wartest du. Google nennt in der Tag-Manager-Anleitung 48 Stunden und in der Google-Tag-Anleitung 72 Stunden, bevor du den Diagnosebericht auswertest. Du findest ihn im Werbekonto unter Zielvorhaben, Zusammenfassung, Reiter Diagnose. Der Status jeder Conversion-Aktion führt ebenfalls dorthin.

Der Diagnosebericht für Web kennt vier Zustände:

StatusBedeutung
HervorragendSetup aktiv, Daten kommen an, nichts zu tun
GutSetup aktiv, mehr Datenfelder würden die Zuordnung verbessern
Muss überprüft werdenSetup aktiv, aber mit Fehlern wie fehlenden Feldern oder falscher Formatierung
Keine aktuellen DatenIn den letzten 7 Tagen wurden keine erweiterten Conversions erfasst

Der Diagnosebericht für Leads ergänzt den Status “Dringend” für ein inaktives Setup, etwa wenn das Tag auf dem Formular nicht feuert. Die wichtigsten Meldungen dort:

  • “Importing limited user-provided data”: Du lädst nur Ereignisse hoch, die sowohl Nutzerdaten als auch eine Google-Kennung wie die GCLID haben. Google will alle Ereignisse mit Nutzerdaten sehen, auch die ohne GCLID.
  • “Tag is missing user-provided data”: Das Tag feuert, aber die Felder sind leer. Meist ein falscher Selektor oder eine Dankeseite, auf der der Wert nicht mehr im DOM steht.
  • “No user-provided data matches”: Die hochgeladenen Hashes passen zu keinem Hash vom Formular. Fast immer eine Normalisierung, die auf einer Seite anders läuft als auf der anderen.

Die Warnungen beziehen sich laut Google auf den letzten Tag oder, wenn dort zu wenig Daten liegen, auf die letzten 7 Tage. Kennzahlen zum Uplift zeigt der Bericht erst nach 30 Tagen laufender Übertragung. Wer nach zwei Tagen einen Effekt sucht, sucht zu früh.


Häufige Fehler

  1. Bereits gehashte Daten noch einmal hashen. Das Tag hasht unverschlüsselte Werte selbst. Ein Hash im Feld email wird zum Hash vom Hash und matcht nie. Gehashte Werte gehören in sha256_email_address und sha256_phone_number.
  2. Falsche Normalisierung. Großbuchstaben, Leerzeichen am Ende, ein Punkt in einer Gmail-Adresse: Jeder Fall erzeugt einen anderen Hash. Gilt vor allem, wenn du selbst hashst oder aus dem CRM hochlädst.
  3. Telefonnummer ohne Ländervorwahl. “0151 1234567” ist kein E.164. Es muss “+491511234567” sein.
  4. Daten ohne Einwilligung senden. Steht ad_user_data nicht auf granted, darf das Tag keine Kundendaten übertragen. Wer das Tag vor dem Banner feuert oder das Signal falsch abbildet, sendet Daten, die er nicht senden darf.
  5. Mehr Conversions erwarten. Erweiterte Conversions verbessern die Zuordnung. Die Gesamtzahl der Bestellungen ändert sich nicht. Der richtige Vergleich ist der Anteil zugeordneter Conversions vorher und nachher.
  6. Zwei Wege gleichzeitig. Google-Tag im Theme plus Tag Manager plus Shop-App: Jede Bestellung wird mehrfach gemeldet. Ein Weg pro Conversion-Aktion.
  7. Beim Leads-Upload nur Datensätze mit GCLID senden. Das löst die Meldung “Importing limited user-provided data” aus und verschenkt den Nutzen der Funktion.

Checkliste

  1. Die Basis-Conversion feuert korrekt, mit Transaktions-Kennung und ohne Duplikate.
  2. Die Kundendatenbedingungen sind im Werbekonto angenommen und erweiterte Conversions sind eingeschaltet.
  3. Das Cookie-Banner setzt ad_user_data und stellt es erst nach der Einwilligung auf granted.
  4. Genau ein Einbauweg ist gewählt: Google-Tag, Tag Manager oder Shop-App.
  5. Die Normalisierung ist geprüft: Kleinschreibung, keine Randleerzeichen, E.164 bei Telefon, ISO-Ländercode.
  6. Unverschlüsselte Werte gehen in email und phone_number, gehashte in sha256_email_address und sha256_phone_number, nie beides gleichzeitig.
  7. Im Netzwerk-Tab enthält der Aufruf an Google die gehashten Werte.
  8. Bei Leads: Das Formular-Tag erfasst E-Mail oder Telefon, die GCLID wird gespeichert, das CRM führt den Consent-Zustand mit.
  9. Bei Leads: Der Upload läuft über den Data Manager oder die Data Manager API, nicht über eine neue Anbindung an die Google Ads API.
  10. Nach 48 bis 72 Stunden steht der Diagnosebericht auf “Hervorragend” oder “Gut” und offene Warnungen sind abgearbeitet.

Wo FW Delta ins Spiel kommt

Erweiterte Conversions bringen nur auf einem sauberen Fundament etwas: ein korrektes Conversion-Ereignis, eine dokumentierte Consent-Abbildung und bei Leads eine CRM-Anbindung, die Kennung und Einwilligung bis zum Upload mitführt. Der Service Web-Tracking baut dieses Fundament, das Tracking-Angebot deckt auch Anbindungen jenseits des Shops ab.

Wenn du nicht sicher bist, ob dein Setup Kundendaten überhaupt sauber überträgt, ist der Tracking-Check der passende Einstieg. Er prüft die Basis-Conversion, den Consent-Zustand und den tatsächlichen Inhalt der Aufrufe an Google.

FW Delta übernimmt die technische Umsetzung. Ob deine Rechtsgrundlage und dein Bannertext die Übertragung gehashter Kundendaten abdecken, bewertet deine Rechtsberatung. Dieser Leitfaden ist eine technische Anleitung, keine Rechtsberatung.

Newsletter

Research für technische Entscheidungen

Neue Reports, Benchmarks und technische Analysen zu SaaS-Ökonomie, AI Engineering und eigener Infrastruktur.

Original Research Öffentliche Quellen Keine Sales-Mails

Mit der Anmeldung erhältst du neue Analysen und Updates von FW Delta per E-Mail. Du kannst deine Einwilligung jederzeit widerrufen. Weitere Informationen in der Datenschutzerklärung.