選擇地址驗證解決方案

流程圖：概略說明測試步驟。

目標

地址驗證可為各種用途提供價值，除了測試結果的原始品質外，還有一些重要考量因素建議您一併瞭解。舉例來說，在使用者流程中 (例如 Place Autocomplete 和 Google 地圖)，可全面瞭解相容產品、區域供應情形，以及企業信任度與可靠性。

評估 Address Validation API 時，建議您遵循下列指南進行測試。

這項測試的目標如下：

  1. 確認 Address Validation API 是否適合您的用途。
  2. 確認 Address Validation API 是否符合解決方案需求，例如：
    • 找出優質地址。
    • 提醒您修正品質不佳的地址輸入內容。
    • 修正地址資料，包括推斷、替換和修正拼字。
    • 提供運送用的格式化地址。
    • 提醒使用者子處所資料缺漏或有誤 (僅限美國)。
  3. 確認導入 API 後可獲得可衡量的效益。

完成測試後，您就能回答上述問題，並判斷 API 是否適合貴商家。

準備資料

測試時應使用現有地址資料的樣本。 請勿手動挑選測試資料，而是選擇能代表您營運所在地理區域的隨機樣本。也就是說，如果您在美國和英國都有業務，但 70% 的業務在英國進行，30% 在美國進行，則樣本應反映這種比例。

使用擷取時的地址。舉例來說，如果您打算在電子商務結帳流程中導入地址驗證功能，請使用客戶在表單中輸入的地址，因為導入 Address Validation API 後，現有的處理程序可能會遭到取代。

準備約 5,000 到 10,000 筆記錄的樣本大小，以供測試。

呼叫 API

本節事前準備：瞭解如何 傳送地址驗證要求。

準備好資料後，您需要針對 API 執行每筆地址記錄。

如需如何呼叫 API 的指引，請參閱 Address Validation API 說明文件。我們也提供文章，說明使用 Address Validation API 大量處理地址的最佳做法。

這個步驟的結果應該是每個地址記錄的 API 資料輸出。接著就能分析結果，判斷 API 是否適合您的用途。您可以選擇使用試算表、資料庫或其他工具。

查看結果

本節的先決條件：瞭解如何 處理驗證回應，尤其是修正、確認和接受的概念。

本節將討論您可分析的輸出情境，以評估解決方案是否合適。

本文討論的重要 API 欄位總覽

回應資料

這是什麼？

如何評估

這項功能有什麼幫助？

verdict.inputGranularity

說明地址的輸入精細程度。

SUB_PREMISE

前提

PREMISE_PROXIMITY

封鎖

ROUTE

其他

判斷輸入地址是否有足夠資料，可望成為有效地址。

verdict.validationGranularity

說明地址的整體輸出驗證。

SUB_PREMISE

前提

PREMISE_PROXIMITY

封鎖

ROUTE

其他

可讓您判斷 API 輸出內容的整體地址品質。

verdict.hasInferredComponents

指出 API 是否已推斷出元件。

是非題

API 能夠在可推斷資料的情況下新增缺少的元件。例如，缺少州/省代碼。

verdict.hasReplacedComponents

指出 API 是否已取代元件。

是非題

在某些情況下，API 可以用正確的資料取代不正確的元件。

verdict.addressComplete

指出地址是否完整。

是非題

如果 API 判斷輸出地址包含所有必要元件，這個值就會是 true。

address.missingComponentTypes

信號：如果地址缺少元件，系統會發出警告。

如要瞭解值，請參閱表二。

醒目顯示不完整地址中缺少的元件。

查看有效地址

將 API 傳回的資料排序，判斷系統會接受哪些地址。API 的重要信號如下：

  • verdict.validationGranularity 包含 PREMISE 或更高版本。
  • verdict.addressComplete為 true。
  • 沒有推斷或取代的元件。

詳情請參閱接受地址。

這項練習的輸出結果應為地址資料的子集，且系統會將其視為有效。此時，您可以判斷：

  • 接受率是否在可接受範圍內？
  • 如果您使用現有的地址驗證工作流程，接受率是否相同或更高？

範例：有效地址

輸入的地址

區域

76 Buckingham Palace Road, London SW1W 9TQ

英國

認定結果

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "addressComplete": true
}

檢查無效地址

您可以藉由這個步驟手動檢查部分標示為無效的地址資料，並查看不使用 Address Validation API 時，無效地址是否會導致後續問題。

排序 API 傳回的資料，判斷系統會標示為無效的地址組合。API 的重要信號如下：

  • verdict.validationGranularity 設為 OTHER 或 ROUTE，視風險等級而定。
  • verdict.addressComplete為 false。

