電子商務結帳功能的地址驗證

目標

擷取客戶訂單中的正確地址對電子商務來說至關重要，因為這有助於確保產品順利送達、增加準時送達，並減少貨運公司地址更正費用。

本文件說明在電子商務結帳中使用 Address Validation API 的最佳做法，包括何時默示接受良好地址、向客戶確認 Address Validation 回應，或將客戶傳回地址輸入表單進行手動修正。

Google 地圖平台已提供教學課程，說明如何使用 Place Autocomplete 服務改善結帳流程。本文件新增了 Address Validation API 的新功能，可用於識別地址輸入錯誤，藉此提升可交付性並強化結帳功能。

什麼是地址驗證？

地址驗證 (也稱為地址驗證) 是一項程序，可用於識別輸入的街道和郵寄地址是否存在，以及能否提供外送服務。

為什麼需要在結帳時驗證地址？

如果在結帳頁面中發現未發現的錯誤，可能會導致嚴重送達問題。 只要在結帳畫面中進行地址驗證，即可確保消費者輸入的貨品交付地址有效。進而減少失敗和錯誤交付，對企業而言，將付出高昂的成本。

Places Autocomplete 服務和 Address Validation API 可讓使用者在結帳時輕鬆快速地輸入資料。一些常見的情況會使 Address Validation API 成為結帳程序的重要部分：

錯別字

客戶經常會在輸入地址時輸入錯誤資訊，尤其是在行動裝置上才是如此。例如，輸入紐約做為 Brooklyn 位址的 locality。

電話訂單

電話訂購的使用者很容易誤解地址，或擷取部分地址資訊。因而導致訂單送達時間延長或完全失敗。

購買禮物

人們通常會選購產品做為禮物，送給自己地址無法完全掌握的親友。在這類情況下，Address Validation API 有助於進一步確保輸入的地址有效。

客戶需要額外的地址中繼資料

包裹貨運公司或快遞公司通常需要額外資訊才能完成運送，例如住宅與商業建築物類型，或 USPS DPV 值 (僅限美國)。

因不同貨運公司而異

相較於小型貨運公司，當地郵政服務通常較能掌握特定鄰近地區的相關資訊。因此，即使缺少公寓號碼或當地地標，某些電信業者 (例如郵局) 或許還是能遞送包裹，導致其他貨運公司可能無法收貨。

如果貨運公司無法掌握運送區域的當地資訊，掌握越多資訊，就越有利於順利交付。Address Validation API 建議的修正內容可讓貨運公司更放心地提供套件。

導入 Address Validation API

客戶輸入地址 (無論是來自 Place Autocomplete 或手動輸入) 後，輸入的地址資料即可傳送至 Address Validation API。

建議呼叫 Address Validation API 的時間，按一下地址表單上的 [Next/Continue] (下一步)/[Continue] (繼續) 按鈕，該按鈕最有可能連往「付款處理」頁面。

在結帳過程中使用 Address Validation API 的端對端流程如下：

圖片

現在來詳細說明每個步驟。

步驟 1：地址輸入流程 - 使用 Place Autocomplete 服務

應在地址輸入表單的第一行導入 Place Autocomplete 服務，讓客戶在輸入地址詳細資料時給予建議。

自動完成功能可簡化在應用程式中輸入地址的過程，為客戶提供流暢體驗並提升轉換率。它提供了一個可「預先輸入」地址預測的快速輸入欄位，可用於自動填入帳單或運送地址表單。

為線上購物車整合自動完成功能有以下好處：

  • 大幅減少下單所需的按鍵動作數和下單所需的總時間。
  • 減少地址輸入錯誤。
  • 降低購物車放棄率。
  • 簡化行動裝置或穿戴式裝置上的地址輸入體驗。

此處提供幾個此階段流程畫面的範例。

圖片

步驟 2：使用 Address Validation API 驗證地址

建議您在結帳時呼叫 Address Validation API，確認地址有效且完整。

不過，如果因故未在預設流程中叫用 Address Validation API，建議您至少在下列情況下叫用此 API：

  1. 客戶使用了瀏覽器自動填入功能，而非自動完成功能。
  2. 客戶忽略了自動完成輸入內容。
  3. 已使用自動完成功能，但傳回的地址已編輯。
  4. 您處理的是高價值交易，在交易成功時特別重要。
  5. 基於法律理由，您必須儲存消費者地址。

