# 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

- [Google Ads Hilfe: Google-Tag-Gateway mit einer TEE](https://support.google.com/google-ads/answer/16708237)
- [Google: Tag-Gateway für Werbetreibende einrichten](https://developers.google.com/tag-platform/tag-manager/gateway/setup-guide)
- [Google Ads Data Manager Hilfe: Confidential Matching](https://support.google.com/google-ads-data-manager/answer/14577185)
- [Google Blog: How confidential matching simplifies data privacy](https://blog.google/products/ads-commerce/google-confidential-matching-data-privacy/)
- [Data Manager API: Nutzerdaten verschlüsseln](https://developers.google.com/data-manager/api/devguides/concepts/encryption)
- [Google Ads API: Click Conversions hochladen, inklusive Sperre ab 15. Juni 2026](https://developers.google.com/google-ads/api/docs/conversions/upload-clicks)
- [EuGH, Urteil vom 4. September 2025, C-413/23 P, EDSB gegen SRB](https://dejure.org/dienste/vernetzung/rechtsprechung?Gericht=EuGH&Datum=04.09.2025&Aktenzeichen=C-413%2F23)