Validierungslogik erstellen

In diesem Dokument wird ein Prozess zum Erstellen eines Systems zur Adressprüfung beschrieben, mit dem verschiedene Antworten der Address Validation API verarbeitet werden können. Darin wird beschrieben, wie Sie Ihre Logik so aufbauen, dass die Antwort richtig verwendet wird, wie Sie andere Signale aus der API untersuchen und wann und wie Sie Ihre Kunden um weitere Informationen bitten.

Im Allgemeinen bestimmt die API-Antwort, wie Ihr System eine Adresse verarbeiten sollte:

  • Beheben: Die Adresse ist von geringer Qualität. Sie sollten nach weiteren Informationen fragen.
  • Bestätigen: Die Adresse ist von hoher Qualität, weicht aber von der eingegebenen Adresse ab. Möglicherweise werden Sie aufgefordert, die Aktion zu bestätigen.
  • Akzeptieren: Die Adresse ist von hoher Qualität. Sie können die angegebene Adresse übernehmen.

Schlüsselzweck

In diesem Dokument erfahren Sie, wie Sie Ihr System so anpassen, dass die API-Antwort optimal analysiert und die nächsten Schritte für die angegebenen Adressen ermittelt werden können. Der folgende Pseudocode veranschaulicht einen möglichen Ablauf.

if (the API response indicates significant problems in the address)
    FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
    CONFIRM - confirm with the user that the address is correct
else
    ACCEPT - continue with the address returned by the API.

Die genaue Logik hängt von Ihrer Situation ab. Weitere Informationen finden Sie im Implementierungsleitfaden. Sie können auch unsere Open-Source-Implementierung dieser Logik verwenden, die sich in der Extended Component Library befindet.

Workflowübersicht

In der folgenden Tabelle sind zwei Aktionen für Ihr System zusammengefasst:

  1. Der zu verwendende Workflow basierend auf dem Verhalten „Beheben, bestätigen, akzeptieren“.
  2. Die ersten Signale, die in der Antwort geprüft werden sollen. Die hier beschriebenen Signale stammen aus der Property verdict und sind nicht die einzigen Signale, die geprüft werden müssen. Sie geben jedoch einen ersten Hinweis auf die Qualität der Adresse. Jeder Verhaltenstyp entspricht einem Abschnitt in diesem Dokument, in dem weitere Signale beschrieben werden, die Sie möglicherweise ebenfalls untersuchen müssen.
Systemverhalten
Adresse korrigieren

Die Antwort von verdict weist auf wichtige fehlende Informationen hin, die angegeben werden sollten. Die von der API zurückgegebene Adresse ist möglicherweise nicht zustellbar.

Workflow

  1. Untersuchen Sie bei Bedarf die Adresskomponenten.
  2. Kunden auffordern, Adressprobleme zu beheben
  3. Fordern Sie die Bestätigung der aktualisierten Adresse an.
  4. Mit der Adresse fortfahren.

Einstufungssignale

Einer der folgenden Punkte trifft zu:
Adresse bestätigen

Die Antwort von verdict enthält eine Lieferadresse, aber es wurden Änderungen an der ursprünglichen Eingabe vorgenommen: Es wurden Daten abgeleitet, die entweder rechtschreibkorrigiert oder bestätigungsfähig sind.

Workflow

  1. Erforderliche Korrekturen:
    1. Untersuchen Sie bei Bedarf die Adresskomponenten.
    2. Fordern Sie die Bestätigung der aktualisierten Adresse an.
    3. Mit der Adresse fortfahren.
  2. Keine Korrekturen erforderlich:
  3. Mit der Adresse fortfahren.

Einstufungssignale

Alle der folgenden Bedingungen sind erfüllt:
Adresse akzeptieren

Die Antwort der Address Validation API gibt eine Adresse mit ausgezeichneter Qualität an.

Workflow

Mit der zurückgegebenen Adresse fortfahren.

Einstufungssignale

Alle der folgenden Bedingungen sind erfüllt:

Implementierungsleitfaden

Die folgenden Empfehlungen können Ihnen helfen, ein effektiveres Reaktionsmodell zu entwickeln, wenn Sie festlegen, wie Ihr System auf Signale zur Adressvalidierung reagiert. Dies sind jedoch nur Empfehlungen. Ihre Implementierung sollte zu Ihrem Geschäftsmodell passen.

Anleitung Details
Risikostufe

Berücksichtigen Sie die Toleranzgrenze für Ihre Situation, wenn Sie zwischen dem Auffordern von Korrekturen und dem Akzeptieren der eingegebenen Adresse abwägen.

Die Address Validation API gibt eine Vielzahl von Signalen zurück, die Sie in Ihr Risikoniveau einbeziehen können, um den Validierungsprozess zu optimieren.

Wenn eine Adresse beispielsweise eine nicht bestätigte Hausnummer hat, können Sie sie trotzdem akzeptieren. Wenn für Ihr Unternehmen hingegen eine höhere Adressgenauigkeit erforderlich ist, können Sie den Nutzer dazu auffordern. Ein Beispiel, das in beide Kategorien fallen könnte, finden Sie unter Nicht bestätigte Hausnummer außerhalb der USA in Adresse akzeptieren – Beispiele.
Adressen akzeptieren

Es empfiehlt sich, das System die ursprüngliche Eingabe akzeptieren zu lassen, wenn der Kunde nicht auf Aufforderungen reagiert.

In diesen Fällen hat der Kunde möglicherweise eine Adresse eingegeben, die nicht im System vorhanden ist, z. B. für einen Neubau.

Adresse korrigieren

