Adressdaten für Enhanced Conversions nutzen: Ist das sinnvoll und wie geht es?

Wenn man eine Chrome Erweiterung zum Debugging von "Erweiterten Conversions" für Google Ads baut, muss man sich zwangsweise tiefer mit den Nutzerdaten auseinandersetzen, die auf unterschiedlichen Wegen zu Google Ads gelangen können. Einige Fragen, auf die ich zum Beispiel bei der Erstellung des Enhanced Conversion Data Validators gestoßen bin: Kann man tatsächlich eine Straße auch als Hash-Wert statt im Klartext im user_data Objekt übergeben? Wie genau geht Google vor, wenn eine Straße als Klartext in einen Hashwert verwandelt wird? Wie sieht es bei anderen Diensten aus - oder anderen Adressinformationen? Dieser Post liefert Antworten auf diese Fragen und versucht, das Kosten-Nutzen-Verhältnis realistisch einzuschätzen.

Hashing und Nutzerdaten

Wer "Erweiterte Conversions" nutzen will, benötigt Daten aus Nutzereingaben oder der eigenen Datenbank (bei Anmeldung), die dazu dienen sollen, einen passenden Datensatz im System des Empfängers zu finden. Die Idee dahinter ist, dass der eigene Bestand ebenso auf gleiche Weise normalisiert und mit Hashwerten versehen werden kann. Ankommende Werte können dann gegen die Hashes aus der eigenen Datenbank verglichen werden. Ein Treffer kann dann dazu dienen, eine Aktion wie den Klick auf eine Anzeige mit einer gemeldeten Conversion zu verknüpfen, selbst wenn "klassische" Referenzen wie Klick-IDs aus URL Parametern es nicht geschafft haben, nach dem Entstehen beim Klick bis zur Conversion zu überleben. Dass so etwas nur bei Zustimmung passieren sollte, ist (hoffentlich) selbstverständlich.

Google Ads, Meta, Pinterest, LinkedIn, TikTok (Bäh), Snapchat, Reddit, X (Pfui!), Amazon Ads, Microsoft Ads, Criteo... alle wollen Nutzerdaten zu genau diesem Zweck. Mal wird Klartext verlangt, mal ein Hash. Jeder hat seine eigenen Regeln, deren Unterschiede erfordern, dass vorgehashte Werte im Fall einzelner Felder unterschiedlich behandelt werden müssen.

Der Wert von Adressdaten beim Abgleich

Um einen "vollwertigen" Request wie das folgende Beispiel eines resultierenden em-Parameters zu erzeugen, in dem mehrere Mailadressen und Anschriften zu finden sind, die ein Maximum an Abgleichsignalen bilden, muss eine Menge Aufwand betrieben werden.

Das wirft die Frage auf: Lohnt sich das überhaupt? Während Telefonnummern und E-Mailadressen relativ stabil sind und nach überschaubaren Regeln normalisiert werden können, sieht das bei Anschriften ganz anders aus. Straßen? Ein Horror in den meisten Datenbanken (dazu gleich mehr)! Selbst ein Name kann als Doppelvorname, ohne mittleren Vornamen, mit Initialen etc. gespeichert werden.

Daher wollen die meisten Dienste auch "nur" Stadt, ggf. Staat / Region, PLZ und Land. Und das ist schon schwierig genug. Nehmen wir als Beispiel das Land:

• Meta (Facebook), Pinterest: ISO 2-Letter als SHA-256 Hash. Werte: de, at, ch. Hier muss also alles Kleingeschrieben werden vor Hash.
• Google Ads, LinkedIn: ISO 2-Letter im Klartext, aber bitte groß: DE, AT, CH
• TikTok: Klartext, Kleingeschrieben: de, at, ch. Hier aber wiederum nur bei Web-Events - die API nimmt nur externe IDs, Mailadressen (also Hash) und Telefonnummern (dito).

Mit "Deutschland" oder einem dreistelligen Code wie "DEU", "AUT" oder "SUI" kann hingegen keiner was anfangen. Hier ist daher gern einiges an Arbeit in einem GTM Container oder per Transformation am Server zu erledigen, wenn ankommende Daten für den jeweiligen Dienst umgewandelt werden müssen (was zum Glück meistens eine passende Community-Vorlage oder gar das Tag selbst erledigen kann).

PLZ und Ort sind in Kombination mit dem Land in vielen Fällen unproblematisch und helfen bei der Eingrenzung von Fehltreffern, wenn der Abgleich nur über Namen erfolgt (ohne Mail oder Telefon). Aber eine Straße?

Straßen zum Datenabgleich

