Google-Update zu „Enhanced Conversions“ 2026: Die meisten Agenturen haben noch nicht überprüft, ob ihre Lösung funktioniert

Im Juni 2026 hat Google Ads die Funktionsweise von „Enhanced Conversions“ geändert. Die beiden separaten Produkte „Enhanced Conversions for Web“ und „Enhanced Conversions for Leads“, die jeweils über einen eigenen Einstellungsbildschirm und eine eigene Implementierungsmethode verfügten, wurden zu einem einzigen Ein-/Aus-Schalter zusammengefasst.

Google hat es als Vereinfachung dargestellt, und das ist es auch. Aber das Update bewirkt noch etwas, das weniger offensichtlich ist. Es entfernt den sichtbaren Hinweis darauf, dass „Enhanced Conversions“ ein aktives System mit sich verändernden Komponenten ist – und kein Schalter, den man einmal umlegt und dann vergisst. Wenn du dein System vor einer Weile eingerichtet und seitdem nicht mehr nachgesehen hast, ist die Wahrscheinlichkeit groß, dass es gar nichts mehr bewirkt.

Ein großer Teil der „Enhanced Conversions“-Einstellungen sieht in Google Ads zwar aktiv aus, liefert aber kaum oder gar keine verwertbaren Daten. Der Schalter steht auf „Ein“. Die Conversion-Aktion zeigt Aktivität an. Doch die gehashten Nutzerdaten, die das Ganze erst funktionieren lassen, erreichen Google nie in einer verwertbaren Form. Niemand merkt das, weil in der Benutzeroberfläche nichts darauf hindeutet, dass etwas nicht stimmt.

Hier erfährst du, was sich im Juni 2026 tatsächlich geändert hat, warum die Einrichtung von „Google Enhanced Conversions“ ohne sichtbaren Fehler fehlschlägt, wie du überprüfen kannst, ob deine Einrichtung davon betroffen ist, und warum die Weiterleitung der Einrichtung über server-side GTM die meisten Fehlerquellen von vornherein beseitigt.

Was „Google Enhanced Conversions“ eigentlich bewirken

Erweiterte Conversions gibt es, weil das Cookie-basierte Conversion-Tracking eine Lücke aufweist. Google Ads ordnet eine Conversion normalerweise mithilfe einer GCLID zu, einer Klick-ID, die in einem Browser-Cookie gespeichert ist. Wenn dieses Cookie fehlt (blockiert oder gelöscht wurde oder der Nutzer die Conversion auf einem anderen Gerät getätigt hat), findet die Conversion zwar trotzdem statt, aber Google kann sie nicht mehr der Anzeige zuordnen, die sie ausgelöst hat.

„Enhanced Conversions“ schließen diese Lücke teilweise durch einen zweiten Identifikator. Wenn ein Nutzer eine Conversion durchführt, erfasst deine Website First-Party-Daten (in der Regel eine E-Mail-Adresse) und verschlüsselt diese mit SHA-256, bevor sie an Google gesendet werden. Google vergleicht diesen Hash mit Hashes, die aus den Daten seiner eigenen angemeldeten Konten abgeleitet wurden. Wenn sie übereinstimmen, wird die Conversion auch ohne funktionierende GCLID zugeordnet.

Das ist der ganze Ablauf: Hashen, senden, abgleichen. Das Hashen erfolgt einseitig, sodass Google niemals eine lesbare E-Mail-Adresse erhält, sondern nur einen Fingerabdruck davon.

Eine vollständige Übersicht, einschließlich eines Vergleichs zwischen „Enhanced Conversions for Web“ und „Leads“, der Funktionsweise der Übereinstimmungsrate sowie Einrichtungsanleitungen für jeden Implementierungsweg, findest du in unserem umfassenden Leitfaden zu Google Enhanced Conversions.

Google-Update zu „Enhanced Conversions“ im Juni 2026: Was hat sich geändert?

Vor Juni 2026 waren „Erweiterte Conversions für das Web“ und „Erweiterte Conversions für Leads“ separate Funktionen. Jede hatte ihren eigenen Einstellungsbildschirm, und Werbetreibende mussten pro Conversion-Aktion eine Implementierungsmethode (das Google-Tag, GTM oder die API) auswählen.

