検証ロジックを作成する

このドキュメントでは、Address Validation API からのさまざまなレスポンスを処理する住所確認システムを構築するプロセスについて説明します。このガイドでは、API レスポンスを解釈して、顧客に詳細情報を求めるタイミングと方法を判断する方法について説明します。

一般に、API レスポンスによって、システムが住所を処理する方法が次のように決まります。

• handyman 修正 - 住所に重大な問題が含まれている可能性があります。
  お客様に追加情報の提供を求めることを検討してください。
• domain_add Add subpremises（副施設を追加） - 住所に副施設が含まれていない可能性があります。
  お客様に部屋番号の追加を促すことを検討してください。
• edit 確認 - 住所に軽微な問題が含まれている可能性があります。
  お客様に住所が正しいことを確認するよう促すことを検討してください。
• check 承認 - 住所に問題がない可能性があります。
  ご自身の責任で、それ以上プロンプトを表示せずにアドレスを使用することを検討してください。

鍵の目的

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

if (verdict.possibleNextAction == FIX)
    Prompt the user to fix the address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
    Prompt the user to add a unit number.
else if (verdict.possibleNextAction == CONFIRM)
    Confirm with the user that the address is correct.
else
    Continue with the address returned by the API.

具体的なロジックは状況によって異なります。詳しくは、検証ロジックをカスタマイズするをご覧ください。

ワークフローの例

次の表に、API レスポンスに基づいて顧客にプロンプトを表示するために実装できるワークフローの例をまとめます。

検証ロジックをカスタマイズする

verdict.possibleNextAction フィールドの結果を使用して、システムが API レスポンスをどのように処理するかを決定できますが、ビジネス固有のニーズを処理するなど、カスタム ロジックの構築も検討できます。

このセクションの目的は、API レスポンスを解釈して、顧客にプロンプトを表示するかどうか、またどのように表示するかを判断するための独自のカスタム ロジックを開発する方法を示すことです。このセクションでは、カスタマイズで考慮すべきリスクレベルと追加の API レスポンス シグナルについて説明します。

ただし、verdict.possibleNextAction のみで次のステップを判断する場合でも、以下で説明する追加のシグナルは、アドレスに関する潜在的な問題の詳細を把握するのに役立ちます。

リスク許容度

Address Validation API からのシグナルに対するシステムの応答を設計する際は、次の推奨事項を参考にすると、より効果的な応答モデルを構築できます。ただし、これらはあくまで推奨事項です。実装はビジネスモデルに合わせて行う必要があります。

リスク回避型の購入手続きフローの例

配信失敗のリスクを軽減したい場合は、顧客へのプロンプトの頻度を増やすようにロジックをカスタマイズできます。たとえば、主な目的セクションで説明されているロジックを使用する代わりに、次のロジックを使用できます。

if (verdict.possibleNextAction == FIX or verdict.validationGranularity
== OTHER or verdict.validationGranularity == ROUTE)
  Prompt customer to fix their address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
  Prompt customer to add a unit number.
else if (verdict.possibleNextAction == CONFIRM or verdict.validationGranularity
== PREMISE_PROXIMITY or verdict.hasSpellCorrectedComponents or
verdict.hasReplacedComponents or verdict.hasInferredComponents)
  Prompt customer to confirm their address.
else
  Proceed with the returned address.

低摩擦の購入手続きフローの例

購入手続きフローでのユーザーの負担を軽減したい場合は、顧客へのプロンプトの表示頻度を減らすようにロジックをカスタマイズできます。たとえば、主な目的セクションで説明されているロジックを使用する代わりに、次のロジックを使用できます。

if (verdict.possibleNextAction == FIX)
  Prompt customer to fix their address.
else if (verdict.hasReplacedComponents)
  Prompt customer to confirm their address.
else
  Proceed with the returned address.

FIX シグナル

結果から住所が配送できない可能性があることが明らかな場合は、住所を修正します。その後、システムからお客様に必要情報の提供を求めるメッセージが表示されます。お客様が情報を提供したら、ワークフローを再発行して配送先住所を取得します。

Address Validation API レスポンスの次のフィールドは、verdict.possibleNextAction に加えて、住所に重大な問題があるかどうか、またどのような問題があるかを判断するために使用できます。

住所の修正例

CONFIRM_ADD_SUBPREMISES シグナル（米国の住所のみ）

Address Validation API のレスポンスで、住所に建物名や部屋番号が不足している可能性があることが示された場合は、住所を確認して建物名や部屋番号を追加するようお客様に促します。このような場合、建物の住所は有効である可能性が高いですが、結果として得られる住所がお客様の意図したものであるという確信を高める必要があります。

住所に建物名や部屋番号が欠落している可能性が高いかどうかを判断するために、verdict.possibleNextAction に加えて、Address Validation API レスポンスの次のフィールドを使用できます。

建物名、部屋番号の住所の例を追加

CONFIRM シグナル

住所が確認されるのは、Address Validation API が検証済みの住所を生成するために住所の構成要素を推測または変更したことを判定が示している場合です。このような場合、配達可能な住所はありますが、結果として得られる住所がお客様の意図したものであるという確信を高めたいと考えています。

Address Validation API レスポンスの次のフィールドは、verdict.possibleNextAction に加えて、住所に軽微な問題があるかどうか、またどのような問題があるかを判断するために使用できます。

住所の確認の例

ACCEPT シグナル

Address Validation API の API レスポンスで、住所が配達可能であり、ダウンストリーム プロセスで顧客とのやり取りなしで使用できるという確信度が高い場合は、住所を受け入れることができます。

Address Validation API レスポンスの次のフィールドは、verdict.possibleNextAction に加えて、住所の品質が許容範囲内かどうかを判断するために使用できます。

住所の入力例