詳情請參閱修正地址。

這項練習的輸出內容應為地址資料的子集，且會標示為系統無效。此時，您可以判斷無效百分比是否可接受。

請注意，將地址標示為無效是 Address Validation API 的核心功能，因此地址標示為無效的比例偏高，不一定代表 API 效能不佳。API 會提供地址有誤的資訊，在造成下游問題前及早發現錯誤，提高工作流程效率。

示例：地址無效

輸入的地址

區域

21 45 40th street

USA

認定結果

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "OTHER",
  "geocodeGranularity": "OTHER",
  "hasUnconfirmedComponents": true
}

查看缺少的或未確認的元件

在這個階段，您也可以查看缺少的或未確認的元件。這是回傳內容中 Address 物件的一部分。這兩個欄位分別是 missingComponentTypes 和 unconfirmedComponentTypes。

使用這些欄位，有助於偵測 API 將地址標示為無效的原因，並收集正確的地址資訊，方法是將不正確的特定欄位回饋給資料收集點，讓地址有效。API 會提供資料品質的具體資訊，藉此提供價值。

範例：缺少元件且未確認

輸入的地址

區域

Fake St, New York, NY 10011

USA

認定結果

{
     "inputGranularity": "ROUTE",
     "validationGranularity": "OTHER",
     "geocodeGranularity": "OTHER",
     "hasUnconfirmedComponents": true
}

缺少及未確認的元件

"missingComponentTypes": [
    "street_number"
],
"unconfirmedComponentTypes": [
    "route"
]

查看已修正的地址

Address Validation API 可以修正輸入資料，將可能無效的地址輸入內容轉換為有效的地址資料。這是 API 增添價值的方式之一，請務必在測試中擷取這項資訊。

應留意的關鍵信號包括：

  • inferred、replaced 或 spellCorrected 設為 true。addressComponents
  • verdict.hasInferredComponents，或將 verdict.hasReplacedComponents 設為 true。

詳情請參閱確認地址。

這項練習的輸出內容應為地址資料的子集，且已透過 API 套用修正。

您可以手動檢查部分資料，判斷 API 是否會修正資料，進而減少下游工作流程的摩擦。

範例：已修正的地址

輸入的地址

區域

76 Bruckingm Palace Road, London SW1W 9TQ

英國

路徑 addressComponent

{
    "componentName": {
        "text": "Buckingham Palace Road",
        "languageCode": "en"
    },
    "componentType": "route",
    "confirmationLevel": "CONFIRMED",
    "spellCorrected": true
}

[僅限美國] 檢查缺少或錯誤子處所資料的地址

對於美國地址，Address Validation API 可以判斷子處所是否遺漏或有誤。

應留意的關鍵信號包括：

  • 在「Address」物件中：
    • unconfirmedComponentTypes包含 subpremise
    • missingComponentTypes包含 subpremise
  • 在 UspsData 物件中：
    • dpvConfirmation (缺少子場所)D
    • dpvConfirmation 是 S (子場所未確認)

詳情請參閱處理美國地址。

這項測試會顯示資料中是否有問題，例如缺少或不正確的子處所 (如公寓號碼)。這可能會導致下游問題，尤其是放送用途。Address Validation API 可在工作流程中提早識別這類問題，讓您採取步驟收集修正後的資料，進而提升工作效率。

示例：缺少子處所

輸入的地址

區域

111 8th Avenue, Manhattan, NY 10011

美國

缺少元件

"missingComponentTypes": [
    "subpremise"
]

美國郵政署資料 DPV 確認

"dpvConfirmation": "D"

[僅限美國] 檢查 USPS 標準化地址

Address Validation API 也會傳回美國地址的 USPS 標準化地址。如果運送標籤必須印上 USPS 格式的地址，這點就格外重要。

您可以查看 UspsAddress，瞭解這項資料是否能為工作流程帶來價值。

範例：美國郵政署標準格式地址

"standardizedAddress": {
    "firstAddressLine": "111 8TH AVE FL 11",
    "cityStateZipAddressLine": "NEW YORK NY 10011-5201",
    "city": "NEW YORK",
    "state": "NY",
    "zipCode": "10011",
    "zipCodeExtension": "5201"
}

結論

開始測試 - 立即開始測試 Address Validation API，確保地址資料準確無誤、提升客戶體驗，並簡化業務營運。完成上述測試情境後，您就能取得所需資訊，判斷 Address Validation API 是否能為工作流程帶來價值。

建議閱讀：

貢獻者

Henrik Valve | DevX 工程師