検証ロジックを作成する

このドキュメントでは、Address Validation API からのさまざまなレスポンスを処理する住所確認システムを構築するプロセスについて説明します。レスポンスを正しく使用するロジックを構築する方法、API からの他のシグナルを調査する方法、ユーザーに詳細情報を求めるタイミングと方法を紹介します。

通常、API レスポンスによって、システムでの住所の処理方法が決まります。

  • 修正 - 住所の品質が低いです。 追加情報を求めるメッセージが表示されます。
  • 確認 - 住所は高品質ですが、入力された住所から変更されています。確認を求めるメッセージが表示されることがあります。
  • 承認 - 住所が高品質です。指定されたアドレスを使用できます。

鍵の目的

このドキュメントは、API レスポンスを最適に分析し、指定されたアドレスで次に取るアクションを決定するようにシステムを変更する際に役立ちます。次の擬似コードは、考えられるフローを示しています。

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.

正確なロジックは状況によって異なります。詳しくは、実装ガイダンスをご覧ください。また、Extended Component Library にある、このロジックのオープンソース実装を使用することもできます。

ワークフローの概要

次の表に、システムに対する 2 つのアクションをまとめます。

  1. 使用するワークフロー: 修正、確認、承認の動作に基づきます。
  2. 1 つ目は、レスポンスから確認するシグナルです。ここで説明するシグナルは、verdict プロパティから取得されます。チェックすべきシグナルはこれだけではありませんが、アドレスの品質の初期の指標となります。各動作タイプはこのドキュメントの各セクションに対応しており、その他のシグナルについても調査する必要があります。
システムの動作
住所を修正する

verdict からのレスポンスには、提供する必要がある重要な情報が欠落していることを示しています。Address Validation API から返される住所は、配送可能な品質ではない可能性があります。

ワークフロー

  1. 必要に応じて、住所コンポーネントを調べます。
  2. 住所の問題を解決するようお客様にお願いします。
  3. 更新された住所の検証をリクエストします。
  4. (省略可)API のフィードバック エンドポイントにリクエストを送信します。更新された住所を処理するをご覧ください。
  5. 住所を入力。

判定シグナル

次のいずれかに該当します。

  • validationGranularityOTHER に設定します。粒度の値をご覧ください。
  • addressCompletefalse です。
住所を確認する

verdict からのレスポンスは配信可能な住所を示していますが、元の入力に変更が加えられています(スペル修正されたデータ、または確認可能なデータの推測)。

ワークフロー

  1. 必要な修正:
    1. 必要に応じて、住所コンポーネントを調べます。
    2. 更新された住所の検証をリクエストします。
    3. (省略可)API のフィードバック エンドポイントにリクエストを送信します。更新された住所を処理するをご覧ください。
    4. 住所を入力。
  2. 修正は不要です。
    1. (省略可)API のフィードバック エンドポイントにリクエストを送信します。更新された住所を処理するをご覧ください。
    2. 住所を入力。

判定シグナル

次のすべてにあてはまります。

  • validationGranularityROUTE 以上が含まれている。粒度の値をご覧ください。
  • addressCompletetrue です。
  • hasInferredComponents フィールドが true または hasReplacedComponents フィールドが true である。
住所を承認

Address Validation API レスポンスは、質の高い住所があることを示しています。

ワークフロー

返品された住所を使用して手続きを進めます。

判定シグナル

次のすべてにあてはまります。

  • validationGranularityPREMISE 以上が含まれている。 粒度の値をご覧ください。
  • addressCompletetrue です。
  • 推定または置換されるコンポーネントがない

導入に関するアドバイス

システムが Address Validation API からのシグナルに応答する方法を設計する際は、次の推奨事項を参考にして、より効果的なレスポンス モデルを構築できます。ただし、これらはあくまでも推奨事項に過ぎないため、ご自身のビジネスモデルに適した実装にする必要があります。

ガイダンス 詳細
リスクレベル

修正メッセージを表示する場合と、入力された住所をそのまま受け入れる場合のバランスをとる場合は、実際の状況に対する許容度を考慮してください。

Address Validation API は、リスクレベルに応じて組み込んで検証プロセスを最適化できるさまざまなシグナルを返します。

たとえば、住所に未確認の番地が含まれている場合でも、それを使用できます。一方、ビジネス オペレーションでより高い精度の住所が必要な場合は、ユーザーにプロンプトを表示できます。いずれかのカテゴリに該当する例については、住所を受け入れる - 例米国以外の未確認の番地をご覧ください。

住所を受け入れる

顧客がプロンプトに応答しない場合に、システムで元の入力を受け入れるようにすることをおすすめします。