Wer wirklich mit der Straße in Nutzerdaten arbeiten will, muss sich daher - kaum verwunderlich - ebenfalls einigen Regeln unterwerfen. Während dort, wo man Klartext in einem Tag anliefern kann, die Arbeit i. d. R. vom Tracking-Code übernommen wird, muss man spätestens dort, wo man selbst einen Hash bilden will, mit den Normalisierungsregeln vertraut sein.

Nicht jeder Dienst nimmt überhaupt eine Straße entgegen. Aber Google Ads (auf verschiedenen Wegen - gtag, API, Measurement Protocol, Uploads) verarbeitet diese Information. Selbst gehashte Werte können dabei z. B. via Browser (GA4, Ads) oder Measurement Protocol (GA4) an Google gesendet werden.  Während bei den meisten Datenfeldern und Diensten die Normalisierungsregeln meistens gleich sind: "alles klein" und je nach Feldtyp auch gern "keine Leerzeichen", ist es bei Straßen (offenbar zumindest) nicht ganz so einfach.

In der Dokumentation zu verschiedenen Wegen, Nutzerdaten an Google zu senden, ist die Frage, ob das Feld "sha256_street" auch für den Browser wirklich existiert, nicht wirklich final zu klären. Noch unklarer ist, wie man beim Hashing genau vorgehen soll. Dass es den Key offenbar auch für user_data gibt, lässt eines der Beispiele in der Hilfe vermuten:

Wenn es aber um die Regeln geht, findet sich nur bei GA4 ein entsprechender Hinweis:

Daher habe ich mir angesehen, was ein Standard Google-Tag aus einer Straße macht, wenn man diese als Klartext in ein Nutzerdatenobjekt packt und als user_data weitergibt. Und tatsächlich: Hausnummern sind weg. Wer demnach selbst einen Hash statt Klartext in den dataLayer schreiben oder per API anliefern will (obschon dies weder per Measurement Protocol noch user_data erforderlich ist - da geht in beiden Fällen auch das Klartextfeld!), muss es vermutlich wie Google machen:

Mit den oben angegebenen Regeln wird so aus der "Bahnhofstr. 22A-C" als Eingangswert für den Hash die "bahnhofstr ac". Klingt komisch, ist aber so. Und dennoch würde es vermutlich nicht matchen, weil es "bahnhofstraße ac" sein sollte (Straße ausgeschrieben), wenn auf der anderen Seite ein Treffer gefunden werden soll. Vermutlich jedenfalls - was wissen wir schon "von außen" so genau?

Dass wir gelegentlich auch "Strasse" statt "Straße" schreiben, macht die Sache nicht leichter, auch ohne "Str." Das gilt übrigens auch dann, wenn Google das Matching selbst übernimmt und wir Klartext einliefern - Sorry.

Noch blöder wird es in Sonderfällen: Der eine schreibt "77A", der nächste "77 A". Oder "16A-C" als Hausnummer, die einen anderen Hash ergibt als "16A - C". Denn die Leerzeichen bleiben erhalten. "Korrekt" für einen einzuliefernden Hash wäre dann "a c" als Hausnummer (zwei Leerzeichen), wenn man sich an die Regeln von Google hält, was aber vermutlich nie zu einem Match führen wird, wenn auf der anderen Seite diese Leerzeichen nicht auch im Datensatz stehen (unwahrscheinlich). Zusätzlich bei der Normalisierung vorhandene Leerzeichen aus Hausnummern zu entfernen, wenn diese auch Buchstaben enthalten, ist deshalb - vermutlich - eine gute Idee... egal ob man selbst den Hash bestimmt oder eine Straße ohne Hash in Nutzerdaten weitergeben will, denn so oder so wird ein Hash daraus im em-Parameter - nach den oben genannten Regeln. Während man beim Bestücken des dataLayers aus dem eigenen CMS heraus noch eine Menge abfangen und vereinheitlichen kann, erfordert die Behandlung von Nutzereingaben auf einer Website, die direkt abgefangen und weitergegeben werden sollen, schnell einige Hundert Zeilen an zusätzlichem Code, der den Tag Manager nicht schlanker macht.

Auch bei anderen Feldern ist eine Normalisierung üblicherweise in den client- und serverseitigen Tags implementiert, aber eben recht unterschiedlich. Und nicht alles wird ausgehend wirklich als Hash versendet:

• Meta z. B. erfordert die Entfernung aller Leerzeichen und Symbole. Hier wird aus einem Ortsnamen wie "Bad Homburg" demnach "badhomburg". Das gilt auch z. B. für TikTok (Web Events)
• Bei Google Ads hingegen wird nur kleingeschrieben, aber keine Leerzeichen entfernt, wenn eine Stadt den Browser verlässt ("bad homburg"), es wird kein Hash verwendet.

