検証ロジックを作成する

このドキュメントでは、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.

具体的なロジックは状況によって異なります。詳しくは、実装ガイダンスをご覧ください。拡張コンポーネント ライブラリにある、このロジックのオープンソース実装を使用することもできます。

ワークフローの概要

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

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

verdict からのレスポンスは、提供すべき重要な情報が不足していることを示します。Address Validation API から返された住所は、配送に適さない場合があります。

ワークフロー

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

判定シグナル

次のいずれかに当てはまります。

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

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

ワークフロー

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

判定シグナル

以下のすべてに該当する

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

Address Validation API のレスポンスは、優れた品質のアドレスを示しています。

ワークフロー

返品先住所の手続きに進みます。

判定シグナル

以下のすべてに該当する:

  • validationGranularity には PREMISE 以上が含まれている。 粒度の値をご覧ください。
  • 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. 検証の粒度

ROUTE 以上の validationGranularity は許容されますが、PREMISE または SUBPREMISE の方が配信可能であることを示す強いシグナルになります。

2. その他のシグナル

お客様と住所の入力を確認する際、判定結果では、調査すべき項目を判断するための以下の情報も提供されます。

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

3. 米国の住所シグナル

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

dpvConfirmation S

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

住所に関する回答 subpremise の値を持つ missingComponentType フィールドが含まれます。

住所の例を確認する

住所を入力

アドレスが配達可能であり、ダウンストリーム プロセスでお客様の追加の操作なしで使用できることが判定結果から高い信頼性で示されている場合は、アドレスを承認します。

シグナルを承認する

Address Validation API には、アドレスを確認する必要があるかどうかを判断するためのさまざまなシグナルが用意されています。

1. 検証の粒度

validationGranularityPREMISE 以上であれば問題ありませんが、場合によっては ROUTE でも配達可能な住所を示します。

2. その他のシグナル

高品質のアドレスの判定結果には、次の情報も含まれている必要があります。

  • 置き換えられたデータなし。この場合は hasReplacedComponents: FALSE です。
  • 推論されたコンポーネントなし。この場合は hasInferredComponents: FALSE です。

3. 米国の住所シグナル

米国の住所にのみ適用される一部のフィールドは、質の高い住所に配送できることを示しています。米国の住所が使用可能な場合は、次のように表示されます。

dpvConfirmation Y

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

許可される住所の例