Hashing in der Conversions API: Kundendaten vor SHA-256 normalisieren und welche Felder ungehasht bleiben

SHA-256 berechnet aus den Eingabedaten einen Wert fester Länge. Dieser Wert heißt Hash. Eine erfolgreiche Antwort der Conversions API bestätigt keine korrekte Zuordnung einer E-Mail-Adresse. Ein SHA-256-Wert kann formal plausibel aussehen und trotzdem aus falsch vorbereiteten Daten stammen. Zugleich können andere Kennungen zur Zuordnung beitragen. API-Annahme, Datenqualität und tatsächliches Matching sind deshalb getrennt zu prüfen.

Normalisierung bedeutet hier: einen Eingabewert vor dem Hashen in die für das jeweilige Feld vorgesehene Form bringen. Die Reihenfolge lautet beispielsweise bei E-Mail-Adressen: äußere Leerzeichen entfernen, in Kleinbuchstaben umwandeln, anschließend SHA-256 berechnen. Eine nachträgliche Änderung am Hash repariert keinen Eingabefehler.

Warum die genaue Eingabe zählt

SHA-256 verarbeitet Bytes. Schon Leerzeichen oder Großbuchstaben verändern das Ergebnis. Im Beispiel ergeben drei Schreibweisen derselben fiktiven Adresse drei verschiedene Hashwerte. Für den Vergleich mit dem erwarteten Hash zählt die normalisierte Schreibweise. Daraus folgt weder, dass Meta andere Werte gar nicht vergleicht, noch dass das gesamte Ereignis ohne Zuordnung bleibt.

Feldregeln statt einer Funktion für alles

Die folgende Übersicht ist eine Orientierung für die Integration. Maßgeblich bleiben das aktuelle Meta-Feldschema und die tatsächlich eingesetzte SDK-Version. Ein SDK ist eine Programmbibliothek für die Anbindung an die API. Diese Bibliothek kann bereits normalisieren und hashen; eine zusätzliche Verarbeitung davor muss dazu passen.

Telefonnummern lassen sich mit Länderinformationen und einer gepflegten Bibliothek wie libphonenumber automatisiert verarbeiten. Bloßes Entfernen aller Nichtziffern reicht nicht: Im deutschen Beispiel +49 (0)170 1234567 bliebe eine überflüssige Null erhalten. Eine Null darf jedoch nicht weltweit nach der Ländervorwahl gelöscht werden; etwa bei italienischen Nummern kann die führende Null Bestandteil der internationalen Nummer sein. Unklare Eingaben benötigen eine Klärung. Eine Formatprüfung beweist außerdem keine aktuelle Erreichbarkeit.

Welche Werte ungehasht bleiben

client_ip_address, client_user_agent, fbp und fbc werden nach dem jeweiligen Schema ungehasht übermittelt. Das bedeutet nicht, dass diese Angaben datenschutzrechtlich unbedenklich oder ohne Personenbezug wären. Die IP-Adresse muss zum Ereignis passen; eine Proxy-Adresse ersetzt keine Browseradresse. Cookie- und Klickkennungen dürfen nicht beliebig erfunden werden.

Das sind wichtige Beispiele, keine vollständige Liste aller API-Felder. Eine explizite Feldzuordnung legt fest, welche Werte validiert, normalisiert, gehasht oder unverändert übertragen werden. Neue Felder benötigen eine eigene Entscheidung statt einer pauschalen Hash-Schleife über das gesamte Objekt.

Ein reproduzierbarer Test ohne echte Kundendaten

Dieses Python-Beispiel berechnet die vollständigen Hashwerte einer fiktiven Adresse. Die ersten beiden Ergebnisse beginnen mit 524d6368 und de4c5edc; die normalisierte Fassung beginnt mit dd432348.

import hashlib

samples = [
    "  Max.Mustermann@Example.COM ",
    "  max.mustermann@example.com ",
    "max.mustermann@example.com",
]
for value in samples:
    print(repr(value), hashlib.sha256(value.encode("utf-8")).hexdigest())

expected = "dd432348e6c3373c5f646913fa94ae7947bc0086b42028aedec4371e3e3c2cdb"
normalised = samples[0].strip().lower()
assert hashlib.sha256(normalised.encode("utf-8")).hexdigest() == expected

Der Test belegt die lokale Berechnung, keine Zuordnung durch Meta. Für die Integration muss derselbe Testwert durch die gesamte Verarbeitung bis zu den endgültig an Meta gesendeten Daten laufen. Zusätzlich gehören leere Werte, internationale Telefonnummern, Postleitzahlen und bereits gehashte Eingaben in die Tests. Rohdaten oder echte Kennungen gehören dafür nicht in ungeschützte Protokolle.

API-Fehler und Warnungen bleiben relevant. Ein unpassender Hash kann unbemerkt bleiben; ungültige Eingaben können aber bereits vom SDK zurückgewiesen werden. Die Event Match Quality ist ein Diagnosehinweis und kein Nachweis, dass ein bestimmtes Ereignis einer bestimmten Person zugeordnet wurde. Eine feste Änderung dieser Kennzahl oder der Ereigniszahl lässt sich aus einem einzelnen Hashfehler nicht vorhersagen.

Browser oder Server: entscheidend ist der Datenfluss

Normalisierung und Hashing sind sowohl im Browser als auch auf einem Server möglich. Meta bietet dafür auch einen clientseitigen Parameter-Builder. Browser-Hashing erzwingt keine Übertragung der rohen Adresse: Ob Rohdaten das Gerät verlassen, hängt von den tatsächlichen Requests und weiteren Skripten ab. Ein Backend kann ebenfalls Rohdaten empfangen und damit eigene Schutzpflichten auslösen.

Die Integration braucht eine klar benannte verantwortliche Verarbeitungsstufe, einen dokumentierten Eingabestatus und eine Kontrolle der ausgehenden Daten. Ein geheimer CAPI-Zugriffstoken gehört nicht in öffentlich ausgelieferten Browsercode. Hashing ersetzt weder Transportverschlüsselung noch eine zulässige Verarbeitung.