この場合、新築の場合など、お客様がシステムにない住所を入力した可能性があります。

フィードバックを送信

アドレス検証リクエストを再発行するときに、リクエストを provideValidationFeedback エンドポイントに送信することもできます。

これにより、最終的な回答にどう対応したのかを Google に知らせることができます。 更新された住所を処理するをご覧ください。

住所を修正

結果で住所を配送できないことが明らかになった場合は、住所を修正します。これにより、必要な情報の提供を求めるメッセージがユーザーに表示されます。その後、ワークフローを再発行して配送先住所を入手します。

シグナルを修正する

Address Validation API は、住所を修正する必要があるかどうかを知らせるさまざまなシグナルを提供します。

1. 検証の粒度と欠落しているコンポーネント

問題のある住所は、次の 2 つのシグナルから判断できます。

  • validationGranularity フィールドが OTHER の場合、システムは住所コンポーネントのシグナルを調査して、エラーが発生した場所とその修正方法を確認する必要があります。
  • 後処理された address オブジェクトmissingComponentTypes フィールドを返すたびに、システムはそのコンポーネントを確認する必要があります。また、コンポーネントが不足していると、住所が不完全で配送不能になります。

2. その他のシグナル

Address Validation API には、特定の問題の診断に役立つその他のシグナルも用意されています。

不審なコンポーネント コンポーネントの確認レベルの列挙型が UNCOMFIRMED_AND_SUSPICIOUS の場合、コンポーネントが正しくない可能性があります。
未解決のコンポーネント unresolvedToken は、住所の有効な部分として認識されない入力の一部です。

3.米国の住所シグナル

米国の住所にのみ適用される特定のフィールドは、住所を配送できず、修正する必要があることを示す有用なシグナルとなります。修正が必要なアドレスの場合は、次のように表示されます。

dpvConfirmation ND、または空。

dpvConfirmation の詳細については、米国の住所を処理するをご覧ください。

住所の例を修正する

住所を確認する

Address Validation API が推定されたか、検証済みの住所を生成するために住所コンポーネントに変更を加えたことが判定結果から判明したら、住所を確認します。このような場合、配達可能な住所は存在しますが、最終的な住所がお客様が意図した住所であるという確信が持てる場合があります。

ユーザーに正しいプロンプトを提供するために、ロジックでサービスによってフラグが付けられたコンポーネントを識別し、API がコンポーネントに適用したアクションまたはフラグ(inferredreplacedspellCorrected など)を決定します。リファレンスの AddressComponent をご覧ください。

シグナルを確認する

Address Validation API は、住所を確認する必要があるかどうかを知らせるさまざまなシグナルを提供します。

1. 検証の粒度

validationGranularityROUTE 以上も許容されますが、PREMISE または SUBPREMISE のいずれかを使用すると、配信可能性のシグナルが強くなります。

2. その他のシグナル

お客様に住所入力を確認する場合、調査するコンポーネントを決定するため、判定で次の情報も示されます。

推定データ hasInferredComponents フィールドが true であれば、他の住所コンポーネントから収集した情報が API によって入力されていることがわかります。
置き換えたデータ hasReplacedComponents フィールドが true の場合、API は入力されたデータを住所が有効と見なしたデータに置き換えます。

3.米国の住所シグナル

米国の住所にのみ適用される特定のフィールドは、ロジックでお客様と詳細を確認する必要があることを示します。以下のいずれかに該当します。

dpvConfirmation S

dpvConfirmation の詳細については、米国の住所を処理するをご覧ください。

住所のレスポンス subpremise の値を持つ missingComponentType フィールドが含まれます。

住所の例を確認する

住所を入力

判定の結果、住所が配達可能であり、ダウンストリーム プロセスで顧客とのやり取りなしで使用できる場合、住所を受け入れます。

シグナルを受け入れる

Address Validation API は、住所を確認する必要があるかどうかを知らせるさまざまなシグナルを提供します。

1. 検証の粒度

validationGranularity には PREMISE 以上を指定できますが、場合によっては ROUTE が配達可能な住所を示すこともあります。

2. その他のシグナル

住所の品質が高いという判定では、次の情報も得られます。

  • 置き換えられるデータはありません。ここでは hasReplacedComponents: FALSE です。
  • 推定コンポーネントがない。ここでは hasInferredComponents: FALSE です。

3.米国の住所シグナル

米国の住所にのみ適用される特定のフィールドは、質の高い住所を配送できることを示します。使用できる米国の住所については、以下をご覧ください。

dpvConfirmation Y

dpvConfirmation の詳細については、米国の住所を処理するをご覧ください。

Accept 住所の例