建構驗證邏輯

本文件說明建立地址檢查系統的程序 處理來自 Address Validation 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 的回應表示缺少重要內容 應提供哪些資訊由 Address Validation API 可能無法交付的品質。

工作流程

  1. 必要時調查地址元件。
  2. 提醒客戶解決問題。
  3. 要求驗證更新後的地址。
  4. (選用) 傳送要求至 API 的意見回饋端點。 請參閱「處理更新後的地址」。
  5. 繼續設定地址。

判定信號

符合下列任何條件:

確認地址

verdict 的回應表示已交付 但變更了原始輸入內容,也就是推斷 拼字校正或可確認的資料

工作流程

  1. 需要修正:
    1. 必要時調查地址元件。
    2. 要求驗證更新後的地址。
    3. (選用) 傳送要求至 API 的意見回饋端點。 請參閱「處理更新後的地址」。
    4. 繼續設定地址。
  2. 不需要修正:
    1. (選用) 傳送要求至 API 的意見回饋端點。 請參閱「處理更新後的地址」。
    2. 繼續設定地址。

判定信號

符合下列所有條件:

  • validationGranularity包含 ROUTE 或更高規格請參閱精細程度 輕鬆分配獎金
  • addressComplete敬上 為 true
  • hasInferredComponents 欄位為「true」 或 「hasReplacedComponents」欄位為「true」。
接受地址

Address Validation API 回應表示地址品質良好。

工作流程

繼續處理退貨地址。

判定信號

符合下列所有條件:

  • validationGranularity包含 PREMISE 或更高規格 請參閱精細程度值。
  • addressComplete敬上 為 true
  • 沒有推論或替換的元件。

實作指南

設計系統回應 Address Validation API 信號的方式時, 下列建議可以幫助您 模型不過,這些只是建議,提醒您 您可以根據自己的商業模式

指引 詳細資料
風險等級

考量層級 確保系統能根據自身需求 修正及接受輸入的地址

Address Validation API 會傳回多種信號 可與風險等級搭配使用,以便最佳化您的驗證 上傳資料集之後,您可以運用 AutoML 自動完成部分資料準備工作

舉例來說,如果地址的門牌號碼尚未確認,您可以 接受。不過,如果您的業務營運需要 網址時,系統可能會提示使用者。舉例來說 可能歸類為任一類別,請參閱「非美國當地未確認的門牌號碼」 請參閱「接受地址 - 範例」一節。

接受地址

建議您允許系統接受原始作品。 如果客戶沒有回應提示。

此時,客戶輸入的地址可能不是 例如進行新建築時

提供意見

重新發出地址驗證要求時,您可以 並傳送要求至 provideValidationFeedback 端點。

讓 Google 瞭解最終處理最終回覆的方式。 請參閱「處理更新後的地址」。

修正地址

在搜尋結果明確指出地址並非地址時修正地址 交付。接著,您的系統就能提示客戶提供必要的 資訊,接著重新核發工作流程, 讓我們看看 DNS 解析 進一步探索內部和外部位址

修正信號

Address Validation API 提供多種信號,可協助您瞭解 都應修正

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

下列兩種信號最能判斷有問題的地址:

  • 每當 validationGranularity 欄位為 OTHER 時,系統應該 調查地址元件信號,進一步瞭解發生錯誤的原因 以及如何修正問題
  • 每當後續處理的 address 物件傳回 missingComponentTypes 欄位,系統應檢查該元件。 如果缺少元件,則會導致地址不完整,無法送達。

2. 其他指標

Address Validation API 也提供其他信號 診斷特定問題:

可疑元件 如果元件的確認等級列舉為 UNCOMFIRMED_AND_SUSPICIOUS,該元件可能 不正確。
未解析的元件 unresolvedToken 輸入的內容屬於無效的地址部分。

3. 美國地址信號

某些欄位僅適用於美國地址,可提供實用的信號, 無法配送,因此應修正。對於需要 您應該會看到以下內容:

dpvConfirmation ND 或空白。

如要進一步瞭解「dpvConfirmation」,請參見 處理美國地址

修正地址示例

確認地址

當判定結果指出 Address Validation API 時,你需要確認地址。 以便產生 通過驗證的地址。在這些情況下,您有可遞送的地址,但偏好 才能放心顯示最終地址 用來追蹤協助客戶的客服專員姓名

為了向消費者提供正確的提示,邏輯會找出 判斷要執行哪個動作或標記 API ,例如 inferredreplacedspellCorrected。 請參閱參考資料中的 AddressComponent

確認信號

Address Validation API 提供多種信號,可協助您瞭解 等電子郵件地址

1. 驗證精細程度

可以將 validationGranularity 設為 ROUTE 以上,但 「PREMISE」或「SUBPREMISE」能夠更準確地顯示出交付結果。

2. 其他指標

判定與客戶確認輸入的地址時,也會有判定結果 提供以下資訊,以便判斷要調查的元件:

推測資料 如果 hasInferredComponents 欄位為 true, 您就會知道 API 已在從其他地址收集的資訊 元件。
已取代的資料 如果 hasReplacedComponents 欄位為 true, API 會將輸入的資料替換為系統認為是地址有效的資料。

3. 美國地址信號

某些僅適用於美國地址的欄位指出您的邏輯應 向客戶確認詳細資料。符合下列其中一項條件:

dpvConfirmation S

如要進一步瞭解「dpvConfirmation」,請參見 處理美國地址

地址回覆 包含 missingComponentType 欄位,且該欄位的值為 subpremise

確認地址範例

接受地址

如果判定結果非常有把握,您接受地址的可信度就會是 該地址可以配送到貨,還可以在不需與客戶進一步互動的情況下使用 後續流程。

接受信號

Address Validation API 提供多種信號,可協助您瞭解 等電子郵件地址

1. 驗證精細程度

validationGranularity 的值可設為 PREMISE 以上,但在某些情況下 案件,ROUTE 仍表示遞送地址。

2. 其他指標

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

  • 沒有替換的資料。在本例中:hasReplacedComponents: FALSE
  • 沒有推論元件。在本例中:hasInferredComponents: FALSE

3. 美國地址信號

某些欄位僅適用於美國地址,其中顯示了高品質地址 以及可以接收的類型在可接受的美國地址中,您應該會看到 包括:

dpvConfirmation Y

如要進一步瞭解「dpvConfirmation」,請參見 處理美國地址

接受地址範例