選擇地址驗證解決方案

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

目標

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

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

這項測試的目標如下：

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

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

準備資料

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

使用擷取時的地址。例如，如果您打算在電子商務結帳中實施地址驗證，請使用客戶在表單中輸入的地址，而不是在進行任何可能被實施地址驗證 API 所取代的現有處理之前輸入的地址。

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

呼叫 API

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

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

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

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

查看結果

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

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

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

回應資料

這是什麼？

如何評估

這項功能有什麼幫助？

verdict.inputGranularity

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

SUB_PREMISE

前提

PREMISE_PROXIMITY

BLOCK

ROUTE

其他

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

verdict.validationGranularity

描述地址的整體輸出驗證。

SUB_PREMISE

前提

PREMISE_PROXIMITY

BLOCK

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"
]

查看已修正的地址

位址驗證 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"
]

USPS 資料 DPV 確認

"dpvConfirmation": "D"

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

地址驗證 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"
}

結論

開始測試 - 立即開始您的地址驗證 API 測試，以確保地址資料的準確性，提升客戶體驗，並簡化您的業務運作。在按照上述測試場景進行操作後，您將獲得所需的信息，以確定地址驗證 API 是否會為您的工作流程帶來價值。

建議閱讀：

貢獻者

Henrik Valve | DevX 工程師