このページは Cloud Translation API によって翻訳されました。

検証ロジックを作成する

このドキュメントでは、住所確認システムを構築して、 Address Validation API からの各種レスポンスを処理します。このコースでは、レスポンスを正しく使用し、他のシグナルを調査するためのロジックを構築する API から使用できる、また、いつどのように顧客に追加情報を求めるかについて説明しました。

一般に、API レスポンスは、システムが行う次の方法を決定します。アドレスを処理するには:

修正 - 住所の品質が低いです。詳細情報の入力を求められます。
確認 - 住所は高品質だが、変化します。たとえば、表示されます。
承認 - 高画質の住所です。Google Chat では提示された住所を受け取ることもできます。

鍵の目的

このドキュメントは、システムを修正し、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 つのアクションの概要を示します。

使用するワークフローは、修正、確認、承認の動作に基づいています。
レスポンスの確認する最初のシグナル。シグナルここで説明する verdict プロパティに由来するものであり、 シグナルで、住所を示す最初のシグナルとして向上します各動作タイプは、このドキュメントの各セクションに対応しています詳しく解説しています。

システムの動作

住所を修正する

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

ワークフロー

必要に応じて、住所コンポーネントを調査します。
住所の問題を解決するようお客様にご案内します。
更新された住所の検証をリクエストします。
（省略可）API の feedback エンドポイントにリクエストを送信します。住所の更新を処理するをご覧ください。
住所を入力

判定シグナル

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

validationGranularity を OTHER に設定しました。粒度を参照使用できます。
addressComplete false です。

住所を確認する

verdict からのレスポンスは、元の入力に変更が加えられた場合、元の入力にスペル修正済み、または確認可能なデータです。

ワークフロー

必要な修正: <ph type="x-smartling-placeholder">
1. 必要に応じて、住所コンポーネントを調査します。
2. 更新された住所の検証をリクエストします。
3. （省略可）API の feedback エンドポイントにリクエストを送信します。住所の更新を処理するをご覧ください。
4. 住所を入力
修正不要:

（省略可）API の feedback エンドポイントにリクエストを送信します。住所の更新を処理するをご覧ください。
住所を入力

判定シグナル

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

「validationGranularity」は「ROUTE」を含む以上です。粒度を参照使用できます。
addressComplete true です。
「hasInferredComponents」フィールドが「true」になっているまたは hasReplacedComponents フィールドは true です。

住所を受け入れる

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

ワークフロー

返品先住所の手続きを進めます。

判定シグナル

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

「validationGranularity」は「PREMISE」を含む以上です。粒度の値をご覧ください。
addressComplete true です。
推定または置換されたコンポーネントがない。

導入に関するアドバイス

Address Validation API からのシグナルにシステムが応答する方法を設計する際は、効果的なインシデント・レスポンス計画を策定するには、モデルです。ただし、これらはあくまでも推奨事項ですので、ビジネスモデルに適したものを選んでください

ガイダンス 詳細

リスクレベル

	ガイダンス	詳細
リスクレベル	需要の水準を考慮しプロンプトのプロンプトとアラートのバランスを入力された住所をそのまま受け入れます。	Address Validation API からさまざまなシグナルが返されるリスクレベルに組み込んで検証を最適化できるプロセスですたとえば、住所の番地が未確認の場合、受け入れることができます。逆に、事業運営に住所の精度が高い場合は、ユーザーにプロンプトを表示することがあります。たとえば、いずれかのカテゴリに該当する場合があります。米国以外の未確認の番地をご覧ください。住所の承認 - 例をご覧ください。
住所を許可	システムで元の入力を受け付けられるようにしておくことをおすすめします。お客様がメッセージに応答しない場合。	この場合、お客様の住所が制御することもできます。
フィードバックを送信する	住所確認リクエストを再発行する場合は、次の方法があります。 `provideValidationFeedback` エンドポイントにもリクエストを送信します。	これにより、最終的な回答にどう対応するかが Google に伝えられます。住所の更新を処理するをご覧ください。

需要の水準を考慮しプロンプトのプロンプトとアラートのバランスを入力された住所をそのまま受け入れます。

