Adressvalidierung: Allgemeines und Hintergrund - addresssolutions/as-address-solutions-validator GitHub Wiki
Für wen ist dieses Modul gedacht?
Sie betreiben eine Webseite und stellen Ihren Kunden/Interessenten eine Seite zur Verfügung, auf der man sich registrieren kann wobei auch Name und Anschrift erfasst werden? Dann kennen Sie das Problem! Diese Angaben werden durch den Anwender oft versehentlich unvollständig, falsch oder gar bewusst fehlerhaft eingegeben. Denn auch sogenannte Fake-Adressen sind ein Problem mit zwar gelegentlich phantasievollen aber nicht existenten Namen und Adressen.
Wenn Ihnen dieses Thema bekannt ist, die Bedeutung und Hintergründe von Adressdatenqualität bewusst sind und Sie vornehmlich an technischen Informationen interessiert sind, wie unser Adress-Validierungs-Modul eingesetzt wird, können Sie direkt zu Seite 2 "Features und Installation" dieses Wikis gehen. Für alle Anderen seien die nachfolgende Ausführungen wärmstens empfohlen. Derjenige, der sich direkt an einem Live-Beispiel ein Bild machen möchte, sei auf diese Seite verwiesen: http://185.82.86.101:9001/address_validation_mask
Beispiel-Screenshot einer Eingabeprüfung
Die Problematik
Die erste Kategorie der o.g. Fehlerquellen ist vermutlich die häufigste. Dabei handelt es sich um die Dateneingabe tatsächlich interessierter Personen oder Kunden, die eigentlich ein Interesse daran haben, ihre Daten korrekt zu hinterlegen, weil sie vielleicht etwas bestellen und die Lieferung ja auch ankommen soll. Aber wie schnell hat man sich vertippt und statt "Andreas" "Anrdeas" eingegeben oder "Rlf" statt "Ralf". Auch das Platzieren von Namenselementen in die falschen Felder kommt vor, z.B. das Vertauschen von Vor- und Nachnamen oder der Titel wird irgendwo im Namen abgelegt - nur nicht im dafür vorgesehenen Titelfeld. Eine andere, nicht selten auftretende und unangenehme Fehlerquelle ist die falsche Auswahl einer Anrede bzw. des Gender-Kennzeichens. Unangenehm ist es deshalb, weil Sie Ihren Kunden künftig mit "Herr" statt "Frau" ansprechen bzw. umgekehrt. Dies sieht wohl kein Kunde gerne. Vermutlich hat jeder diese Erfahrung selbst schon einmal gemacht. Nicht zuletzt ist aber auch die korrekte Schreibweise eines Namens nicht unbedeutend. Gerade im Zeitalter der mobilen Web-Clients wie Smartphones oder Tablets wird der Name und/oder die Anschrift durch den Benutzer oft nicht in sorgfältiger Groß-/Kleinschreibung eingetragen oder Umlaute werden falsch erfasst, etc. Angeschrieben werden möchte man als Kunde aber dennoch in einer landes-/kulturüblich korrekten Weise. Schließlich ist man Kunde und der Anbieter sollte einem ja die gebührende Aufmerksamkeit zukommen lassen. Bei den bisher beschriebenen Problemfällen und Beispielen haben wir uns auf die Namensfelder bezogen. Gleiches gilt natürlich auch für die postalischen Elemente, wie PLZ, Ort, Straße und Hausnummer. Deren korrekte Erfassung ist besonders dann von enormer Wichtigkeit, wenn neben der digitalen Anbieter-Kunde-Beziehung auch der traditionelle Postweg seinen Adressaten finden soll.
Schauen Sie sich folgendes Beispiel an:
Welcher Adress-Tabelle würden Sie ad-hoc mehr Vertrauen schenken? Richtig! Der zweiten. Ohne die Datenqualität inhaltlich schon genau geprüft zu haben, erweckt die zweite Tabelle schon rein optisch den Eindruck einer verlässlicheren Datenlage. Alle Felder sind homogen gefüllt und standardisiert. Der zweite Blick auf die durchgeführten Korrekturen offenbart dann das tatsächliche Qualitätsproblem der ersten Auflistung, wenn man die Veränderungen markiert.
Wie schafft man das?
Es gibt verschiedene Wege zur Datenqualität, die hier kurz angerissen werden
- Bereinigung/Korrektur der Daten im Backend-System
- Syntaktische Prüfungen bei der Erfassung
- Semantische Prüfungen bei der Erfassung
Die erste Methode bedeutet eine nachträgliche Bereinigung der Stammdaten, nachdem der Kunde sich erfolgreich angemeldet hat. Dafür müssen Methoden, Ressourcen und auch Manpower aktiviert werden, die mangelhafte Daten identifizieren und korrigieren. Nicht alles geht automatisch, daher ist oft der manuelle Eingriff erforderlich. Auch muss wahrscheinlich Kontakt zum Kunden aufgenommen werden, da man die von ihm autorisierten Daten verändert, was rechtlich oft nicht unproblematisch ist. Darüber hinaus muss man dafür sorgen, dass die (fehlerhaften) Daten in nachgelagerten Systemen korrigiert werden, falls sie vorab schon automatisch weitergeleitet wurden. Insgesamt ist diese Methode daher so weit wie möglich zu vermeiden und auf ein Minimum zu reduzieren. Sich auf dieses Verfahren als alleiniges Datenqualitäts-Werkzeug zu beschränken ist zwar besser als Nichts, aber die aufwendigste und kostenintensivste Vorgehensweise.
Die zweitgenannte Maßnahme, syntaktische Prüfungen bei der Erfassung durchzuführen, scheint naheliegend. Es existiert eine Vielzahl verschiedener Validierungskomponenten für die unterschiedlichsten Technologien, die recht einfach implementiert werden können. Dabei werden meist Funtionalitäten zur Verfügung gestellt, mit denen die (syntaktischen) Inhalte bestimmter Felder geprüft werden, also z.B. kann die Mindestlänge eines Textfeldes geprüft werden oder die Eingabe auf "normale" Buchstaben (z.B. für die Namenseingabe) eingegrenzt werden. Für Postleitzahlen beispielsweise würde man in Deutschland nur Ziffern zulassen. Ebenso werden meist Möglichkeiten geboten, per Regulären Ausdrücken den Aufbau einer Email-Adresse o.ä. wohl strukturierte Daten zu validieren. Im Falle des serverseitigen Javascripts seien hier exemplarisch folgenden Module genannt, die ausgewählt wurden, weil sie auch Bootstrap unterstützen. Es gibt noch viele andere Module - vielleicht auch noch bessere, aber aus eigenen Tests was Handling und Einbindungsmöglichkeiten angeht, gefällt uns der 1000hz bootstrap-validator besonders.
Neben diesen Validierungspaketen ist es oft sinnvoll, sogenannte "Input-Mask" Komponenten zu verwenden. Diese bieten die Möglichkeit, das Format eines Eingabefeldes mit einer Maske vorzubelegen, die die Eingabe schon von vorn herein auf bestimmte Möglichkeiten einschränkt. Bei der Postleitzahl lässt sich somit beispielsweise für deutsche Adressen definieren, dass das Eingabefeld genau fünf Ziffern enthalten muss und somit das Feld erst dann erfolgreich verlassen werden kann, wenn dies erfüllt ist. In den Niederlanden könnte man eine Maske definieren, mit der die dort verwendete Postleitzahlstruktur von vier Ziffern und zwei Buchstaben (z.B. "6422 RA") abgebildet wird. Eine schöne und sehr empfehlenswerte Komponente für ein Inputmasken-Modul ist hier zu finden:
Die syntaktische Datenprüfung bei der Erfassung bietet so also schon einmal eine gute Basis, grundsätzliche Eingabefehler zu vermeiden. Für viele Fehlerquellen bei der Erfassung von Kundenstammdaten reicht das aber oft noch nicht aus. Auch für viele der Problemfälle aus o.g. Beispielen hilft eine rein Feld-basierte Prüfung nicht. Die PLZ "50826" besteht zwar syntaktisch korrekt aus 5 Ziffern, jedoch existiert diese PLZ überhaupt nicht. Genauso ist die Anrede "Frau" für den Namen "Meier, Paul" zwar generell eine gültige Feldeingabe, passt aber nicht zum Geschlecht des Vornamens. Oder der Nachname "Greeken", der zwar prinzipiell die Anforderung erfüllt, nur Buchstaben zu enthalten, mindestens zwei und per Definition höchstens 40 Zeichen lang zu sein, aber kein existierender Nachname ist. An dieser Stelle ist dann der Einsatz einer intelligenteren Software erforderlich: **as-address-solutions-validator ** übernimmt diese Aufgaben!
Dieses Modul greift auf die Komponenten AS ConvertBox und AS PostBox zu, die als Service angesprochen werden. Weiterführende Informationen zu diesen Standard-Softwarekomponenten finden Sie auf unserer Homepage AS Address Solutions bzw. mit den direkten Links: AS ConvertBox und AS PostBox.