建構驗證邏輯

本文件說明建構地址檢查系統的程序，以便處理 Address Validation API 的各種回應。這篇文章將說明如何解讀 API 回應，以便判斷何時及如何向客戶索取更多資訊。

一般來說，API 回應會決定系統應以下列方式處理地址：

• handyman 修正：地址可能含有重大問題。
  考慮要求客戶提供更多資訊。
• domain_add 新增子門牌：地址可能缺少子門牌。
  建議您提醒客戶新增單位號碼。
• 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 信號

如果結果明確指出地址可能無法送達，請修正該地址。系統接著可提示消費者提供必要資訊，之後您就能重新發出工作流程，取得可送達的地址。

除了 verdict.possibleNextAction 之外，您也可以使用下列 Address Validation API 回應欄位，判斷地址是否有重大問題，以及這些問題為何。

修正地址範例

CONFIRM_ADD_SUBPREMISES 信號 (僅限美國地址)

如果 Address Validation API 回應指出地址可能缺少子門牌，請提示客戶查看地址，並考慮新增單元號碼。在這種情況下，建築物的地址可能有效，但您想更確信產生的地址是客戶想要的地址。

除了 verdict.possibleNextAction 之外，您也可以使用 Address Validation API 回應的下列欄位，判斷地址是否可能缺少子門牌。

新增分支機構地址範例

「確認」信號

當判定結果指出 Address Validation API 已推斷或變更地址元件，以產生已驗證的地址時，您便可確認該地址。在這種情況下，您有可送達的地址，但希望更確信產生的地址是客戶想要的地址。

除了 verdict.possibleNextAction 之外，您也可以使用下列 Address Validation API 回應欄位，判斷地址是否有小問題，以及這些問題為何。

確認地址範例

ACCEPT 信號

如果 Address Validation API 回應提供的資訊可讓您高度確信地址可送達，且在下游程序中無須進一步與客戶互動即可使用，您就可以接受該地址。

除了 verdict.possibleNextAction 之外，您也可以使用下列 Address Validation API 回應欄位，判斷地址是否符合要求。

接受地址範例