Ab April 2026 akzeptierte Google gleichzeitig von Nutzern bereitgestellte Daten aus Website-Tags, dem Data Manager und API-Verbindungen, anstatt eine einzige Methode vorzuschreiben. Ab Juni 2026 wurde diese Flexibilität zur Standardeinstellung: Die beiden Produkte wurden zu einer einzigen Funktion mit einem einzigen Ein-/Aus-Schalter zusammengefasst, und der Bildschirm zur Methodenauswahl verschwand vollständig aus der Benutzeroberfläche.

Für Agenturen, die mehrere Kunden betreuen, gibt es drei Dinge, die man nach der Zusammenlegung überprüfen sollte.

Bestehende Konfigurationen wurden automatisch migriert, allerdings nur für Konten, die Googles Nutzungsbedingungen für Kundendaten bereits akzeptiert hatten. Wenn ein Kundenkonto diese Bedingungen nie ausdrücklich akzeptiert hat (was häufig vorkommt, wenn „Erweiterte Conversions“ von einer früheren Agentur oder einem internen Team aktiviert wurden, das die Einrichtung nicht vollständig abgeschlossen hat), läuft die Migration nicht reibungslos ab, und das Konto zeigt „Erweiterte Conversions“ möglicherweise als verfügbar, aber inaktiv an.

Durch die Änderung der Benutzeroberfläche sind einige der zuvor vorhandenen Diagnosehinweise nicht mehr sichtbar. Als die Methodenauswahl noch angezeigt wurde, konntest du zumindest überprüfen, welchen Implementierungspfad eine Konvertierungsaktion eigentlich nutzen sollte. Da dieser Bildschirm nun wegfällt, hängt die Überprüfung der Konfiguration jetzt stärker von den Diagnosehinweisen ab und weniger davon, ob die Einstellungsseite deinen Erwartungen entspricht.

Die Opt-out-Möglichkeit besteht weiterhin auf der Ebene der Conversion-Aktion, und die Zusammenführung ändert nichts an der zugrunde liegenden Anforderung der Datenverarbeitungsbedingungen. Google erwartet nach wie vor, dass Werbetreibende diesen Bedingungen zugestimmt haben und die von Nutzern bereitgestellten Daten in Übereinstimmung mit den Richtlinien verarbeiten. Die Umschaltfunktion ist einfacher geworden, aber die Verpflichtung zur Einhaltung der Vorschriften bleibt bestehen.

Funktionierende Konfigurationen laufen einfach weiter. Aber das ist ein guter Zeitpunkt, um Konten zu überprüfen, die vor einer Weile eingerichtet und seitdem nie wieder angesehen wurden, denn die Zusammenführung ist genau die Art von Änderung, die Probleme ans Licht bringt, nach denen niemand gesucht hat.

Warum „Enhanced Conversions“ stillschweigend fehlschlägt und wie man das erkennen kann

Bei „Google Enhanced Conversions“ gibt es einen speziellen Fehlerfall, der leicht übersehen werden kann. Das Conversion-Tag kann korrekt ausgelöst werden, die Conversion wird trotzdem erfasst und Google Ads zeigt die Conversion-Aktion als aktiv an, während die erweiterten Daten selbst Google nie in einem verwertbaren Zustand erreichen.

Googles eigener Diagnosebericht definiert genau aus diesem Grund mehrere Statusmeldungen. „Erweiterte Conversions werden erfasst“ bedeutet, dass es tatsächlich funktioniert. „Warten auf erweiterte Conversion-Daten“ kann bedeuten, dass es noch zu früh ist, da es bis zu 48 Stunden dauern kann, bis der Status aktualisiert wird. Aber „Einrichtungsprobleme erkannt“ und – bei Leads – der Status „Dringend“ deuten beide auf eine Einrichtung hin, die zwar live zu sein scheint, aber nichts Brauchbares liefert. In der Lücke zwischen diesen Zuständen verharren die meisten fehlerhaften Einstellungen monatelang unberührt, während niemand auf die Idee kommt, nachzuschauen.

Die häufigsten Ursachen sind nicht besonders dramatisch. Es handelt sich um kleine Konfigurationsdetails, die nirgendwo einen Fehler auslösen:

• Das Feld „user_data“ ist vorhanden, aber leer. Das Tag wird ausgelöst, der Wrapper erreicht Google, aber das darin enthaltene, gehashtes E-Mail- oder Telefonnummernfeld ist leer. Google protokolliert den Ping als empfangen und macht weiter. Es wird nicht vermerkt, dass „nichts Brauchbares darin war“. Meistens handelt es sich dabei um eine GTM-Variable, die nie dem richtigen dataLayer-Schlüssel zugeordnet wurde, und das ist der mit Abstand häufigste Grund dafür, dass eine auf den ersten Blick einwandfrei aussehende Konfiguration kein Signal liefert.
• Doppel-Hashing. Manche Teams hashen die E-Mail-Adresse selbst, bevor sie sie an den dataLayer übermitteln; anschließend hasht GTM oder das Google-Tag sie vor dem Versand noch einmal. Google vergleicht dann letztendlich einen Hash eines Hashs mit seiner eigenen Datenbank aus einzelnen Hashs. Es gibt nie eine Übereinstimmung, und es gibt keinen Fehler, der auf die Ursache hinweist. Die Lösung besteht darin, immer den Rohwert zu senden und das Hashen von GTM oder gtag.js übernehmen zu lassen.
• Den Schalter umlegen, ohne das Etikett zu berühren. Das Aktivieren von „Erweiterte Conversions“ in der Google Ads-Oberfläche führt nicht automatisch zu einer Neukonfiguration deines GTM-Tags. Wenn die „user_data“-Felder im Conversion-Tag nie eingerichtet wurden, bewirkt das Umschalten des Schalters auf Kontoebene nichts, außer dass die Einstellung so aussieht, als wäre sie aktiv.
• CSS-Selektoren funktionieren nach der Neugestaltung der Website nicht mehr. Wenn bei der ursprünglichen Einrichtung das E-Mail-Feld über einen CSS-Selektor auf der Bestätigungsseite erfasst wurde, führt eine Neugestaltung, bei der Element-IDs oder Klassennamen geändert werden, dazu, dass der Selektor nicht mehr funktioniert, ohne dass es jemand bemerkt. Das Tag wird zwar weiterhin ausgelöst, findet aber nichts mehr, was es hashen könnte. Variablen auf der Datenebene haben dieses Problem nicht – das ist ein Grund, warum sie die stabilere Option sind.
• Ein Einwilligungs-Gating, das wie eine normale Abweichung aussieht. Wenn die Einwilligung für „ad_user_data“ verweigert wird, sendet „Enhanced Conversions“ die gehashten Daten für diesen Nutzer einfach nicht. Das ist das korrekte Verhalten und kein Fehler, bedeutet aber, dass die Übereinstimmungsrate in Regionen mit hoher Einwilligungsquote natürlich sinkt. Die Kunst besteht darin, den Unterschied zwischen erwarteten, durch die Einwilligungsquote bedingten Schwankungen und einem tatsächlichen technischen Fehler zu erkennen – was ohne direkte Überprüfung der Zahlen schwer ist.

Die Diagnose all dieser Probleme beginnt mit denselben zwei Überprüfungen: Öffne den GTM-Vorschau-Modus und vergewissere dich, dass das „user_data“-Objekt im Conversion-Tag tatsächlich gehashtete Werte enthält und kein leeres Objekt ist. Überprüfe dann die Netzwerkanfrage selbst auf den „em“-Parameter. Fehlt dieser, ist das Tag nicht so konfiguriert, dass es ihn sendet. Ist er zwar vorhanden, lautet aber etwa „tv.1~em.“ ohne weiteren Nachhang, wird das Feld leer ausgelöst. In beiden Fällen liegt die Lösung in GTM, nicht im Einstellungsbildschirm von Google Ads.

Wie server-side GTM die „Google Enhanced Conversions“ zuverlässiger macht

Die meisten der oben genannten Fehlerquellen haben eines gemeinsam: Sie treten im Browser auf, wo das Tag vom DOM der Seite abhängt, davon, dass der dataLayer korrekt gefüllt ist, und davon, dass die Anfrage nicht abgefangen wird, bevor sie den Browser verlässt. Die Verlagerung der Einrichtung auf server-side GTM beseitigt zwar nicht alle Fehlerquellen, eliminiert aber einige davon, indem der Ort, an dem die Verarbeitung stattfindet, geändert wird.

