Trackdolphin
↑↓ wählen ↵ öffnen CtrlK Suche

Zurück zum Blog

Paul Wolf Google Ads

Google-Tag-Gateway ab 19. Oktober 2026: Was bedeutet die Google-Mail zu verschlüsselten Kundendaten?

Google Ads verschickt seit dem 9. September 2026 eine Kontomail mit dem Betreff „Verbesserungen bei der Datenverarbeitung im Google-Tag-Gateway“. Der Inhalt in einem Satz: Ab dem 19. Oktober 2026 schickt das Google-Tag bei aktivem Tag-Gateway keine SHA-256-Hashes von Kundendaten mehr, sondern verschlüsselte Daten in eine Trusted Execution Environment (TEE), wo sie entschlüsselt und mit Google-Konten abgeglichen werden. Betroffen sind nur Konten, die das Tag-Gateway und erweiterte Conversions, erweiterte Conversions für Leads oder conversionbasierte Kundenlisten nutzen. Zu tun ist praktisch nichts: Die Umstellung passiert auf Googles Seite, es gibt kein Opt-out, und am Tag nichts umzubauen. Was sich nicht ändert, ist die Rechtslage. Die Daten bleiben personenbezogen, und die Einwilligung bleibt nötig.

Was ändert sich genau am 19. Oktober 2026?

Heute hasht das Google-Tag die vom Nutzer bereitgestellten Daten, also E-Mail-Adresse, Telefonnummer und Name, mit SHA-256 und schickt den Hash im Parameter &em mit. Nach der Umstellung verschlüsselt das Tag die Daten im Browser und schickt sie im neuen Parameter &eme. Das zusätzliche e steht laut Googles Hilfe für „encrypted“: verschlüsselt im Browser, entschlüsselt erst in der TEE.

Der Ursprung der Daten bleibt gleich. Das Tag läuft weiter auf dem Endgerät des Besuchers, liest dort die Bestelldaten aus und schickt sie los. Verändert wird nur die Form, in der die Kundendaten die Seite verlassen.

Bin ich betroffen?

Betroffen ist, wer beides hat: das Google-Tag-Gateway für Werbetreibende und mindestens eines von erweiterten Conversions, erweiterten Conversions für Leads, conversionbasierten Kundenlisten.

Nicht betroffen sind:

  • Shops mit normalem Google-Tag oder Google Tag Manager ohne Gateway.
  • Google Analytics und Floodlight. Laut Googles Hilfe nutzt derzeit nur Google Ads eine TEE für diese Verarbeitung.
  • Serverseitige Uploads über die Google-Ads-API. Dort gilt weiterhin die SHA-256-Pflicht, und die Entwicklerdokumentation zum Conversion-Upload erwähnt weder TEE noch Verschlüsselung.

Wer serverseitiges Google Tag Manager einsetzt und darüber das Gateway betreibt, ist mitgemeint. Dort werden die Nutzerdaten verschlüsselt, bevor sie den Server-Container verlassen.

Ob das Gateway überhaupt aktiv ist, steht im Google Tag Manager unter Verwaltung. Von außen erkennt man es daran, dass das Tag und ein Teil der Messanfragen über die eigene Domain laufen statt über googletagmanager.com.

Was muss ich jetzt tun?

Wenig. Die Umstellung passiert bei Google, nicht im eigenen Tag.

  1. Nichts am Tag ändern. Wer die Daten heute schon selbst hasht und dem Tag übergibt, muss nichts umbauen. Google verarbeitet das weiter.
  2. Nach dem 19. Oktober die Conversions beobachten. Google verspricht eine bessere Abgleichsgenauigkeit und weniger Übertragungsfehler. Ob das im eigenen Konto ankommt, zeigt nur der Vorher-Nachher-Vergleich über zwei bis vier Wochen.
  3. Die eigene Dokumentation prüfen. Wer in der Datenschutzerklärung oder im Verzeichnis von Verarbeitungstätigkeiten „gehashte Daten“ stehen hat, beschreibt danach nicht mehr ganz das, was passiert.

Ein Opt-out ist nicht vorgesehen. Für Konten mit Google Ads als Ziel wird die TEE laut Googles Hilfe automatisch aktiviert.

Was ist das Google-Tag-Gateway überhaupt?

Das Google-Tag-Gateway für Werbetreibende, früher „first-party mode“, ist kein serverseitiges Tracking. Es ist ein Proxy. Statt das Google-Tag von googletagmanager.com zu laden und die Messdaten direkt an Google zu schicken, lädt die Seite das Tag von der eigenen Domain, und ein Teil der Messanfragen läuft über diese Domain zu Google. Ausgeliefert wird das über die vorhandene Infrastruktur: ein CDN, ein Load Balancer, der eigene Webserver oder direkt über Cloudflare, Akamai, Fastly oder Google Cloud. Mit Cloudflare ist es im Tag Manager praktisch ein Schalter.

Ein First-Party-Pfad hilft gegen Domain-Sperrlisten und gegen kurze Cookie-Laufzeiten. Er hilft nicht gegen ein Skript, das gar nicht erst ausgeführt wird.

Was ist eine Trusted Execution Environment?

Eine TEE ist eine besondere Kombination aus Hardware und Software mit einem Hardware-Vertrauensanker. Sie soll verhindern, dass die Verarbeitung von außen beobachtet oder manipuliert wird. Google nennt das im Ads-Kontext Confidential Matching und baut es auf der Confidential-Space-Technik von Google Cloud.

Der Anspruch: Der Abgleich findet in einer abgeschotteten Umgebung statt, auf die auch Google selbst nicht zugreifen kann, und nur das Ergebnis des Abgleichs verlässt sie.