步驟 3：提供視覺化的確認畫面

輸入地址後，請使用簡單的靜態地圖，讓使用者以視覺方式確認送貨地點。這張地圖讓客戶進一步確保地址正確無誤，可減少運送/取貨失敗的情況。
地圖可以顯示在客戶輸入地址的網頁中，甚至在客戶完成交易後傳送到確認電子郵件中。這兩種用途皆可透過下列 API 完成：

Maps JavaScript API 提供互動式地圖，用於顯示使用者位置。 Maps Static API 可讓您在網頁或電子郵件中嵌入圖片。

深入探討：解決接受案例

透過 Address Validation API 的回應，有三種主要情況可以定義。用於檢查地址品質的回應元件會醒目顯示，本文件前面的流程圖針對上述情境提供整體建議的流程。

情境 1：有效的地址

如果 API 傳回訊號，指出輸入的地址品質良好，則結帳可進入下一個階段，且不會向客戶發送任何通知。
表示良好地址的信號如下：

  • addressComplete 標記屬於 true，
  • PREMISE 或 SUB_PREMISE, 的驗證精細程度，以及
  • 沒有任何地址元件 加上以下標示：
    • inferred
    • spellCorrected
    • replaced
    • unexpected

建議您從 Address Validation API 採用建議的地址資料，因為這可能包含小幅修正和附加內容，例如：

  • 大寫
  • 格式修正，例如：
    • 街道至聖母街
    • 正確的地址元件排序
  • 以美國為例。

以下示範如何在驗證程序中使用這類意見回饋：

提出要求 反應 
  "address": {
    "regionCode": "US",
    "locality": "Mountain View",
    "addressLines": ["1600 Amphitheatre Pkwy"]
  }
 
"verdict": {
      "inputGranularity": "PREMISE",
      "validationGranularity": "PREMISE",
      "geocodeGranularity": "PREMISE",
      "addressComplete": true,
      "hasInferredComponents": true
    } …