Mit einem Server-Container schrumpft die Aufgabe des Browsers. Er sendet das Ereignis (mit den Rohdaten des Nutzers) an deinen eigenen First-Party-Endpunkt. Der Server-Container – und nicht ein browserseitiges Tag – erstellt das „user_data“-Objekt, führt die Hash-Verarbeitung durch und leitet die Anfrage an Google weiter. Diese eine Änderung beseitigt das Problem der doppelten Hash-Verarbeitung vollständig, da die Hash-Logik nun an einer einzigen Stelle angesiedelt ist, anstatt zwischen der Seite und dem Tag aufgeteilt zu sein.

Außerdem wird dadurch das Risiko durch Werbeblocker beseitigt. Ein browserbasiertes „Enhanced Conversions“-Tag sendet seine Anfrage vom Browser des Nutzers aus, was bedeutet, dass ein Werbeblocker oder eine Tracking-Schutzfunktion diese abfangen oder verwerfen kann, bevor Google sie überhaupt zu Gesicht bekommt. Das Tag kann perfekt konfiguriert sein und trotzdem Daten an etwas verlieren, das völlig außerhalb deiner Kontrolle liegt. Eine Server-zu-Server-Anfrage von deinem Container an die Google-API ist diesem Risiko nicht ausgesetzt, da es im Browser nichts gibt, was ein Ad-Blocker abfangen könnte.

Wichtig zu wissen: Der server-side Schritt hilft nur, wenn die Verbindung zwischen Browser und Server selbst widerstandsfähig ist. Stell sicher, dass du das „Enhanced Tracking Script“ von TAGGRS verwendest, damit diese erste Anfrage für Werbeblocker komplett unsichtbar bleibt – sonst verlagert sich das Risiko einer Abfangung einfach einen Schritt weiter nach vorne in der Kette.

Nichts davon ersetzt die Notwendigkeit, die Einstellungen korrekt vorzunehmen. Eine server-side Konfiguration mit einem leeren „user_data“-Feld ist immer noch ein leeres „user_data“-Feld. Aber es bedeutet, dass es weniger Stellen gibt, an denen eine funktionierende Konfiguration plötzlich nicht mehr funktioniert, ohne dass ein Fehler ausgegeben wird – und genau diese Art von Fehler ist schwer zu entdecken, wenn man nicht aktiv danach sucht. Für Agenturen, die mehrere Kundenkonten verwalten, summiert sich dieser Unterschied in der Zuverlässigkeit schnell – weniger stille Fehler bedeuten weniger Audits, weniger Lücken in den Attributionsdaten und weniger Gespräche, in denen man den Kunden erklären muss, warum ihre Conversion-Zahlen nicht mit der Realität übereinstimmen.

• Den vollständigen Einrichtungspfad, einschließlich der Konfiguration auf Feldebene für Google Ads über das server-side GTM, findest du in der Dokumentation zur Einrichtung von „Enhanced Conversions“ und in der Übersicht zum server-side Tracking von Google Ads.
• Wenn du neben „Enhanced Conversions for Leads“ auch Offline-Conversions aus einem CRM verarbeitest, findest du in der Dokumentation zum Offline-Conversion-Tag Informationen zu dieser speziellen Einrichtung. In diesem Artikel über den Nachweis des tatsächlichen ROAS aus Offline-Conversions erfährst du, warum diese Daten nicht nur für Smart Bidding, sondern auch für das Reporting insgesamt wichtig sind.

Google Enhanced Conversions und DSGVO: Was EU-Behörden wissen müssen

„Enhanced Conversions“ übermittelt personenbezogene Daten, und das Hashing ändert nichts an dieser Einstufung gemäß DSGVO. Ein SHA-256-Hash einer E-Mail-Adresse ist pseudonymisierte Daten, keine anonymisierten Daten, da Google (der Empfänger) diesen mit bereits vorhandenen Daten abgleichen und die dahinter stehende Person wieder identifizieren kann. Diese Unterscheidung ist wichtig: Pseudonymisierte Daten fallen weiterhin vollständig unter die DSGVO, mit denselben Verpflichtungen hinsichtlich der Rechtsgrundlage, der Einwilligung und der Rechte der betroffenen Personen.