Ist verschlüsselt besser als gehasht?

Für die Sicherheit der Übertragung: vermutlich ja. Ein Hash ist eine Einbahnstraße, aber der Hash einer E-Mail-Adresse ist mit einer Wörterliste angreifbar, weil der Klartextraum klein ist. Verschlüsselung plus abgeschottete Verarbeitung ist technisch der stärkere Schutz.

Für die Rechtslage: nein, sie ändert sich nicht. Siehe den nächsten Abschnitt.

Brauche ich nach dem 19. Oktober weiterhin eine Einwilligung?

Ja. Die Einwilligung bleibt, was sie war.

Ein SHA-256-Hash einer E-Mail-Adresse ist nach herrschender Meinung ein personenbezogenes Datum, nämlich ein Pseudonym. Der EuGH hat am 4. September 2025 in der Sache EDSB gegen SRB (C-413/23 P) bestätigt, dass pseudonymisierte Daten personenbezogen bleiben, wenn eine Zuordnung mit Zusatzwissen möglich ist. Genau darauf beruht erweiterte Conversion-Messung: Der Abgleich funktioniert nur, weil Google denselben Wert aus seinen Kontodaten bilden kann.

Verschlüsselung ändert daran nichts, im Gegenteil. Verschlüsselte Daten sind unstrittig personenbezogen, solange jemand entschlüsseln kann, und in der TEE wird entschlüsselt. Eine TEE ist eine technische Grenze, keine rechtliche. Sie verhindert, dass Personal oder andere Systeme mitlesen. Sie verhindert nicht, dass Daten übermittelt werden, sie begründet keine Rechtsgrundlage, und sie beantwortet die Frage der Zweckbindung nicht. Was mit dem Ergebnis des Abgleichs im Google-Ökosystem geschieht, steht außerhalb der Enklave.

Aufsichtsbehörden haben sich zu Confidential Matching bislang nicht positioniert. Das Risiko trägt weiterhin der Werbetreibende als Verantwortlicher. Wer heute erweiterte Conversions nur nach Einwilligung sendet, sendet sie auch nach dem 19. Oktober nur nach Einwilligung. Das ist keine Rechtsberatung, sondern die nüchterne Lesart der Quellen.

Was ist an dieser Ankündigung unbelegt?

Vier Angaben stehen in keiner öffentlichen Google-Dokumentation. Wer sie anderswo als Tatsache liest, sollte nach der Quelle fragen.

  • Das Datum 19. Oktober 2026 steht bislang nur in der Kontomail, nicht in der Hilfe und nicht in der Entwicklerdokumentation.
  • Wer die Schlüssel hält, sagt Google nicht. Für den Weg über die Data Manager API kann man eigene Schlüssel aus einem Cloud-KMS mitbringen. Für den Browser-Fall steht dazu nichts.
  • Welches Verschlüsselungsverfahren im Browser verwendet wird, ist nicht dokumentiert.
  • Welche Daten Google wann im Klartext sieht, ist nicht dokumentiert.

Betrifft das auch serverseitige Uploads über die Google-Ads-API?

Nein. Für UploadClickConversions gilt weiterhin SHA-256, und in dieser Ankündigung äußert sich Google nicht dazu.

Interessanter für alle, die serverseitig messen, ist eine zweite, leisere Änderung aus diesem Jahr: Seit dem 15. Juni 2026 lässt Google UploadClickConversions nur noch für Entwicklerzugänge zu, die zwischen Dezember 2025 und Juni 2026 nachweislich Offline-Conversions hochgeladen haben. Alle anderen bekommen CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE und werden auf die neue Data Manager API verwiesen. Wer eine Eigenentwicklung oder ein junges Werkzeug einsetzt, sollte das prüfen, bevor stillschweigend Conversions fehlen.

In der Data Manager API gibt es die Server-Entsprechung zu dem, was jetzt im Browser passiert: Man darf die gehashten Identifikatoren zusätzlich verschlüsseln, mit einem eigenen Schlüssel aus Google Cloud KMS oder AWS KMS, und Google entschlüsselt sie nur in der TEE. Das Verfahren ist XChaCha20-Poly1305 mit einem Datenschlüssel, der wiederum mit dem eigenen KMS-Schlüssel gesichert ist. Es ist optional und kostet Einrichtungsaufwand: Schlüsselbund, Workload Identity Federation, Rechtevergabe an Googles Dienstkonto.

Der Unterschied zum Browser-Fall ist genau der Punkt, auf den es ankommt: Auf dem Server kann man eigene Schlüssel halten. Im Browser tut man das nicht.

Was hat Trackdolphin damit zu tun?

Wenig, und das ist der ehrliche Teil. Trackdolphin betreibt kein Tag-Gateway und lädt kein Google-Tag im Browser. Wir melden Käufe serverseitig aus dem Shop-Backend an Google Ads, über UploadClickConversions mit SHA-256. Für uns und unsere Kunden ändert sich am 19. Oktober 2026 nichts, und wir haben bis dahin nichts zu bauen.

Zwei Dinge nehmen wir trotzdem mit. Erstens: Das Gateway ist ein First-Party-Proxy für ein Browser-Tag. Es misst weiter nur das, was der Browser noch ausführt, und nicht den Kauf, bei dem der Browser vor dem Aufruf der Danke-Seite geschlossen wurde. Zweitens: Der Umstieg auf die Data Manager API und die Verschlüsselung mit eigenem Schlüssel stehen bei uns auf der Liste, aber als Reihenfolgefrage, nicht als Notfall. Was daraus wird, schreiben wir hier auf, wenn es soweit ist.

Quellen

Diesen Beitrag als Markdown ↑ Nach oben