Address Validation API からさまざまなシグナルが返されるリスクレベルに組み込んで検証を最適化できるプロセスです

たとえば、住所の番地が未確認の場合、受け入れることができます。逆に、事業運営に住所の精度が高い場合は、ユーザーにプロンプトを表示することがあります。たとえば、いずれかのカテゴリに該当する場合があります。米国以外の未確認の番地をご覧ください。 住所の承認 - 例をご覧ください。

住所を許可

システムで元の入力を受け付けられるようにしておくことをおすすめします。お客様がメッセージに応答しない場合。

この場合、お客様の住所が制御することもできます。

フィードバックを送信する

住所確認リクエストを再発行する場合は、次の方法があります。 provideValidationFeedback エンドポイントにもリクエストを送信します。

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

住所を修正

住所が実際の住所ではないことが明らかな場合に、住所を修正してください提供しますその後、顧客は必要な情報を提供するよう求められます。完了後、ワークフローを再発行して成果物を受け取るあります。

シグナルを修正

Address Validation API は、住所変更の有無、固定される必要があります。

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

次の 2 つのシグナルから、問題のある住所を最もよく把握できます。

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

2. その他のシグナル

Address Validation API は、ドキュメント、ドキュメント、スプレッドシート、特定の問題の診断：

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

3. 米国の住所シグナル

米国の住所にのみ適用される一部のフィールドは、住所が配送できないため、修正する必要があります。住所の入力が必須となっている場合、次のように表示されます。

`dpvConfirmation`	`N`、`D`、空のいずれか。

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

住所の修正の例

住所の確認

判定の結果、Address Validation API が住所の構成要素に変更を加えるか推測したり検証済みのアドレスです。このようなケースでは、配達可能な住所を知っているが、結果として得られるアドレスが、意図したとおりであるという確信が持てる提供します。

お客様に正しいプロンプトを提供するため、ロジックでは、サービスによってフラグが付けられたコンポーネントを使用して、API にフラグを付けるアクションやフラグを設定 inferred、replaced、spellCorrected など、コンポーネントにのみ適用されます。リファレンスの AddressComponent をご覧ください。

シグナルを確認する

Address Validation API は、住所変更の有無、確認する必要があります。

1. 検証の粒度

ROUTE 以上の validationGranularity は許容されますが、次のいずれかである PREMISE または SUBPREMISE であれば、配信完了の強いシグナルになります。

2. その他のシグナル

住所の入力をお客様と確認する場合にも、この判定ででは、調査すべきコンポーネントを判断するための情報を提供します。

推定データ	`hasInferredComponents` フィールドが `true` の場合、 API は他のアドレスから収集した情報を説明します。
置換されたデータ	`hasReplacedComponents` フィールドが `true` の場合、 API が入力されたデータを、住所が有効とみなされるデータに置き換えました。

3. 米国の住所シグナル

米国の住所にのみ適用される一部のフィールドは、ロジックでお客様に詳細を確認します。次のいずれかに該当します。

`dpvConfirmation`	`S` `dpvConfirmation` について詳しくは、以下をご覧ください。米国の住所を処理する。
Address response（住所応答）	次の値を含む `missingComponentType` フィールドが含まれます。 `subpremise`。注: フィールドに `subpremise` 以外の場合、アクションは住所のカテゴリを修正します。住所の一覧はこちら（ジオコーディングのドキュメント）をご覧ください。

住所の例を確認する

住所を入力

住所を承諾するのは、判定の結果、その住所が住所が配送可能で、それ以上お客様に操作しなくても使用できる下流プロセスで発生します

シグナルを受け入れる

Address Validation API は、住所変更の有無、確認する必要があります。

1. 検証の粒度

PREMISE 以上の validationGranularity は許容されますが、 ROUTE は配達可能な住所を示します。

2. その他のシグナル

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

置換されたデータがない。この場合は hasReplacedComponents: FALSE です。
推定されるコンポーネントがない。この場合は hasInferredComponents: FALSE です。

3. 米国の住所シグナル

米国の住所にのみ適用される一部の項目で、質の高い住所が示されている配信できるようになります米国の住所が使用可能な場合は、次のとおりです。

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

住所の例を受け入れる

基本的な対応を理解する