In der Praxis bedeutet das, dass für „Google Enhanced Conversions“ das Einwilligungssignal „ad_user_data“ aus dem Consent Mode V2 erteilt sein muss, bevor es ausgelöst wird. Wenn ein Nutzer diese Einwilligung verweigert, nimmt das Google-Tag die gehashten Daten überhaupt nicht in den Conversion-Hit auf. Das ist beabsichtigt, kein Fehler, und entspricht den geltenden Vorschriften. Die aggregierte Conversion-Modellierung gilt weiterhin für Nutzer, die ihre Einwilligung nicht erteilen.

Für EU-Agenturen liegt das praktische Risiko in der Regel nicht bei „Enhanced Conversions“ selbst. Es sind vielmehr die Konfigurationen, bei denen „ad_storage“ gewährt wird, „ad_user_data“ jedoch nie explizit konfiguriert wurde – sodass das Einwilligungsbanner zwar technisch funktioniert, das zugrunde liegende Signal, das Google für „Enhanced Conversions“ tatsächlich überprüft, aber nie eingerichtet wurde. Das Tag wird ausgelöst, Daten werden gesendet, und es gibt keinen Einwilligungsnachweis, der das untermauert. Das ist eine Compliance-Lücke, die in einem Match-Rate-Bericht nicht auftaucht, weil es aus Sicht von Google so aussieht, als würde alles funktionieren. Das ist genau die Art von Problem, die man nur entdeckt, wenn man gezielt danach sucht – und die sich im Nachhinein nur schwer erklären lässt.

Server-side GTM hebt die Einwilligungspflicht nicht auf – und das sollte es auch nicht. Stattdessen wird die Überprüfung der Einwilligung zentralisiert. Anstatt sich darauf zu verlassen, dass mehrere browserbasierte Tags den Einwilligungsstatus jeweils korrekt berücksichtigen, kann der server-side Container die gesamte Nutzerdaten-Nutzlast an einer Stelle prüfen, bevor irgendetwas an Google, Meta oder eine andere Plattform gesendet wird.

Einen umfassenden Überblick über Einwilligungssignale und server-side Tracking findest du im Leitfaden zur DSGVO und zum server-side Tracking.

Wo TAGGRS passt

Nach einem Google-Update die erweiterten Conversions in jedem Kundenkonto zu überprüfen, ist für die meisten Agenturen kein realistischer Arbeitsablauf. Niemand hat die Zeit, jedes Mal, wenn Google etwas ändert, den GTM-Vorschau-Modus für fünfzig Konten zu öffnen.

TAGGRS führt „Enhanced Conversions“ über denselben server-side GTM-Container aus, der auch das übrige Tracking eines Kontos abwickelt. Da das Hashing und die Erstellung der „user_data“ server-side erfolgen und nicht über ein Flickwerk aus Browser-Tags, gibt es weniger Stellen, an denen sich ein unbemerktes Problem wie eine leere Nutzlast oder ein doppelt gehashtes Feld einschleichen kann, ohne dass es jemand bemerkt.

Auch die Einwilligungsprüfung läuft an einer zentralen Stelle ab. Anstatt zu prüfen, ob jedes browserbasierte Tag auf der Website eines Kunden „ad_user_data“ korrekt berücksichtigt, sorgt der Server-Container zentral dafür, bevor Nutzerdaten an Google, Meta oder eine andere Plattform weitergeleitet werden.

For teams that already use Google Ads tracking through TAGGRS, “Enhanced Conversions” are part of the same pipeline as all other conversion events and can be monitored through the central analysis dashboards in the TAGGRS account.

Fazit

Mit dem Update vom Juni 2026 wurde es einfacher, „Enhanced Conversions“ zu aktivieren – und es leichter, sie zu vergessen. Das ist das Risiko, das hinter einer Vereinfachung steckt: Weniger Einstellungen zu verwalten bedeutet auch, dass es weniger sichtbare Erinnerungen gibt, die dich daran erinnern, zu überprüfen, ob das, was du vor Monaten eingerichtet hast, noch immer seinen Zweck erfüllt.

