{"id":10466,"date":"2026-09-18T12:30:00","date_gmt":"2026-09-18T10:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10466"},"modified":"2026-10-26T11:52:52","modified_gmt":"2026-10-26T10:52:52","slug":"kundendaten-fur-die-meta-conversions-api-vorbereiten-richtig-formatieren-und-hashen","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-marketing-de\/kundendaten-fur-die-meta-conversions-api-vorbereiten-richtig-formatieren-und-hashen\/","title":{"rendered":"Kundendaten f\u00fcr die Meta Conversions API vorbereiten: Richtig formatieren und hashen"},"content":{"rendered":"

SHA-256 berechnet aus den Eingabedaten einen Wert fester L\u00e4nge. Dieser Wert hei\u00dft Hash. Eine erfolgreiche Antwort der Conversions API best\u00e4tigt keine korrekte Zuordnung einer E-Mail-Adresse. Ein SHA-256-Wert kann formal plausibel aussehen und trotzdem aus falsch vorbereiteten Daten stammen. Zugleich k\u00f6nnen andere Kennungen zur Zuordnung beitragen. API-Annahme, Datenqualit\u00e4t und tats\u00e4chliches Matching sind deshalb getrennt zu pr\u00fcfen.<\/p>\n

Normalisierung bedeutet hier: einen Eingabewert vor dem Hashen in die f\u00fcr das jeweilige Feld vorgesehene Form bringen. Die Reihenfolge lautet beispielsweise bei E-Mail-Adressen: \u00e4u\u00dfere Leerzeichen entfernen, in Kleinbuchstaben umwandeln, anschlie\u00dfend SHA-256 berechnen. Eine nachtr\u00e4gliche \u00c4nderung am Hash repariert keinen Eingabefehler.<\/p>\n

\"Zwei
Zwei Schreibweisen, zwei Hashwerte. Der lokale Sollwertvergleich belegt weder API-Annahme noch Attribution.<\/figcaption><\/figure>\n

Warum die genaue Eingabe z\u00e4hlt<\/h2>\n

SHA-256 verarbeitet Bytes. Schon Leerzeichen oder Gro\u00dfbuchstaben ver\u00e4ndern das Ergebnis. Im Beispiel ergeben drei Schreibweisen derselben fiktiven Adresse drei verschiedene Hashwerte. F\u00fcr den Vergleich mit dem erwarteten Hash z\u00e4hlt die normalisierte Schreibweise. Daraus folgt weder, dass Meta andere Werte gar nicht vergleicht, noch dass das gesamte Ereignis ohne Zuordnung bleibt.<\/p>\n

Feldregeln statt einer Funktion f\u00fcr alles<\/h2>\n

Die folgende \u00dcbersicht ist eine Orientierung f\u00fcr die Integration. Ma\u00dfgeblich bleiben das aktuelle Meta-Feldschema und die tats\u00e4chlich eingesetzte SDK-Version. Ein SDK ist eine Programmbibliothek f\u00fcr die Anbindung an die API. Diese Bibliothek kann bereits normalisieren und hashen; eine zus\u00e4tzliche Verarbeitung davor muss dazu passen.<\/p>\n\n
Feld<\/th>Vorbereitung und Pr\u00fcfpunkt<\/th><\/tr><\/thead>
em<\/code><\/td>\u00c4u\u00dferen Leerraum entfernen und kleinschreiben; keine erfundenen Korrekturen am Adressteil.<\/td><\/tr>\n
ph<\/code><\/td>Internationale Telefonnummer mit L\u00e4ndervorwahl, f\u00fcr das Hashing nur Ziffern. L\u00e4nderabh\u00e4ngige Vorwahlen vorher korrekt aufl\u00f6sen.<\/td><\/tr>\n
fn<\/code>, ln<\/code><\/td>Kleinschreibung und \u00e4u\u00dferen Leerraum pr\u00fcfen. Die gepr\u00fcften Python-\/Node.js-Helfer entfernen hier nicht pauschal alle inneren Leerzeichen und Satzzeichen.<\/td><\/tr>\n
ct<\/code><\/td>Ortsname klein, ohne Leerzeichen und Satzzeichen gem\u00e4\u00df Feldvorgabe; das konkrete Verhalten des SDK mit Beispielen pr\u00fcfen.<\/td><\/tr>\n
country<\/code>, st<\/code><\/td>Land als zweibuchstabigen ISO-L\u00e4ndercode wie de<\/code>. Regionsangaben gesondert behandeln; ein US-Bundesstaatsk\u00fcrzel ist keine weltweite Regionsregel.<\/td><\/tr>\n
ge<\/code>, db<\/code><\/td>Falls vorhanden und zul\u00e4ssig: f<\/code>\/m<\/code> beziehungsweise g\u00fcltiges Datum in YYYYMMDD<\/code>. Fehlende Angaben nicht erraten.<\/td><\/tr>\n<\/tbody><\/table>\n

Telefonnummern lassen sich mit L\u00e4nderinformationen und einer gepflegten Bibliothek wie libphonenumber automatisiert verarbeiten. Blo\u00dfes Entfernen aller Nichtziffern reicht nicht: Im deutschen Beispiel +49 (0)170 1234567<\/code> bliebe eine \u00fcberfl\u00fcssige Null erhalten. Eine Null darf jedoch nicht weltweit nach der L\u00e4ndervorwahl gel\u00f6scht werden; etwa bei italienischen Nummern kann die f\u00fchrende Null Bestandteil der internationalen Nummer sein. Unklare Eingaben ben\u00f6tigen eine Kl\u00e4rung. Eine Formatpr\u00fcfung beweist au\u00dferdem keine aktuelle Erreichbarkeit.<\/p>\n\n\n\n

\"W\u00e4sche
W\u00e4sche liegt nach Art sortiert in drei K\u00f6rben, ein Seidentuch h\u00e4ngt ganz f\u00fcr sich. Genauso braucht jede Art von Kundendaten vor dem Hashen (dem Unkenntlichmachen) ihre eigene Regel.<\/figcaption><\/figure>\n\n\n

Welche Werte ungehasht bleiben<\/h2>\n

client_ip_address<\/code>, client_user_agent<\/code>, fbp<\/code> und fbc<\/code> werden nach dem jeweiligen Schema ungehasht \u00fcbermittelt. Das bedeutet nicht, dass diese Angaben datenschutzrechtlich unbedenklich oder ohne Personenbezug w\u00e4ren. Die IP-Adresse muss zum Ereignis passen; eine Proxy-Adresse ersetzt keine Browseradresse. Cookie- und Klickkennungen d\u00fcrfen nicht beliebig erfunden werden.<\/p>\n

Das sind wichtige Beispiele, keine vollst\u00e4ndige Liste aller API-Felder. Eine explizite Feldzuordnung legt fest, welche Werte validiert, normalisiert, gehasht oder unver\u00e4ndert \u00fcbertragen werden. Neue Felder ben\u00f6tigen eine eigene Entscheidung statt einer pauschalen Hash-Schleife \u00fcber das gesamte Objekt.<\/p>\n

Ein reproduzierbarer Test ohne echte Kundendaten<\/h2>\n

Dieses Python-Beispiel berechnet die vollst\u00e4ndigen Hashwerte einer fiktiven Adresse. Die ersten beiden Ergebnisse beginnen mit 524d6368<\/code> und de4c5edc<\/code>; die normalisierte Fassung beginnt mit dd432348<\/code>.<\/p>\n

Python<\/span>