建構驗證邏輯

本文說明如何建構地址檢查系統，處理 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.

確切邏輯取決於您的情況，詳情請參閱導入指南。您也可以使用擴充元件程式庫中，這項邏輯的開放原始碼實作。

工作流程總覽

下表摘要說明系統的兩項動作：

  1. 根據修正、確認、接受行為使用的工作流程。
  2. 首先要檢查的回應信號。這裡所述的信號來自 verdict 屬性，並非唯一需要檢查的信號，但可做為地址品質的初步指標。每種行為類型都對應到本文中的一個章節，說明您可能需要調查的其他信號。
系統行為
修正地址

verdict 的回應指出缺少應提供的重要資訊。API 傳回的地址可能不符合可送達標準。

工作流程

  1. 必要時，請調查地址元件。
  2. 提示顧客修正地址問題。
  3. 要求驗證更新後的地址。
  4. 繼續使用地址。

判定結果信號

符合下列任一條件：
確認地址

verdict 的回應指出地址可送達，但已變更原始輸入內容：推論資料已修正拼寫，或資料可確認。

工作流程

  1. 需要修正：
    1. 視需要調查地址元件。
    2. 要求驗證更新後的地址。
    3. 繼續使用地址。
  2. 無需修正：
  3. 繼續使用地址。

判定結果信號

符合下列所有條件：
接受地址

Address Validation API 回應指出地址品質極佳。

工作流程

繼續使用傳回的地址。

判定結果信號

必須符合下列所有條件：

實作指南

設計系統如何回應地址驗證信號時，下列建議可協助您建構更有效的回應模型。不過，這些只是建議，請務必根據您的商業模式進行導入。

指引 詳細資料
風險等級

在提示更正和接受輸入的地址之間取得平衡時，請考量您情況的容忍度。

Address Validation API 會傳回各種信號，您可以結合風險等級，最佳化驗證程序。

舉例來說，如果地址的門牌號碼未經確認，您仍可接受。另一方面，如果業務營運需要更精確的地址，則可提示使用者。如需可能屬於任一類別的範例，請參閱「接受地址 - 範例」中的「非美國未確認門牌號碼」。
接受地址

如果客戶未回應提示，建議您讓系統接受原始輸入內容。

在這種情況下，顧客可能輸入了系統中沒有的地址，例如新建築物的地址。

修正地址

如果結果明確指出地址無法送達，請修正地址。接著，系統會提示顧客提供必要資訊，然後重新發出工作流程，取得可送達的地址。

修正信號

Address Validation API 提供多種信號，可讓您瞭解地址是否需要修正。

1. 驗證精細程度和缺少的元件

以下兩項信號最能指出地址有問題：

  • 只要 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，請參閱「處理美國地址」。
地址回應 包含 missingComponentTypes 欄位，值為 subpremise。

確認地址範例

接受地址

如果判定結果高度確信地址可送達，且可在後續流程中使用，不需進一步與客戶互動，您就會接受地址。

接受信號

Address Validation API 提供多種信號，可讓您瞭解是否應確認地址。

1. 驗證精細程度

validationGranularity 為 PREMISE 以上即可接受，但在某些情況下，ROUTE 仍表示地址可送達。

2. 其他指標

高品質地址的判定結果也應提供下列資訊：

  • 不取代資料。在本例中為 hasReplacedComponents: FALSE。
  • 沒有推論元件。在本例中為 hasInferredComponents: FALSE。

3. 美國地址信號

某些欄位僅適用於美國地址，表示該地址品質良好，可供寄送。如果美國地址可接受，您應該會看到以下內容：

dpvConfirmation Y

如要進一步瞭解 dpvConfirmation，請參閱「處理美國地址」。

接受地址範例