Eine Konfiguration, die in Google Ads als aktiv angezeigt wird, liefert möglicherweise trotzdem keine brauchbaren Daten. Die einzige Möglichkeit, das festzustellen, besteht darin, den Diagnosebericht und die tatsächliche Netzwerkanfrage zu überprüfen – nicht nur den Schalter. Und wenn das Ziel darin besteht, die Anzahl der Stellen zu verringern, an denen dieser Fehler überhaupt erst auftreten kann, beseitigt die Verlagerung der Konfiguration server-side die meisten browserabhängigen Stellen, an denen es häufig zu Ausfällen kommt.

Das Überwachen von erweiterten Conversions über alle Kundenkonten hinweg ist genau die Art von Arbeit, die dir eine server-side Einrichtung ersparen soll. Du kannst ein kostenloses TAGGRS-Konto erstellen, um loszulegen, oder dir die Einrichtungsanleitungen ansehen, wenn du lieber erst einmal wissen möchtest, wie das Ganze funktioniert.

FAQ

Was hat sich mit dem Update „Enhanced Conversions“ vom Juni 2026 geändert?

Google hat „Enhanced Conversions for Web“ und „Enhanced Conversions for Leads“ zu einem einzigen Ein-/Aus-Schalter zusammengefasst und den Bildschirm entfernt, auf dem Werbetreibende eine Implementierungsmethode auswählen konnten. Bestehende Konten, die Googles Nutzungsbedingungen für Kundendaten bereits akzeptiert hatten, wurden automatisch migriert. Der zugrunde liegende Hash- und Abgleichmechanismus hat sich nicht geändert.

Warum sieht „Enhanced Conversions“ zwar aktiv aus, funktioniert aber eigentlich nicht?

Denn das Conversion-Tag und die erweiterten Daten sind zwei verschiedene Dinge. Das Tag kann ausgelöst werden und die Conversion kann normal erfasst werden, auch wenn das Feld „user_data“ darin leer ist, doppelt gehasht wurde oder ganz fehlt. Google Ads zeigt die Conversion-Aktion in beiden Fällen als aktiv an, da die Basis-Conversion weiterhin korrekt nachverfolgt wird.

Wie kann ich überprüfen, ob meine „Enhanced Conversions“-Einrichtung tatsächlich brauchbare Daten liefert?

Öffne den GTM-Vorschau-Modus, löse eine Testkonversion aus und überprüfe, ob das „user_data“-Objekt gehashtete Werte enthält und nicht leer ist. Überprüfe anschließend die Netzwerkanfrage auf den „em“-Parameter. Fehlt dieser oder ist er leer, gelangen die erweiterten Daten nicht bei Google an, selbst wenn die Basis-Konversion erfasst wird.

Löst das server-side GTM jedes Problem mit den erweiterten Conversions?

Nein. Ein falsch konfiguriertes Feld bleibt auch dann falsch konfiguriert, egal wo das Hashing stattfindet. Was das server-side GTM beseitigt, sind die browserabhängigen Fehlerquellen: Werbeblocker, die die Anfrage abfangen, CSS-Selektoren, die nach einer Neugestaltung nicht mehr funktionieren, und doppeltes Hashing, das durch die Aufteilung der Logik zwischen Seite und Tag verursacht wird.

Sind „Enhanced Conversions“ nach dem Update immer noch DSGVO-konform?

Ja, und die Anforderung hat sich nicht geändert. „Enhanced Conversions“ benötigt nach wie vor die im Consent Mode V2 erteilte Einwilligung für „ad_user_data“, bevor es gehashte Daten senden kann. Durch das Hashing werden die Daten im Sinne der DSGVO nicht anonymisiert, da Google sie weiterhin mit den bei ihm gespeicherten Kontodaten abgleichen kann.

Muss ich meine „Enhanced Conversions“-Einstellungen wegen der Zusammenlegung neu vornehmen?

Nicht unbedingt. Wenn dein Konto die Bedingungen für Kundendaten bereits akzeptiert hatte, erfolgte die Migration automatisch. Es lohnt sich trotzdem, den Diagnosebericht zu überprüfen, da die Zusammenführung ein guter Anlass ist, um eine Konfiguration zu entdecken, die schon vor dem Update fehlerhaft war, ohne dass es jemand bemerkt hat.