使用 Address Validation API 處理大量地址

目標

開發人員經常使用的資料集內含客戶電子郵件地址， 品質不佳您必須確認 從客戶 ID 驗證到交付等各種用途

「地址驗證」 API 是由 可用來驗證地址的 Google 地圖平台。但 一次處理一個位址在本文件中，我們將探討如何使用 來自 API 測試在不同情境下的高容量位址驗證 只能驗證一次性和週期性的地址驗證。

用途

現在，我們將說明大量位址驗證的用途 很實用

測試

您通常想執行數千個 讓我們看看 DNS 解析 進一步探索內部和外部位址您可能在「逗號分隔值」檔案中使用了位址 以驗證地址的品質

地址的一次性驗證

加入 Address Validation API 時，您想驗證 連結至使用者資料庫的現有位址資料庫

定期驗證地址

在許多情況下，您需要定期驗證地址：

  • 您可能已排定工作時間驗證地址，以便取得詳細資料 例如客戶註冊、訂單詳細資料 排程。
  • 您可能會收到包含不同部門地址的資料轉儲 例如銷售或行銷收到 地址，通常希望在使用前先驗證。
  • 您可能會在問卷調查期間，或多項促銷活動後收集地址 保持連線狀態您想要驗證 正確輸入錯誤

深入探討技術

就本文件的目的而言，我們假設：

  • 您正在使用客戶提供的地址呼叫 Address Validation API 資料庫 (即內含客戶詳細資料的資料庫)
  • 您可以針對資料庫中個別地址快取有效性旗標。
  • 系統會在下列情況中，擷取有效性標記： 個別客戶登入帳戶

用於實際工作環境的快取

使用 Address Validation API 時，您通常會希望對 回應。雖然我們的服務條款 服務限制 哪些資料可以快取、任何可從 Address Validation API 快取的資料 都必須針對使用者帳戶快取也就是說，在資料庫 必須根據使用者的電子郵件地址或地址中繼資料 和其他主要 ID 相同

如為高容量位址驗證，資料快取必須遵循 Address Validation API 服務專屬 條款 第 11.3 節所述。有了這些資訊，您可以 判斷使用者的地址是否無效 取得更正地址的使用者，並與 應用程式。

  • 來自 AddressComponent 的資料 物體
    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

如果您要快取任何實際地址的相關資訊， 只有在取得使用者同意時才能快取。這可確保使用者 使用者知道為何特定服務會儲存自己的地址，而且接受 分享其地址。

比方說，使用者同意聲明就是與電子商務位址直接互動 表單中的表單。我們相信您將快取 處理地址以利運送包裹。

取得使用者同意後，您就能快取 formattedAddress 和其他主要元件 特定資料。但在無頭的情況下，使用者就無法提供 取得使用者同意聲明。因此 在這個無頭的情況下，您便可以快取極有限的資訊。

瞭解回應內容

如果 Address Validation API 回應包含下列標記，則 可確保輸入地址的交貨品質良好：

  • 認定結果中的 addressComplete 標記 物件是 true
  • 認定結果中的 validationGranularity 物件為 PREMISE 或 SUB_PREMISE
  • 沒有任何 AddressComponent 會標示為：
    • Inferred(請注意: inferred=true， addressComplete=true)
    • spellCorrected
    • replaced
    • unexpected和
  • confirmationLevel： 確認層級的 AddressComponent 設為 CONFIRMED或UNCONFIRMED_BUT_PLAUSIBLE

如果 API 回應不包含上述標記，則輸入地址 而您也可能在資料庫中快取標記 這些資料。快取標記表示整個地址品質不佳， 例如「拼字校正」這類更精確的旗標 解決品質問題客戶與已標記地址的下一次互動時 若是品質不佳，您可以使用現有的 讓我們看看 DNS 解析 進一步探索內部和外部位址Address Validation API 會傳回正確的地址， 都能透過 UI 提示顯示客戶接受格式化地址後 您可以在回應中快取下列項目：

  • formattedAddress
  • postalAddress
  • addressComponent componentNames 或
  • UspsData standardizedAddress

實作無頭地址驗證

根據上述討論：

  • 通常必須從地址快取部分回應 Validation API，用於商業用途。
  • 不過，服務條款 位於 Google 地圖平台會限制可快取的資料。

下一節將討論如何遵循 並採用大量地址驗證。

步驟 1：

第一步我們會探討如何導入大量地址 現有資料管道的驗證指令碼此程序可讓您 將 Address Validation API 回應的特定欄位儲存在 服務符合規定。

圖 A：下圖說明如何增強資料管道 和高容量位址驗證邏輯。

alt_text

根據《服務條款》，您可以從以下位置快取下列資料： addressComponent:

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

因此，在實作的步驟中，我們會快取上述 與 UserID 比對欄位

如要進一步瞭解實際資料，請參閱 架構

步驟 2：

在步驟 1 中，我們收集的意見回饋指出輸入資料集中的部分地址可能會 品質不佳在下一個步驟中，我們會使用這些已標記的地址 並與使用者分享，並取得他們的同意，可以修正儲存的資料 讓我們看看 DNS 解析 進一步探索內部和外部位址

圖 B：此圖表顯示如何進行使用者的端對端整合 同意聲明流程可能如下所示：

alt_text

  1. 使用者登入時，請先檢查您是否快取了任何驗證旗標 系統中的指示
  2. 如果有旗標，您應該透過 UI 告訴使用者 更新地址。
  3. 您可以使用已更新或快取，再次呼叫 Address Validation API 地址，並將更正後的地址顯示給使用者確認。
  4. 如果地址品質良好，Address Validation API 會傳回 formattedAddress。
  5. 您可以視情況向使用者顯示該地址 若未接受修正，則自動接受接受。
  6. 使用者接受邀請後，您就可以在資料庫中快取 formattedAddress。

結論

大量位址驗證是您可能會遇到的常見用途 應用程式本文件旨在示範某些情境 採用符合 Google 地圖規範的此類解決方案的設計模式 平台服務條款。

我們進一步撰寫了高流量地址的參考資源 驗證為 GitHub 上的開放原始碼程式庫。快來一探究竟！ 快速執行高量地址驗證另請參閱以下項目： 在不同情境下使用程式庫的設計模式。

後續步驟

下載透過可靠的地址提升結帳、交付和營運成效 白皮書 並檢視運用地址改善結帳、交付和營運方式 驗證 網路研討會。

建議延伸閱讀：

貢獻者

本文由 Google 負責維護。下列提供者原本可以撰寫您的簽名。
主要作者：

Henrik Valve |解決方案工程師
Thomas Anglaret |解決方案 工程師
Sarthak Ganguly |解決方案 Engineer (工程師)