使用 A/B 測試評估地址驗證的影響

本文說明執行 Google 地圖平台 Place AutocompleteAddress Validation API A/B 測試時可考量的技巧。

使用 Place Autocomplete 和 Address Validation API 有下列幾項優點:

  • 改善顧客體驗:商家可即時提供地址和地點建議,方便消費者輕鬆快速地完成結帳。進而提升客戶體驗。
  • 提高資料準確度:Place Autocomplete 和 Address Validation API,可提高顧客數位資料的準確度。這在電子商務中尤其重要,因為系統仰賴正確的地址資料來順利遞送包裹。

如要提升地址的品質,請執行 A/B 測試,評估哪種驗證解決方案最符合您的需求。方便您量化決定哪項產品最適合您的用途。

A/B 測試可用來比較兩個網頁或應用程式的不同版本。這是一種控制實驗,可用來判斷變更變數對可評估結果的影響。
如要執行 A/B 版本測試,請為網頁或應用程式建立兩個版本:一個做為控制組,另一個做為可衡量的變動。接著,您就能向不同使用者顯示這些版本,並評估這些版本的互動方式。成效較佳的版本就是勝出版本。

系統架構總覽

讓我們以電子商務應用實例的 A/B 測試地址驗證為例。以下架構圖顯示客戶如何與您的商務體驗互動,以便您決定更有效的驗證策略。

[系統內容] A/B 測試地址驗證

執行 A/B 測試 Address Validation API 值時會涉及的系統。

架構圖顯示客戶造訪您的電子商務網站,並與 A/B 測試系統互動。這個系統會透過電子商務商店軟體系統,決定要向客戶顯示哪個測試變數。電子商務商店向 Google 地圖平台軟體系統發出 API 呼叫。其也會收集 A/B 版本測試分析,並透過分析軟體系統處理,然後回報給 A/B 測試系統。

A/B 測試程序

當您考慮整體 A/B 測試流程時,需要考量四個階段。

  • 準備:找出測試要求、範圍和時間範圍。
  • 建構:在要執行測試的環境中導入 Place Autocomplete 和 Address Validation API。
  • 執行:在測試執行期間收集指標,直到取得顯著結果或時間結束為止。
  • 分析:將結果與假設進行比較,並找出後續步驟。

以下將逐一說明這些要素。

事前準備

決定 A/B 測試要求

初始探索

問問自己:您為什麼要新增或變更地址驗證服務供應商?例如使用 Google 地圖地點自動完成功能範例:

  • 省時:只要直接開始輸入,系統就會顯示建議,不必輸入地點的完整名稱。
  • 減少錯誤:如果您拼錯地點名稱,Google 地圖 Place Autocomplete 仍會建議正確的地點。

驗證問題的好處很多,包括:

  • 提高送達率:地址驗證功能可確保郵件和包裹送達正確的地址,有助於提升送達率。可以替商家節省時間和金錢,並提高客戶滿意度。
  • 提升資料品質:地址驗證有助於改善資料品質,方法是找出地址錯誤並加以修正。藉此提升行銷廣告活動和其他資料導向計畫的準確度。

決定假設

決定要測試的假設。以下提供兩個範例:

1. 轉換率

新增特定類型的解決方案後,轉換率通常會稍微增加,因此這是可追蹤的指標。如果您要提前從其他供應商變更類型解決方案,轉換率應該是固定的。如果轉換率下降,請先檢查導入作業。

轉換率很重要,但不能呈現整個故事資訊。新增地址驗證解決方案的目的是避免使用者在進入點提交品質不佳的地址,並且在某些情況下,可以自然地解決擷取的問題。這可能會導致整體轉換率下滑,但這不一定是壞事。因為多了地址驗證而導致的未完成訂單可能與品質不佳的地址資料相關聯,而會造成商家因出貨退款而需負擔損失。

2. 減少品質不佳的地址

這時,理想的地址驗證解決方案就能派上用場。導入「地址驗證」後,您會發現地址資料品質不佳的情況就會降低。

相較於現有的解決方案,新的解決方案的媒合率可能是比較「良好地址」的媒合率,並選擇媒合率較高的服務。這可誤導大眾,因為某項服務可能提供的誤報數量可能較多。

