目標
開發人員通常會使用包含客戶地址的資料集,因為這些資料集可能品質不佳。您需確保地址正確無誤,適用於客戶 ID 驗證、運送等各種用途。
Address Validation API 是 Google 地圖平台中的產品,可用來驗證地址。不過,系統一次只能處理一個位址。本文說明如何透過 API 測試,到一次性與週期性地址驗證,在不同情況下使用高容量地址驗證。
用途
現在,我們將瞭解高容量位址驗證的用途。
測試
您通常會想執行數千個位址來測試 Address Validation API。您可能在逗號分隔值檔案中使用位址,且想要驗證位址的品質。
地址的一次性驗證
加入 Address Validation API 時,建議您根據使用者資料庫驗證現有的地址資料庫。
定期驗證地址
在許多情況下,您需要定期驗證地址:
- 您可以排定工作驗證一天內擷取到的詳細資料,例如客戶的註冊、訂單詳細資料和貨品交付時間。
- 您可能會收到包含不同部門地址的資料轉儲,例如從銷售到行銷的團隊地址。接收位址的新部門通常希望先驗證這些資訊再使用。
- 您可能會在問卷調查期間收集地址,或各種促銷活動和後續線上系統的更新收集地址。您要在系統中輸入位址時,確認位址正確無誤。
深入探討技術
就本文件的目的而言,我們假設:
- 您使用客戶資料庫 (即包含客戶詳細資料的資料庫) 中的地址呼叫 Address Validation API
- 您可以針對資料庫中個別地址快取有效性旗標。
- 在個別客戶登入時,系統會從 Address Validation API 擷取有效性標記。
用於實際工作環境的快取
使用 Address Validation API 時,您通常會想快取 API 呼叫中的部分回應。雖然我們的《服務條款》會限制可以快取哪些資料,但任何可從 Address Validation API 快取的資料,都必須針對使用者帳戶進行快取。這表示資料庫、地址或地址中繼資料必須依據使用者的電子郵件地址或其他主要 ID 進行快取。
針對高容量位址驗證的用途,資料快取必須遵循第 11.3 節所述的 Address Validation API 服務專屬條款。您可以根據這項資訊,判斷使用者的地址是否無效。在這種情況下,系統會在使用者下次與應用程式互動時,提示他們提供更正後的地址。
- 來自 AddressComponent 物件的資料
confirmationLevel
inferred
spellCorrected
replaced
unexpected
如果您要快取任何實際地址的相關資訊,則必須取得使用者同意,才能快取該資料。如此可確保使用者清楚瞭解特定服務儲存其地址的原因,並且符合共用地址的條款規定。
使用者同意聲明的例子之一,是與結帳頁面上的電子商務地址表單直接互動。據我們所知,為了運送包裹,您會快取及處理地址。
在取得使用者同意後,您可以從回應中快取 formattedAddress
和其他主要元件。然而,在無頭的情況下,使用者便無法提供同意,因為地址驗證程序是於後端進行。因此,在這個無頭情境中,您可以快取非常有限的資訊。
瞭解回應內容
如果 Address Validation API 回應含有下列標記,表示輸入地址的可交付品質相當良好:
- Verdict 物件中的
addressComplete
標記為true
。 - 判定結果物件中的
validationGranularity
為PREMISE
或SUB_PREMISE
- 所有 AddressComponent 均未標示為:
Inferred
(請注意: inferred=true
若發生addressComplete=true
狀態,就可能發生上述情況)spellCorrected
replaced
unexpected
和
confirmationLevel
:AddressComponent 中的確認層級已設為CONFIRMED
或UNCONFIRMED_BUT_PLAUSIBLE
如果 API 回應不含上述標記,則輸入位址可能品質不佳,您可以在資料庫中快取標記來反映這一點。快取標記會指出整個地址的品質不佳,而「拼字修正」這類更詳細的旗標則會指出地址品質問題的特定類型。當下一次客戶與標記為不良的地址互動時,您可以使用現有地址呼叫 Address Validation API。Address Validation API 會傳回正確地址,您可以在 UI 提示中顯示正確地址。客戶接受格式化地址後,您就可以從回應中快取下列內容:
formattedAddress
postalAddress
addressComponent componentNames
或UspsData standardizedAddress
實作無頭地址驗證
根據上述討論:
- 基於業務考量,通常必須快取 Address Validation API 回應中的部分回應。
- 不過,Google 地圖平台的《服務條款》限制了可快取的資料。
我們將在下一節討論如何遵循《服務條款》和實作高流量地址驗證的兩個步驟程序。
步驟 1:
在第一個步驟中,我們將探討如何實作現有資料管道中的高容量位址驗證指令碼。此程序可讓您以符合《服務條款》的方式,儲存 Address Validation API 回應的特定欄位。
圖 A:下圖顯示如何使用高容量位址驗證邏輯強化資料管道。
根據《服務條款》,您可以從 addressComponent
快取下列資料:
confirmationLevel
inferred
spellCorrected
replaced
unexpected
因此,在實作的步驟中,我們會針對 UserID 快取上述欄位。
詳情請參閱實際資料結構。
步驟 2:
在步驟 1 中,我們收集的意見回饋指出輸入資料集中的部分地址可能品質不佳。在下一個步驟中,我們會擷取這些標記的地址,並向使用者顯示,並取得他們同意來修正儲存的地址。
圖 B:此圖表顯示使用者同意聲明流程的端對端整合方式:
- 使用者登入時,請先檢查您是否已在系統中快取任何驗證標記。
- 如有標記,建議您透過 UI 讓使用者修正並更新地址。
- 您可以使用已更新或快取的地址再次呼叫 Address Validation API,並將正確的地址提供給使用者進行確認。
- 如果地址品質良好,Address Validation API 會傳回
formattedAddress
。 - 如已做出修正,您可以向使用者顯示該地址,如果沒有修正,則提供靜音接受選項。
- 使用者接受邀請後,您就可以在資料庫中快取
formattedAddress
。
結論
大量位址驗證是您在許多應用程式中可能會遇到的常見用途。本文件嘗試示範一些情境,並採用符合《Google 地圖平台服務條款》規定的設計模式。
我們也在 GitHub 上進一步撰寫了高容量地址驗證的參考實作,以做為開放原始碼的程式庫。請查看說明, 開始快速使用高容量地址驗證建構應用程式另請參閱文章,瞭解在不同情況下如何使用程式庫。
後續步驟
下載透過可靠地址提升結帳、交付和營運成效 白皮書,並查看運用地址驗證改善結帳、交付和營運成效 網路研討會。
建議延伸閱讀:
- 運用大量位址驗證
- GitHub 上的 Python 程式庫
- 瀏覽地址驗證的示範
協作者
本文由 Google 負責維護。下列提供者原本可以撰寫您的簽名。
首席作者:
Henrik Valve | 解決方案工程師
Thomas Anglaret | 解決方案工程師
Sarthak Ganguly | 解決方案工程師