Korrigieren Sie eine Adresse, wenn die Ergebnisse eindeutig darauf hinweisen, dass die Adresse nicht zustellbar ist. Ihr System kann den Kunden dann auffordern, die erforderlichen Informationen anzugeben. Anschließend können Sie Ihren Workflow noch einmal ausführen, um eine Lieferadresse zu erhalten.

Signale korrigieren

Die Address Validation API bietet eine Reihe von Signalen, die darauf hinweisen, ob eine Adresse korrigiert werden sollte.

1. Granularität der Validierung und fehlende Komponenten

Diese beiden Signale geben den besten Hinweis auf eine problematische Adresse:

  • Wenn das Feld validationGranularity den Wert OTHER hat, sollte Ihr System die Signale der Adresskomponenten untersuchen, um mehr darüber zu erfahren, wo der Fehler aufgetreten ist und wie er behoben werden kann.
  • Immer wenn das nachbearbeitete address-Objekt ein missingComponentTypes-Feld zurückgibt, sollte Ihr System diese Komponente prüfen. Fehlende Komponenten machen eine Adresse ebenfalls unvollständig und unzustellbar.

2. Sonstige Signale

Die Address Validation API bietet auch die folgenden Signale, um bestimmte Probleme zu diagnostizieren:

Verdächtige Komponenten Wenn das Enum für das Bestätigungsniveau für eine Komponente UNCOMFIRMED_AND_SUSPICIOUS ist, ist die Komponente wahrscheinlich falsch.
Nicht aufgelöste Komponente Ein unresolvedToken ist ein Teil der Eingabe, der nicht als gültiger Teil einer Adresse erkannt wird.

3. Signale für US-Adressen

Bestimmte Felder, die nur für US-Adressen gelten, liefern ein nützliches Signal dafür, dass die Adresse nicht zustellbar ist und korrigiert werden sollte. Bei einer Adresse, die korrigiert werden muss, wird Folgendes angezeigt:

dpvConfirmation Entweder N, D oder leer.

Weitere Informationen zu dpvConfirmation finden Sie unter Adressen in den USA verarbeiten.

Adressbeispiele korrigieren

Adresse bestätigen

Sie bestätigen eine Adresse, wenn das Ergebnis angibt, dass die Address Validation API entweder Änderungen an Adresskomponenten vorgenommen oder diese abgeleitet hat, um eine validierte Adresse zu erstellen. In diesen Fällen haben Sie eine lieferbare Adresse, möchten aber sichergehen, dass die resultierende Adresse die vom Kunden beabsichtigte ist.

Damit der Kunde die richtige Aufforderung erhält, muss in Ihrer Logik ermittelt werden, welche Komponenten vom Dienst gekennzeichnet wurden, um festzustellen, welche Aktion oder Kennzeichnung die API auf die Komponente angewendet hat, z. B. inferred, replaced oder spellCorrected. Weitere Informationen finden Sie in der AddressComponent.

Signale bestätigen

Die Address Validation API bietet eine Reihe von Signalen, die angeben, ob eine Adresse bestätigt werden sollte.

1. Granularität der Validierung

Ein validationGranularity von ROUTE oder besser ist akzeptabel, aber entweder PREMISE oder SUBPREMISE liefert ein stärkeres Signal für die Zustellbarkeit.

2. Sonstige Signale

Wenn Sie sich entscheiden, die Adresseingabe mit dem Kunden zu bestätigen, enthält das Ergebnis auch die folgenden Informationen, um zu bestimmen, welche Komponenten untersucht werden müssen:

Abgeleitete Daten Wenn das Feld hasInferredComponents den Wert true hat, wurde die API mit Informationen aus anderen Adresskomponenten gefüllt.
Ersetzte Daten Wenn das Feld hasReplacedComponents den Wert true hat, wurden die eingegebenen Daten von der API durch Daten ersetzt, die die Adresse gültig machen.

3. Signale für US-Adressen

Bestimmte Felder, die nur für US-Adressen gelten, weisen darauf hin, dass Ihre Logik die Angaben mit dem Kunden bestätigen sollte. Einer der folgenden Punkte trifft zu:

dpvConfirmation S

Weitere Informationen zu dpvConfirmation finden Sie unter Adressen in den USA verarbeiten.
Adressantwort Enthält das Feld missingComponentTypes mit dem Wert subpremise.

Adressbeispiele bestätigen

Adresse akzeptieren

Sie akzeptieren eine Adresse, wenn das Ergebnis mit hoher Wahrscheinlichkeit angibt, dass die Adresse zustellbar ist und im weiteren Prozess ohne weitere Kundeninteraktion verwendet werden kann.

Signale akzeptieren

Die Address Validation API bietet eine Reihe von Signalen, die angeben, ob eine Adresse bestätigt werden sollte.

1. Granularität der Validierung

Eine validationGranularity von PREMISE oder besser ist akzeptabel. In einigen Fällen weist ROUTE jedoch immer noch auf eine lieferbare Adresse hin.

2. Sonstige Signale

Ein Ergebnis für eine hochwertige Adresse sollte auch Folgendes enthalten:

  • Keine ersetzten Daten: In diesem Fall hasReplacedComponents: FALSE.
  • Keine abgeleiteten Komponenten: In diesem Fall hasInferredComponents: FALSE.

3. Signale für US-Adressen

Bestimmte Felder, die nur für US-Adressen gelten, weisen auf eine hochwertige Adresse hin, an die geliefert werden kann. Eine akzeptable US-Adresse sollte so aussehen:

dpvConfirmation Y

Weitere Informationen zu dpvConfirmation finden Sie unter Adressen in den USA verarbeiten.

Adressbeispiele akzeptieren