本文件說明建立地址檢查系統的程序 處理來自 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.
實際邏輯會因您的情況而異,請參閱導入指南 ,掌握更多詳細資訊。您也可以使用這項邏輯的開放原始碼實作 是在擴充元件程式庫中找到
工作流程總覽
下表摘要列出系統可採取的兩項動作:
- 根據修正、確認及接受行為區分的工作流程。
- 要檢查回應中的第一個信號。信號
此處描述的內容來自
verdict
屬性,而且並非 信號,但提供地址的初始指標 品質每種行為類型都對應本文件中的一個章節 說明您可能還需要調查的進一步信號
系統行為 | |||
---|---|---|---|
修正地址 |
來自
|
||
確認地址 |
|
||
接受地址 |
Address Validation API 回應表示地址品質良好。
|
實作指南
設計系統回應 Address Validation API 信號的方式時, 下列建議可以幫助您 模型不過,這些只是建議,提醒您 您可以根據自己的商業模式
指引 | 詳細資料 | |
---|---|---|
風險等級 |
考量層級 確保系統能根據自身需求 修正及接受輸入的地址 |
Address Validation API 會傳回多種信號 可與風險等級搭配使用,以便最佳化您的驗證 上傳資料集之後,您可以運用 AutoML 自動完成部分資料準備工作 舉例來說,如果地址的門牌號碼尚未確認,您可以 接受。不過,如果您的業務營運需要 網址時,系統可能會提示使用者。舉例來說 可能歸類為任一類別,請參閱「非美國當地未確認的門牌號碼」 請參閱「接受地址 - 範例」一節。 |
接受地址 |
建議您允許系統接受原始作品。 如果客戶沒有回應提示。 |
此時,客戶輸入的地址可能不是 例如進行新建築時 |
提供意見 |
重新發出地址驗證要求時,您可以
並傳送要求至 |
讓 Google 瞭解最終處理最終回覆的方式。 請參閱「處理更新後的地址」。 |
修正地址
在搜尋結果明確指出地址並非地址時修正地址 交付。接著,您的系統就能提示客戶提供必要的 資訊,接著重新核發工作流程, 讓我們看看 DNS 解析 進一步探索內部和外部位址
修正信號
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. 驗證精細程度
可以將 validationGranularity
設為 ROUTE
以上,但
「PREMISE」或「SUBPREMISE」能夠更準確地顯示出交付結果。
2. 其他指標
判定與客戶確認輸入的地址時,也會有判定結果 提供以下資訊,以便判斷要調查的元件:
推測資料 | 如果 hasInferredComponents 欄位為 true ,
您就會知道 API 已在從其他地址收集的資訊
元件。
|
---|---|
已取代的資料 | 如果 hasReplacedComponents 欄位為 true ,
API 會將輸入的資料替換為系統認為是地址有效的資料。
|
3. 美國地址信號
某些僅適用於美國地址的欄位指出您的邏輯應 向客戶確認詳細資料。符合下列其中一項條件:
dpvConfirmation
|
S
如要進一步瞭解「 |
---|---|
地址回覆 | 包含 missingComponentType 欄位,且該欄位的值為
subpremise 。
|
接受地址
如果判定結果非常有把握,您接受地址的可信度就會是 該地址可以配送到貨,還可以在不需與客戶進一步互動的情況下使用 後續流程。
接受信號
Address Validation API 提供多種信號,可協助您瞭解 等電子郵件地址
1. 驗證精細程度
validationGranularity
的值可設為 PREMISE
以上,但在某些情況下
案件,ROUTE
仍表示遞送地址。
2. 其他指標
高品質地址的判定結果也應提供以下資訊:
- 沒有替換的資料。在本例中:
hasReplacedComponents: FALSE
。 - 沒有推論元件。在本例中:
hasInferredComponents: FALSE
。
3. 美國地址信號
某些欄位僅適用於美國地址,其中顯示了高品質地址 以及可以接收的類型在可接受的美國地址中,您應該會看到 包括:
dpvConfirmation
|
Y
如要進一步瞭解「 |
---|