Dass die Lage so kompliziert ist, ist sicher auch der Grund, warum unterschiedliche Templates, die es vor allem für den server-seitigen Google Tag Manager gibt, nicht immer alles perfekt machen. Da werden Nutzerdaten aus den eingehenden GA4 Requests (die meistens keiner Normalisierung unterliegen und oft ungehashed sind) entweder als Hash weitergegeben, der nicht zum Format passt (Meta) oder unverändert (keine Kleinschreibung etc.) an TikTok & Co. weitergegeben. Dazu kommt, dass manche Web-Tags hex, andere base64url verwenden, wenn Hashwerte übergeben werden.

Was jetzt: Hashing oder nicht?

Wer Adressen (nicht nur die Straße) als Nutzerdaten für den Abgleich oder zum Tracking von Conversions einsetzen will, darf und sollte bei Daten wie der Telefonnummer oder E-Mail-Adresse spätestens dann, wenn diese im "öffentlichen" dataLayer einer Website landen, dort bereits als Hash vorhalten. Dass man für Google vs. Rest der Welt unterschiedliche Hashes für die Mailadresse nutzen muss (Sonderregelungen für Gmail, siehe dazu z. B. den Abschnitt zur Normalisierung im Post zu Enhanced Conversions) - und dass man für Meta einen anderen Eingangswert bei der Telefonnummer (491771234567 statt +491771234567) verwenden muss, wenn mehrere Dienste bedient werden sollen, ist vertretbarer Aufwand. Wobei: Auch Microsoft Ads hat einen eigenen Weg. mit Mailadressen umzugehen: Punkte werden auch hier entfernt, so dass man (bis auf ein "+" in Gmail-Adressen) den gleichen Hash wie Google verwenden kann (zumindest in der Praxis, wo das "+" in den meisten Datenbanken nur selten zu finden ist).

Ob man sich den Spaß bei der Straße ebenfalls geben muss - und ob andere Daten als die beiden oben genannten überhaupt die Mühe wert sind -, sollte kritisch anhand des eigenen Volumens und zu erwartenden Effekts auf die Erfolgskontrolle und Steuerbarkeit der Kampagnen entschieden werden. Name und Vorname als Hash zu verwenden, ist - zumindest bei Google - ebenso technisch kein Problem, wird aber einen geringen Effekt haben. Da aber bis auf die Straße ohnehin alles andere, was zu einer Adresse gehört, meist als Klartext in den entsprechenden Tags eingereicht werden kann (und je nach Dienst auch muss, weil dieser bestenfalls selbst vor der Übertragung einen Hash bildet), kann man sich vermutlich bei diesen Angaben eher darauf beschränken, die integrierten Hashfunktionen der Tags zu nutzen. Wenn man z. B. die Straße im Klartext an ein Google-Tag übergibt (z. B. via dataLayer), wird diese vom Tag zuerst normalisiert und dann in Hashwerte umgewandelt. Beim Server-Side GTM ist ebenso meist das entsprechende API-Tag dafür verantwortlich und Nutzerdaten werden im Klartext an den Server gesendet. Ein weiteres Argument für Klartext, spätestens bei Übertragung server-to-server: Pre-Hashing nimmt den Plattformen die letzte Reparaturchance. Wenn es also nicht um den Schutz von Angaben im dataLayer geht, mag Klartext manchmal überlegen sein. Nur wissen wir nicht, welche serverseitigen Normalisierungen denn überhaupt stattfinden. Schade...

Empfehlung

Die Mailadresse bleibt der größte Hebel. Eine Telefonnummer zu normalisieren, ist auch noch drin und sinnvoll in vielen Fällen und die meisten Anbieter (außer z. B. LinkedIn) können damit etwas anfangen. Eine "wirkungsvolle" Anschrift (evtl. gar inkl. Straße), korrekt codiertem Land und allem anderen Zapp anzuliefern, ist hingegen kein Pappenstiel. Stellt sich die Frage, ob es den ganzen Aufwand lohnt.

Klar: Wenn es bei 80% der eingelieferten Adressen keinen Unterschied ergibt, weil keine solchen Sonderregelungen im Spiel sind, mag es egal sein. Aber gerade hier, wo wir eine "Teststraße" auch oft als "Teststrasse" oder "Teststr." in der Datenbank (oder als Nutzereingabe) haben, scheint es besonders sinnvoll, sich auf die eher wirkungsvollen Parameter zu beschränken und den Rest nur dann anzugehen, wenn a) das Volumen es rechtfertigt und b) der IT Aufwand in wirtschaftlichen Grenzen bleibt. Zum Trost: Selbst wenn man eine Telefonnummer oder Anschrift in klar beschriebene und benannte Felder in einem Formular eingibt, beschränkt sich der Automatikmodus des Google-Tags üblicherweise auf die Mailadresse als stärkstes Signal. Machen wir es doch einfach genauso 😉