確認地址 - 範例

本文件說明在現實生活中,Address Validation API 針對須由系統確認行為的地址提供回應信號。如要瞭解相關資訊,請參閱「建構驗證邏輯」中的工作流程總覽

常見範例:確認

以下範例說明街道名稱相似的都會區。假設使用者打算輸入美國華盛頓州科克蘭的 Google 大樓 D 地址。然而,他們反而無意地進入 Seattle,而非 Kirkland

已輸入地址 區域
Building D, 451 7th Avenue South, Seattle, WA 98033, USA 美國

已取代資料的判斷結果

以下範例強調回應中的重要信號。

{
  "inputGranularity": "SUB_PREMISE",
  "validationGranularity": "PREMISE_PROXIMITY",
  "geocodeGranularity": "PREMISE_PROXIMITY",
  "addressComplete": true,
  "hasUnconfirmedComponents": true
  "hasReplacedComponents": true
}

PREMISE_PROXIMITY 表示建築物層級地址的「近似」,但不會像 SUB_PREMISE (即輸入時提供的精細程度) 一樣詳細。回應也包含未確認和取代的元件,因此組合提示會歸入「confirm」類別。

地址元件查詢可指出下列問題所在:

{
  "componentName": {
    "text": "451",
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
  "componentName": {
    "text": "98104",
  },
  "componentType": "postal_code",
  "confirmationLevel": "CONFIRMED",
  "replaced": true
}
...
{
  "componentName": {
    "text": "Building D",
    "language_code": "en"
  },
  "componentType": "subpremise",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......

    "unconfirmedComponentTypes": [
      "street_number",
      "subpremise"
    ]

在本例中,Address Validation API 會找到與「西雅圖」所提供地址的近似值,並取代為較高層級的元件,以解析為「Seattle」地址。這可能是有效的替代項目,但加上元件未確認的情況下,務必確認使用者打算輸入西雅圖的地址,而不是 Kirkland 等其他網址。

極端案例:確認

以下範例說明下列極端案例類型:

  • ARE 確認的輕微推論。Address Validation API 會推論國家/地區、郵遞區號或狀態,但所有其他資訊都會提供並確認。精細程度和確認層級的組合會使輕微推論不需要確認動作。
  • 未確認非預期的地址元件。未經確認的地址元件會增加地址的風險等級。這可能會進行確認。
  • 經確認的非預期地址元件。正確的地址並不需要使用此元件,且 Address Validation API 會將該元件從輸出內容中移除。一般來說,格式問題並不足以保證做出確認。

已確認 ARE 的輕微推論

與更精細層級的已確認資料結合時,如果輸入內容只有一個以下類型的元件,API 仍可做出正確的推論:

  • 城市
  • 狀態
  • 郵遞區號
  • 國家/地區

例如,客戶為位於麻薩諸塞州春田市麥當勞的餐廳提供有效的街道地址,但忘記輸入城市並提供不含 4 位數副檔名的郵遞區號。

已輸入地址 區域
1402 Allen St, MA 01118, USA 美國

遺漏城市的認定結果

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

如果 Address Validation API 推斷較高層級的元件以便產生配送地址,您可以提高系統來自系統資料的正確性。這是因為代表大地理區域的推測元件會更容易比對出更精細的地址元件。即使在城市名稱重複的國家/地區 (例如美國的春田市),其他元件與它結合,就能提供不重複的地址。

使用上述範例時,掃描所有地址元件的掃描作業顯示每個元件均經過確認,這表示該元件與 Address Validation API 儲存的資料相符,且該服務也會推斷兩個較高層級的元件。

{
  "componentName": {
    "text": "Springfield",
    "languageCode": "en"
  },
  "componentType": "locality",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
},
{
  "componentName": {
    "text": "1806"
  },
  "componentType": "postal_code_suffix",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
}

未確認非預期的地址元件

本情境說明檢查元件「未」確認的重要性。如果地址元件不符合預期,Address Validation API 會從輸出內容中移除。在這種情況下,根據您的風險等級和信賴水準,您可以接受或向客戶重新確認地址。

舉例來說,客戶輸入的地址可能來自郵局忽略的無害資訊,在這種情況下,您接受該地址。但在某些情況下,未確認的元件可能不是客戶的需求。

已輸入地址 區域
1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry 法國

未確認非預期地址元件的判定結果

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

除了含有未確認元件的判定結果外,Address Validation API 也會回傳下列格式化地址:

"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",

掃描未確認元件的掃描結果顯示 API 已從傳回的地址中移除 la caritat 2

{
  "componentName": {
    "text": "la caritat 2",
    "languageCode": "fr"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

已確認的非預期地址元件

這個範例說明如何在提供的地址中加入英國郡,這是常見的做法。不過,這並非英國郵政機構的要求,基本上會忽略。請參閱 postoffice.co.uk如何處理英國和國際郵件

因此,如果客戶在英國境內提供縣市,服務會將此視為非預期的輸入內容。

已輸入地址 區域
33 Dunalley St、Cheltenham、Gloucestershire、GL50 4AP 英國

經 IS 確認的非預期地址元件認定結果

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

在這裡,address_complete 評估為否,分析地址元件時會顯示非預期的標記。

{
  "componentName": {
    "text": "Gloucestershire",
    "languageCode": "en"
  },
  "componentType": "administrative_area_level_2",
  "confirmationLevel": "CONFIRMED",
  "unexpected": true
}

雖然 Gloucestershire 是所輸入地址的正確郡/縣,但地址本身格式不正確。提醒您,Address Validation API 也會評估資訊的格式是否正確。