Die Plattform sagt dir nicht, was schiefging
Googles API-Dokumentation benennt den Fehlermodus unmissverständlich: Falsch formatierte Daten werden trotzdem angenommen – "but it can't be matched with a customer." Angenommen und nicht gematcht sieht exakt so aus wie hochgeladen und ignoriert. Die Diagnose liegt also bei dir, und die folgenden Ursachen sind danach sortiert, wie günstig sie zu prüfen sind.
1. Du hast eine gehashte Spalte für mehrere Plattformen wiederverwendet (30 Sekunden)
Google Ads dokumentiert E.164-Telefonnummern mit +; Meta dokumentiert reine Ziffern mit Ländervorwahl – das Beispiel dort lautet 16505551212. Dieselbe Nummer, auf beide Arten gehasht, ergibt zwei völlig unabhängige Digests, und nur eine Plattform kann jeweils matchen. Wenn eine Plattform sauber matcht und die andere kaum, ist das mit ziemlicher Sicherheit die Ursache.
2. Du hast den Anzeigewert gehasht (1 Minute)
(650) 555-1212 ist nicht 16505551212, und John@Example.com – Großbuchstaben, Leerzeichen am Ende – ist nicht john@example.com. Beide Plattformen dokumentieren Kleinschreibung und getrimmte Werte; prüfe den tatsächlichen Inhalt einer Zelle gegen das, was du zu hashen glaubtest. Achte auf das geschützte Leerzeichen: TRIM() entfernt es nicht, und CSV-Exporte setzen es unsichtbar ein.
3. Doppeltes Hashen oder Abschneiden (1 Minute)
Ein SHA-256-Hex-Digest ist exakt 64 Zeichen lang. =LEN(B2)=64 die Spalte hinuntergezogen findet in einem Durchgang sowohl eine Formel, die über bereits gehashte Werte lief (128 Zeichen Unsinn hinein, Digest eines Digests heraus), als auch abgeschnittene Zellen.
4. Falsche Kodierung (5 Minuten)
Base64-Ausgabe oder Hex in Großbuchstaben, wo Kleinschreibung vorgeschrieben ist – Meta dokumentiert Kleinbuchstaben-Hex ausdrücklich. Der saubere Test: Hashe Metas veröffentlichten Testwert john_smith@gmail.com und vergleiche mit dem veröffentlichten Digest (62a14e44…f62f). Falsche Form oder falsche Schreibweise heißt: Das Werkzeug ist schuld, nicht die Liste.
5. Die Tabelle hat die Daten vorher zerstört (10 Minuten)
Verlorene führende Nullen, lange Nummern in wissenschaftlicher Notation, +44-Zellen, die als Formel interpretiert werden – alles lautlos, alles vor dem Hashen. Scrolle die Rohspalte durch und halte nach E+ und verdächtig kurzen Nummern Ausschau. Das lässt sich nicht an Ort und Stelle beheben: neu in eine Klartextspalte importieren und wieder aufbauen.
6. Plattformspezifische Regeln übersprungen (10 Minuten)
Google dokumentiert eine Gmail-spezifische E-Mail-Bereinigung – Punkte und +-Zusätze werden ausschließlich bei gmail.com- und googlemail.com-Adressen entfernt. Eine Liste mit vielen Gmail-Adressen, generisch normalisiert, schwächelt genau in diesen Zeilen.
7. Es war nie ein Formatproblem
Der ehrliche Schlussabschnitt: Gematcht wird gegen die angemeldeten Nutzer der Plattform. Eine veraltete Liste, eine kleine Liste oder eine Liste voller Funktionsadressen (info@, buchhaltung@) matcht schlecht, egal wie perfekt das Hashing ist. Wenn die Schritte 1 bis 6 alle sauber sind, liegt die Lösung in der Listenqualität – Aktualität und echte persönliche Adressen –, nicht in einem weiteren Formatierungsdurchgang.
Wo Hash Data hineinpasst
Die meisten der obigen Fehler passieren in der Lücke zwischen "richtig normalisieren" und "richtig hashen". Hash Data schließt diese Lücke in der Tabelle selbst: =HASHPHONE() normalisiert eine Nummer auf E.164 und hasht sie in einem Schritt, und die Algorithmus-Funktionen liefern die Standard-Hex-Form, die die Plattformen erwarten.
Quellen
- Google Ads API – Get started with Customer Match – gelesen am 20.08.2026
- Google Ads-Hilfe – Kundendatendatei formatieren – gelesen am 20.08.2026
- Meta – Conversions API customer information parameters – gelesen am 20.08.2026