使用 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 地圖地點自動完成功能仍會建議正確的地點。

驗證地址有許多好處,包括:

  • 提高送達率:地址驗證可確保郵件和包裹傳送至正確的地址,進而提升送達率。不但為商家省下寶貴的時間和金錢,還能提升客戶滿意度。
  • 改善資料品質:地址驗證可協助找出並更正地址中的錯誤,提升資料品質。進而提高行銷廣告活動和其他資料導向計畫的準確度。

決定假設

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

1. 轉換率

預先新增類型解決方案後,轉換率通常會略微上升,這是一項值得追蹤的指標。如果您是經由其他供應商變更類型的解決方案,預期轉換率應該會是固定的。如果轉換率下滑,請先檢查導入情形。

轉換率固然重要,但不一定能反映成效全貌。新增地址驗證解決方案的目的,是防止使用者在輸入時提交品質不佳的地址,在某些情況下可能會因此自然而然處理問題。這可能導致整體轉換率下滑,但不見得是壞事。由於新增地址驗證而未完成的訂單,可能是因為地址資料品質不佳,導致商家因配送交易退單而產生費用。

2. 減少品質不佳的地址

在這種情況下,理想的地址驗證解決方案就能派上用場。採用地址驗證後,我們應該就會減少地址資料品質不佳的情況。

如果您將新的解決方案與現有解決方案進行比較,您有可能只想比較「良好地址」的媒合率,並選取媒合率較高的服務。這可能會產生誤導,因為其中一項服務提供的誤報數量可能多於另一項服務。

相反地,使用地址資料比較成效時,指標會更具影響力。以電子商務為例,擷取地址的理想結果就是包裹成功送達。

建立模型

現在才是有趣的部分!現在是為客戶打造全新解決方案的時候了。我們準備了實用指南,說明如何針對電子商務結帳流程導入 Place AutocompleteAddress Validation API。建議你在完成這個步驟後再查看。

即使您不是專為電子商務建構,有許多資訊仍然相關,尤其是說明如何根據 Address Validation API 的輸出內容判定地址品質。

架構圖

以下是可在電子商務環境中建立 A/B 版本測試的容器範例:

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

關鍵系統中的重要應用程式、服務和資料儲存庫,為架構供電。(按一下可放大)。

架構圖顯示構成 A/B Test Software 系統和電子商務應用程式軟體系統的容器。客戶可看見與負載平衡器互動的電子商務網站,並將他們導向電子商務網站或應用程式。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 地圖平台解決方案工程師