English
Deutsch
PolskiHashing 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.
Fragen und Antworten
Macht das Streuen die Kundendaten datenschutzrechtlich anonym?
Nein. Ein Streuwert, den Meta mit dem eigenen Kundenbestand abgleichen kann, ist pseudonymisiert und nicht anonym, und pseudonymisierte Daten bleiben nach der DSGVO personenbezogen; die Zuordnung zu einer Person ist hier sogar der Zweck. Das Streuen verhindert, dass die Adresse im Klartext übertragen wird, ersetzt aber weder die Rechtsgrundlage noch die Einwilligung.
Was geschieht, wenn ein Wert auf dem Weg zu Meta zweimal gestreut wird?
Dasselbe wie bei einem Normalisierungsfehler: Die Nutzlast ist gültig, die Schnittstelle meldet Erfolg, und keine Person wird gefunden. Ein Streuwert eines Streuwerts ist wieder eine Zeichenkette aus 64 Hexadezimalzeichen, sieht also aus wie ein richtiger und entspricht doch keinem Eintrag auf der anderen Seite.
Der Fall entsteht dort, wo zwei Stufen je für sich vernünftig handeln. Das Shopsystem liefert die Adresse bereits gestreut an den Servercontainer, und ein Tag dort streut jedes Feld der Nutzerdaten noch einmal. Keine der beiden Stufen ist für sich falsch, erst die Kette ist es.
Die übliche Absicherung ist eine Prüfung vor dem Streuen: Besteht ein Wert bereits aus genau 64 Zeichen aus 0–9 und a–f, wird er durchgereicht statt erneut gestreut. Eine E-Mail-Adresse erfüllt dieses Muster nie, weil sie ein @ enthält, und eine Telefonnummer ebenso wenig, weil E.164 höchstens 15 Ziffern zulässt. Den Rest fängt der Vergleich gegen einen bekannten Wert ab, den der Artikel beschreibt, sofern er am Ende der Kette ansetzt, also an der Nutzlast, die tatsächlich an Meta geht, und nicht an einer Zwischenstufe.
Wie sind Postleitzahl und external_id zu behandeln, die in der Tabelle fehlen?
Die Postleitzahl (zp) wird gestreut und steht davor kleingeschrieben, ohne Leerzeichen und ohne Bindestrich: Aus der polnischen Postleitzahl 00-950 wird 00950, aus der niederländischen 1012 AB wird 1012ab. Für die USA verlangt Meta nur die ersten fünf Ziffern.
external_id ist eine eigene Kennung des Shops, etwa die Kundennummer. Meta empfiehlt das Streuen, verlangt es aber nicht. Entscheidend ist die Gleichheit: Wird die Kennung auch über das Pixel gesendet, muss sie auf beiden Wegen in derselben Form ankommen, gestreut oder nicht, denn sonst sind es für Meta zwei verschiedene Kennungen.
Quellen
Passend dazu
