このドキュメントでは、住所確認システムを構築して、 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プロパティに由来するものであり、 シグナルで、住所を示す最初のシグナルとして 向上します各動作タイプは、このドキュメントの各セクションに対応しています 詳しく解説しています。
| システムの動作 | |||
|---|---|---|---|
| 住所を修正する |
|
||
| 住所を確認する |
|
||
| 住所を受け入れる |
Address Validation API のレスポンスは、住所の品質が優れていることを示しています。
|
||
導入に関するアドバイス
Address Validation API からのシグナルにシステムが応答する方法を設計する際は、 効果的なインシデント・レスポンス計画を策定するには、 モデルです。ただし、これらはあくまでも推奨事項ですので、 ビジネスモデルに適したものを選んでください
| ガイダンス | 詳細 | |
|---|---|---|
| リスクレベル |
需要の水準を考慮し プロンプトのプロンプトとアラートのバランスを 入力された住所をそのまま受け入れます。 |
Address Validation API からさまざまなシグナルが返される リスクレベルに組み込んで検証を最適化できる プロセスです たとえば、住所の番地が未確認の場合、 受け入れることができます。逆に、事業運営に 住所の精度が高い場合は、ユーザーにプロンプトを表示することがあります。たとえば、 いずれかのカテゴリに該当する場合があります。米国以外の未確認の番地をご覧ください。 住所の承認 - 例をご覧ください。 |
| 住所を許可 |
システムで元の入力を受け付けられるようにしておくことをおすすめします。 お客様がメッセージに応答しない場合。 |
この場合、お客様の住所が 制御することもできます。 |
| フィードバックを送信する |
住所確認リクエストを再発行する場合は、次の方法があります。
|
これにより、最終的な回答にどう対応するかが 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
|
|---|---|
| Address response（住所応答） | 次の値を含む missingComponentType フィールドが含まれます。
subpremise。
|
住所を入力
住所を承諾するのは、判定の結果、その住所が 住所が配送可能で、それ以上お客様に操作しなくても使用できる 下流プロセスで発生します
シグナルを受け入れる
Address Validation API は、住所変更の有無、 確認する必要があります。
1. 検証の粒度
PREMISE 以上の validationGranularity は許容されますが、
ROUTE は配達可能な住所を示します。
2. その他のシグナル
高品質なアドレスの判定結果には、次の情報も含まれている必要があります。
- 置換されたデータがない。この場合は
hasReplacedComponents: FALSEです。 - 推定されるコンポーネントがない。この場合は
hasInferredComponents: FALSEです。
3. 米国の住所シグナル
米国の住所にのみ適用される一部の項目で、質の高い住所が示されている 配信できるようになります米国の住所が使用可能な場合は、 次のとおりです。
dpvConfirmation
|
Y
|
|---|