而是比較使用地址資料的成效。以電子商務為例,達成包裹的期望結果會是最終順利遞送包裹。

建構

現在更是精彩有趣的部分!現在正是為客戶打造全新解決方案的好時機。我們已經有一份實用指南,說明如何在電子商務結帳中導入 Place AutocompleteAddress Validation API。建議你在完成這個步驟時查看這個頁面。

即使您的不是專門針對電子商務打造廣告,但這些資訊還是非常相關,尤其是根據 Address Validation API 輸出結果判斷地址品質的指引。

架構圖

下列容器可用於在電子商務環境中建立 A/B 版本測試:

[執行環境] A/B 測試地址驗證

關鍵系統中的關鍵應用程式、服務和資料儲存庫,這些是支援架構的重要工具。(按一下可放大)。

架構圖顯示 A/B 測試軟體系統和電子商務應用程式軟體系統的構成容器。客戶造訪您的電子商務網站時,與負載平衡器互動,而負載平衡器會將他們導向至電子商務網站。A/B 測試管理員會與負載平衡器通訊,以便選取要向客戶顯示的 A/B 測試變數。這個 A/B 測試系統也會在您選擇的資料庫中記錄 A/B 版本測試的結果和設定。電子商務網頁應用程式會向 Google 地圖平台軟體系統發出 API 呼叫,並將數據分析事件回報至 Analytics (分析) 軟體系統,再向 A/B 測試結果資料庫記錄測試事件。

驗證實作

不完善的解決方案會產生不可靠的測試結果。執行 A/B 版本測試前,請務必先請一小群使用者驗證解決方案,確保解決方案可正常運作。對象可以是內部品質確保測試人員,以及/或是您信任的特定外部測試人員,提供建設性的意見。

執行

慢慢增加

即使解決方案通過驗證,您仍然最好還是慢慢地擴大測試的規模,一開始先對一小群使用者進行測試。透過這種做法,您可以及早發現錯誤或其他問題,並迅速解決,而不會對大部分的使用者造成影響。

完整測試

等到一小群使用者測試解決方案並解決所有問題後,即可進一步提升 A/B 版本測試的成效。這不一定是真實的 50/50 流量分配比例,但應與隨機選取的一組即時用量進行比較。

擷取指標

在測試期間,您必須確保擷取適當的資料來支持您的假設。過程中,您可以使用 A/B 測試平台來簡化資料收集作業,並之後再分析。Google 地圖平台也會收集可能使用的 API 用量指標。如要進一步瞭解如何使用報表工具,請參閱這個頁面

以下是一些建議指標:

Place Autocomplete

轉換率:先前沒有自動完成解決方案,表單的轉換率/完成率是否有所提升?
工具互動:與先前的解決方案相比,使用 Place Autocomplete 功能成功的使用者是否更多?

Address Validation

傳送成功:地址品質是否導致無法傳送失敗的情形?
地址變更:貨運公司向您收取的地址變更費用是否有減少?
住宅與商業資料:擷取住宅與商業資料方面是否有改善?(僅適用於特定市場)

分析

測試結束,接下來請根據原始測試條件和假設分析結果。如果您曾使用 A/B 測試平台完成這項程序,可能已能看到部分資訊。

回到上述的「品質不佳的地址降低」一節,您也可以使用 A/B 測試平台未擷取到的其他指標。這可能是在測試情境之間提交失敗的頻率,並提供下列示例資料:

解決方案 A 解決方案 B
傳送失敗 1.75% 1.23%

從上面的基本範例來看,這個應用實例清楚來說,解決方案 B 會是比較好的選擇。

結論

希望這份指南為您提供充分的資訊,以協助您開始執行 A/B 測試!雖然本文運用了電子商務領域的範例,但相同的基本原則也能應用在整體上。指出在商家中提供高品質地址資料後獲得的成果,並將這個假設視為主要假設。

以下再次附上指南中提及的連結,建議您多加閱讀。

預祝測試愉快!

後續步驟

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

建議的延伸閱讀:

貢獻者

主體作者:

Henrik Valve | Google 地圖平台解決方案工程師