Validierungslogik erstellen

In diesem Dokument wird ein Verfahren zum Erstellen eines Systems zur Adressprüfung beschrieben, das verschiedene Antworten der Address Validation API verarbeiten kann. Darin wird beschrieben, wie Sie Ihre Logik so erstellen, 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:

• handyman Beheben: Die Adresse ist von geringer Qualität. Sie sollten nach weiteren Informationen fragen.
• edit Bestätigen: Die Adresse ist von hoher Qualität, weicht aber von der eingegebenen Adresse ab. Möglicherweise werden Sie um eine Bestätigung gebeten.
• check 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 „Korrigieren“, „Bestätigen“ und „Akzeptieren“.
2. Die ersten Signale, die in der Antwort geprüft werden sollen. Die hier beschriebenen Signale stammen aus dem Attribut verdict und sind nicht die einzigen Signale, die geprüft werden. 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.

Implementierungsleitfaden

Bei der Entwicklung der Reaktion Ihres Systems auf Signale zur Adressvalidierung können Ihnen die folgenden Empfehlungen helfen, ein effektiveres Reaktionsmodell zu erstellen. Dies sind jedoch nur Empfehlungen. Ihre Implementierung sollte zu Ihrem Geschäftsmodell passen.

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. Validierungsgranularität 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:

3. US-Adresssignale

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:

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

Beispiele für die Korrektur von Adressen

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 zustellbare Adresse, möchten aber sichergehen, dass die resultierende Adresse die vom Kunden angegebene ist.

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

Signale bestätigen

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

1. Detaillierungsgrad der Validierung

Eine 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 Folgendes, um zu ermitteln, welche Komponenten untersucht werden müssen:

3. US-Adresssignale

Bei bestimmten Feldern, die nur für US-Adressen gelten, muss Ihre Logik die Details mit dem Kunden bestätigen. Eines der folgenden Kriterien muss erfüllt sein:

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. Detaillierungsgrad 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 Urteil für eine Adresse von hoher Qualität sollte auch Folgendes enthalten:

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

3. US-Adresssignale

Bestimmte Felder, die nur für US-Adressen gelten, weisen auf eine hochwertige Adresse hin, an die geliefert werden kann. Eine akzeptable US-Adresse muss die folgenden Angaben enthalten:

Adressbeispiele akzeptieren