Die E-Mail, die du nicht mehr verschicken solltest
"Hi, Kundenliste für die Kampagne im Anhang" – mit einer rohen CSV voller Namen, E-Mail-Adressen und Telefonnummern, an ein Agentur-Postfach geschickt, weitergeleitet an wen auch immer die Anzeigen schaltet, für immer lebendig in drei Mail-Archiven. Die Agentur brauchte die lesbaren Adressen nie. Sie brauchte eine Datei, die die Werbeplattform abgleichen kann. Das sind zwei verschiedene Dateien – und du kannst die zweite erzeugen, ohne die erste jemals zu teilen.
Warum das überhaupt funktioniert
Werbeplattformen gleichen Kundenlisten über gehashte Identifikatoren ab – Google Ads und Meta dokumentieren beide, dass sie SHA-256-Digests normalisierter E-Mail-Adressen und Telefonnummern akzeptieren. Die Plattform vergleicht deine Digests mit ihren eigenen; an keiner Stelle muss deine Liste für die Menschen lesbar sein, die die Kampagne betreuen. Die Arbeitsteilung ist also sauber: Du normalisierst und hashst in deiner eigenen Tabelle, die Agentur bekommt Digests und lädt sie hoch.
Der Ablauf
- Zuerst je Zielplattform normalisieren – hier lauert die Falle. Googles dokumentiertes Telefonformat ist E.164 mit
+; Metas sind Ziffern mit Ländervorwahl, ohne Plus. Eine Nummer, zwei Formate, zwei verschiedene Digests – frag die Agentur also nach den Plattformen, bevor du hashst, und erzeuge eine gehashte Spalte pro Plattform. (Die vollständigen Regeln je Plattform stehen in unseren Leitfäden zu Customer Match und Custom Audiences.) - In der Tabelle hashen – SHA-256, Hex. Google Tabellen hat keine eingebaute Hash-Funktion, das läuft also über Apps Script oder ein Add-on.
- Die Datei entkernen, bevor sie reist. Kopiere die gehashten Spalten, füge sie als Werte in eine frische Tabelle ein und prüfe, dass die Datei sonst nichts enthält – keine Rohspalte, die sich ganz rechts versteckt, kein zweites Tabellenblatt mit der ursprünglichen Einfügung, keine benannten Bereiche, die Daten mitschleppen.
- Mit einer einzeiligen Spezifikation verschicken: für welche Plattform welche Spalte gedacht ist und dass die Digests SHA-256 in Hex-Kleinbuchstaben über plattformnormalisierte Werte sind. Dieser eine Satz verhindert, dass die Agentur die Daten erneut hasht oder "repariert" – die häufigste Art, wie eine saubere Übergabe stirbt.
Was das nicht leistet
Ehrlichkeit, weil sie hier zählt: Eine gehashte Liste ist pseudonymisiert, nicht anonymisiert – Aufsichtsbehörden behandeln sie als personenbezogene Daten, und kleine Schlüsselräume wie Telefonnummern lassen sich per Brute Force durchgehen. Die gehashte Datei sollte unter derselben Vereinbarung reisen, die auch die Rohdatei gebraucht hätte; was sich ändert, ist die Exposition, nicht die Pflicht. Scheitert der Prozess der Agentur, lecken Digests statt Adressen – ein deutlich kleinerer Wirkungsradius, kein Nichtereignis.
Wo Hash Data hineinpasst
Hash Data hält Schritt 2 in Google Tabellen: Hash-Funktionen in den Zellen, =HASHPHONE() normalisiert auf E.164 und hasht in einem Schritt für die Google-formatierte Spalte. Die Liste wird kampagnenbereit, ohne dass eine Kopie davon je in einen Web-Hasher eingefügt oder roh an eine E-Mail angehängt wurde.
Quellen
- Google Ads-Hilfe – Kundendatendatei formatieren – gelesen am 20.08.2026
- Meta – Custom Audiences guide – gelesen am 20.08.2026
- EDSA-Leitlinien 01/2025 zur Pseudonymisierung – gelesen am 20.08.2026