Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

地址驗證解決方案指南

測試步驟概略總覽流程圖。

目標

地址驗證適用於多種用途，除了測試結果的原始品質外，建議您也考量其他重要因素。例如：在使用者流程中全面檢視相容產品 (例如 Place Autocomplete 和Maps)、區域可用性，以及企業信任與可靠性。

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

這項測試的目標如下：

確認 Address Validation API 適合您的用途。
確認 Address Validation API 如何滿足您的解決方案需求，例如：
- 辨識優質地址。
- 在輸入的地址品質不佳時發出警示。
- 修正地址資料，包括推論、替換和拼寫更正。
- 提供格式正確的運送地址。
- 缺少或有誤的子建築物資料快訊 (僅限美國)。
確保導入 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 PREMISE_PROXIMITY 封鎖 ROUTE 其他	判斷輸入的地址是否有足夠資料，可能有效。
verdict.validationGranularity	說明地址的整體輸出驗證。	SUB_PREMISE PREMISE PREMISE_PROXIMITY 封鎖 ROUTE OTHER	可讓您判斷 API 輸出內容的整體地址品質。
verdict.hasInferredComponents	指出 API 是否已推論出元件。	是非題	API 能夠在可推論資料的情況下，新增缺少的元件。例如缺少州/省代碼。
verdict.hasReplacedComponents	指出 API 是否已取代元件。	是非題	在某些情況下，API 能夠以正確的資料取代不正確的元件。
verdict.addressComplete	表示地址是否完整。	是非題	如果 API 判定輸出地址包含所有必要元件，這個值就會是 true。
address.missingComponentTypes	如果地址缺少元件，系統會發出警告信號。	請參閱表 2 的值。	醒目顯示不完整地址中缺少的元件。

查看有效地址

排序 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 在任何 addressComponents 上設為 true。
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 標準化地址

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

您可以查看 UspsAddress 來檢視這項資料，並判斷是否能為工作流程增添價值。

範例：USPS 標準格式地址

"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 工程師

地址驗證解決方案指南 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

目標