"addressComponents": [
        {
          "componentName": {
            "text": "1600",
            "languageCode": "en"
          },
          "componentType": "street_number",
          "confirmationLevel": "CONFIRMED"
        },
        {
          "componentName": {
            "text": "Amphitheatre Parkway",
            "languageCode": "en"
          },
          "componentType": "route",
          "confirmationLevel": "CONFIRMED"
        },
        {
          "componentName": {
            "text": "Mountain View",
            "languageCode": "en"
          },
          "componentType": "locality",
          "confirmationLevel": "CONFIRMED"
        }

情境 2：可提出問題的地址

Address Validation API 可能指出地址有明顯的變更，通常是在個別欄位中加入 inferred、spellCorrected 或 replaced，因此應向客戶確認傳回的地址。您可以利用彈出式視窗、選擇輸入的地址或 API 提供的建議來完成這項操作。
  • 當 Address Validation API 找到與地址相符的項目 (類似 Place Autocomplete 回應的「候選比對」) 時，系統會回應可能相符的單一地址，並標記任何修正元件 (Address Validation API 回應："spellCorrected": true)。例如：
"1600 amphiteatre parkway" 與 "1600 Amphitheatre Parkway, Mountain View, CA 94043-1351, USA" 相符
以下舉例說明如何在驗證程序中運用這類意見回饋：
提出要求 反應 
  "address": {
    "regionCode": "US",
    "addressLines": ["1600 amphiteatre parkway"]
  }
 
      "verdict": {
      "inputGranularity": "PREMISE",
      "validationGranularity": "PREMISE",
      "geocodeGranularity": "PREMISE",
      "addressComplete": true,
      "hasInferredComponents": true
    } …
      "address": {
      "formattedAddress": "1600 Amphitheatre Parkway, Mountain View, CA 94043-1351, USA",
      …
      "addressComponents": [
        {
          "componentName": {
            "text": "1600",
            "languageCode": "en"
          },
          "componentType": "street_number",
          "confirmationLevel": "CONFIRMED"
        },
        {
          "componentName": {
            "text": "Amphitheatre Parkway",
            "languageCode": "en"
          },
          "componentType": "route",
          "confirmationLevel": "CONFIRMED",
          "spellCorrected": true
        }
...
{ "componentName": {
            "text": "Mountain View",
            "languageCode": "en"
          },
          "componentType": "locality",
          "confirmationLevel": "CONFIRMED",
          "inferred": true
        }
注意：路線缺少「h」，缺少縣市名稱 (Mountain View)

情境 3：地址無效

如果 Address Validation API 的回應指出地址無效，客戶應重新導向至地址輸入表單，以查看輸入的資料。當 Address Validation API 找到地址的候選項目時，系統會驗證地址的個別元件，並標記缺少或無效的資料，因此您可以標記需要新增或修正的欄位。
以下舉例說明如何在驗證程序中運用這類意見回饋：
提出要求 反應 
  "address": {
    "regionCode": "US",
    "addressLines": ["123 fake street new york"]
  }

"verdict": {
      "inputGranularity": "PREMISE",
      "validationGranularity": "ROUTE",
      "geocodeGranularity": "ROUTE",
      "hasUnconfirmedComponents": true,
      "hasInferredComponents": true
    } …
"addressComponents": [...
       {"componentName": {
            "text": "123",
            "languageCode": "en"
          },
          "componentType": "street_number",
          "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
        },
        { "componentName": {
            "text": "fake street",
            "languageCode": "en"
          },
          "componentType": "route",
          "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
        },
        {"componentName": {
            "text": "New York",
            "languageCode": "en"
          },
          "componentType": "locality",
          "confirmationLevel": "CONFIRMED"
        } …

上述的邏輯可在結帳流程中實作，如以下流程圖所示：

圖片

進一步改善結帳功能的提示

請注意，輸入的地址無效時，不會導致客戶無法結帳。建構邏輯不得在 API 持續指出項目為無效地址時，以無限迴圈的方式傳送客戶。

我們建議客戶最多選擇兩次輸入地址，如果第二次嘗試輸入，即使項目未經驗證，也應接受。實際做法為允許客戶在顯示 API 建議的彈出式互動視窗時「強制處理」，或在地址輸入時，自動接受第二次嘗試 (即使地址未通過驗證)。如果地址輸入未完成驗證，在產品出貨前，可能會由客戶服務部門下游進行人工審查。

例如，為什麼這很重要。新建築物建構完成後，與郵政地址資料庫中填入該建築物地址後，之間可能會出現落差。客戶應該要能使用輸入的地址強制執行結帳頁面，因為該地址可能尚未通過驗證。

您可以選擇使用 Address Verification API 的 provideValidationFeedback 方法，向 Google 針對特定驗證嘗試提供意見回饋。請按這裡瞭解詳情。

如果地址符合《Address Validation API 服務專屬條款》，即可在 UI 或資料庫中顯示地址。如果這些位址在資料庫中快取，就必須確保下列事項：

  • 地址只能用來快取使用者。
  • 只有在取得使用者同意聲明後，才能快取格式化地址和大多數其他屬性。

您會發現部分 Autocomplete 和/或 Address Validation API 回應不完整或不完整。根據地理位置和具體的業務需求，我們建議您在決定是否接受 Address Validation API 無法確認的地址時，實施更寬鬆的商業邏輯。

舉例來說，如果您位在美國，可以選擇在 Address Validation API 回應中啟用 CASSTM1，提供詳細的每個地址資料。

許多客戶偏好透過次要程序重新驗證地址，例如：

  • 基於法規原因，要求客戶必須確保快取的確切地址。
  • 如果驗證位址的初始呼叫失敗，請在離線時重新驗證位址。

我們提供高磁碟區位址驗證開放原始碼軟體工具，在批次程序中導入位址重新驗證功能。

結論

Address Validation API 是強大的工具，可改善任何電子商務平台的結帳體驗。如要進一步瞭解 Address Validation API，請按這裡試用。

後續步驟

下載「透過可靠的地址改善結帳、配送及營運流程 」白皮書，並參閱「利用地址驗證改善結帳、配送和營運成效 」網路研討會。

建議的延伸閱讀：

貢獻者

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

  1. 美國郵政服務非專屬被授權人。下列商標屬於美國郵政服務® 所有，且經許可使用：CASSTM、USPS®、DPV®。↩