Hashing in der Conversions API: Kundendaten vor SHA-256 normalisieren und welche Felder ungehasht bleiben
Inhalt
Ein Conversions-API-Ereignis mit einer gestreuten E-Mail-Adresse sieht gleich aus, ob richtig oder falsch gestreut wurde. Die Nutzlast ist gültig, die Schnittstelle antwortet mit einem Erfolg, der Ereigniszähler steigt, und die Übereinstimmungsgüte bleibt, wo sie war – weil die Adresse, korrekt zu einer Zeichenkette gestreut, die keiner entspricht, mit einem Kundenbestand verglichen und in keinem gefunden wurde.
Das ist die Art des Scheiterns, die vor aller Verrohrung verstanden sein sollte: Streuen scheitert nicht laut, es scheitert, indem es etwas hervorbringt, das technisch einwandfrei und inhaltlich leer ist.
Warum ein kleiner Unterschied ein vollständiger ist
Eine Streufunktion ist so gebaut, dass eine winzige Änderung der Eingabe eine bis zur Unkenntlichkeit verschiedene Ausgabe erzeugt. Diese Eigenschaft macht das Streuen brauchbar, und genau sie macht einen Normalisierungsfehler tödlich: Beinahe-Übereinstimmung gibt es nicht. Zwei Streuwerte sind gleich, oder sie haben nichts miteinander zu tun, und keine noch so unscharfe Zuordnung weiter hinten holt den Unterschied wieder ein.
Ob ein Ereignis eine Person findet, entscheidet sich also, bevor die Streufunktion überhaupt aufgerufen wird – in den wenigen Zeilen, die festlegen, was genau hineingeht.
Die Form, in der jeder Parameter stehen muss
| Parameter | Verlangte Form | Was schiefgeht |
|---|---|---|
em |
beschnitten, klein | ein Großbuchstabe aus dem Formular, ein Leerzeichen aus der Zwischenablage |
ph |
nur Ziffern, mit Ländervorwahl | die nationale Null in +49 (0)170 überlebt |
fn, ln |
klein, ohne Satzzeichen und Leerraum | der Bindestrich in einem Doppelnamen |
ct |
klein, ohne Leerzeichen | Frankfurt am Main behält seine Leerzeichen |
st, country |
zweibuchstabiges Kürzel, klein | das Land steht ausgeschrieben da |
ge |
genau f oder m |
alles andere, gestreut als wäre es ein Wert |
db |
JJJJMMTT | ein landesübliches Datumsformat, lautlos umsortiert |
Die Telefonnummer verdient eine eigene Anmerkung, denn sie ist der eine Fall, der sich nicht maschinell normalisieren lässt. Aus +49 (0)170 1234567 alle Nichtziffern zu entfernen ergibt 4901701234567, und die Null hinter der Ländervorwahl ist eine nationale Vorwahlkennziffer, die in einer internationalen Nummer nichts zu suchen hat. Keine Regel entscheidet das für jedes Land verlässlich, weshalb die ehrliche Behandlung darin besteht, zu entfernen und das verdächtige Muster einem Menschen zu melden, statt zu raten.
Die Parameter, die nicht gestreut werden dürfen
Der umgekehrte Fehler ist seltener und ebenso endgültig. client_ip_address, client_user_agent, fbp und fbc werden im Klartext gesendet. Sie sind keine Kennungen in dem Sinn, in dem die gestreuten Felder es sind; sie sind Werte, die Meta gegen die eigenen Aufzeichnungen hält, und ein gestreuter davon ist eine Zeichenkette, der auf der anderen Seite nichts entspricht.
Am häufigsten passiert das, wenn eine Streuhilfe auf das gesamte Nutzerdatenobjekt auf einmal angewandt wird – ein vernünftig aussehendes Stück Code, das in genau vier Feldern falsch ist. Eine Hilfe, die nach Feldnamen streut statt nach Objekt, ist die Fassung, die eine Schemaänderung übersteht.
Wie sich das von außen zeigt
# dieselbe Adresse, drei Wege
" Max.Mustermann@Example.COM " → 524d6368ceb086b2b1d8fed14ee75313…
" max.mustermann@example.com " → de4c5edc5348280eedb5b029d7851764…
"max.mustermann@example.com" → dd432348e6c3373c5f646913fa94ae79…
# verglichen wird nur der dritte mit irgendetwasKeiner davon erzeugt einen Fehler. Die Ereigniszahl im Ereignismanager ist in allen drei Fällen gleich, die Zustellung wird in allen drei Fällen bestätigt, und die einzige Größe, die sich bewegt, ist die Übereinstimmungsgüte – nach unten, langsam, und auf eine Weise, die sich bequem der Jahreszeit oder einer Änderung an der Einwilligung zuschreiben lässt.
Die brauchbare Prüfung ist deshalb nicht die Antwort der Schnittstelle, sondern ein Vergleich gegen einen bekannten Wert. Eine Adresse aus dem Kundenbestand nehmen, sie so streuen, wie der Shop es tut, sie so streuen, wie die Vorschrift es verlangt, und die beiden Zeichenketten vergleichen. Sie stimmen überein, oder die Verarbeitungskette hat einen Normalisierungsfehler – und die Antwort dauert eine Minute.
Wohin die Normalisierung gehört
Die letzte Entscheidung ist eine des Aufbaus. Normalisieren lässt sich im Browser, im Servercontainer oder in dem System, das den Kundeneintrag führt – und nur das letzte hat den ursprünglichen Wert in der Form vorliegen, in der ihn auch der Kundenbestand hält.
Es im serverseitigen Container zu tun, ist der übliche Mittelweg und trägt, sofern der Container den Rohwert bekommt und nicht etwas, das ein Formular bereits zugerichtet hat. Es im Browser zu tun, ist die eine Anordnung, die zu vermeiden ist: Sie legt die Adresse im Klartext in eine Anfrage, die das Gerät des Besuchers verlässt – genau das, was das Streuen verhindern sollte.
Quellen
Passend dazu
