運用 A/B 測試提升應用程式品質

您可以藉由 A/B 測試,針對部分使用者測試應用程式的改善項目,然後根據收集到的資料選出最適合所有使用者的解決方案。

為何有效

應用程式的功能或內容有所調整時,只要進行 A/B 測試,就不必憑空猜測所做的調整是否對使用者有助益。而且,由於測試對象可以限定為部分使用者,所以您不必擔心發佈後會對所有使用者造成非預期或負面的影響。

執行方法

  • 選取合適的 A/B 測試平台 例如使用 Firebase 遠端設定隨機挑選一定比例的使用者、使用 Firebase 數據分析或 Google Analytics (分析) 指定目標對象,搭配 Google 代碼管理工具,並與應用程式進行整合。
  • 決定要測試的功能或內容版本,以及評估成功與否的標準。
  • 設定對控制組和測試組顯示的功能或內容,做法如下:
情境 變更測試實例 非測試者體驗 版本 A 版本 B 版本 C、D 等 (選用)
為現有功能採用新的實作方式 將標籤改成底部導覽區可提高使用者參與度 … 原實作方式
亦即:標籤
原實作方式
亦即:標籤
實作新功能
亦即:底部導覽區
其他實作方式
例如:導覽匣
推出的新功能會建立新指標 依熱門程度而非價格來列出應用程式內產品可產生更多收益 … 不含新功能
亦即:不支援應用程式內購
按做法 1 實作新功能
亦即:依熱門程度列出應用程式內產品
按做法 2 實作新功能
亦即:依價格列出應用程式內產品
其他實作方式
例如:依字母順序列出應用程式內產品
使用現有指標評估新功能 允許使用者標示項目可提高使用者參與度 … 不含新功能
亦即:未開放標示項目
不含新功能
亦即:未開放標示項目
實作新功能
亦即:開放使用心型符號標示項目
其他實作方式
例如:開放使用星型符號標示項目
  • 選取測試人數或測試時間 (可用功能依 A/B 測試平台而定),最低目標測試人數為 1000 位使用者。
  • 進行測試。
  • 查看測試結果,判斷結果是否具有統計顯著性,以及是否有任何測試版本成功提高了應用程式成效。
  • 對所有使用者發佈「成效最佳」的版本

最佳做法

  • 選取具有擴充性的測試平台。 隨著應用程式的人氣攀升與業績成長,您進行的 A/B 測試可能會更多、更頻繁。因此,請務必選擇能夠讓您同時對相同的使用者群體者進行多項測試的平台,理想的情況是讓同一批人接受測試 (使用者可同時參與多項測試)。
  • 視實際需要決定測試版本數量,以實用性為目標。 如果某個功能或內容選項有許多種實用的替代方案,您最好針對超過兩個以上的版本進行測試,考慮採用多變量方法來定義版本。範例如下:
按鈕文字 (變數 2)
購買 下單
按鈕顏色 (變數 1) 藍色 版本 A 版本 B
綠色 版本 C 版本 D
  • 測試時間的長度需能夠排除周期性變化。 使用者的行為可能有周期性變化,例如每小時、每天、每週改變,或出現類似的循環。設定測試時間長度時,請將這些變化納入考量。如果已知使用者行為會在較長的周期內出現變化,則必須確保測試期間短於這個周期,然後推斷結果。
  • 確認已知使用者區隔之間的差異不會影響測試結果。如果您認為使用者行為會因使用者區隔而異,請在單一區隔中進行測試,或確實使用能夠代表所有使用者的樣本。舉例來說,如果您知道每位使用者收益會因國家/地區而異,則可針對單一國家/地區的使用者進行測試,或是從所有國家/地區的使用者中抽樣測試。
  • 針對多個區隔進行測試。 如果您已建立有效的使用者區隔 (例如國家/地區、客戶開發管道或類似區隔),即可考慮在不同區隔中進行測試,看看測試結果是否會改變。您可以選擇只對部分區隔發佈變更,也可以按區隔發佈不同變更。
  • 考量潛在商業效益來設定測試時間。 設定測試時間或測試群組大小 (這會影響向測試人員顯示不同版本所需的時間) 時,需考慮時間較短的測試是否具有商業效益 (可以更快做出改進)。
  • 監控測試,以防任何未預期的負面結果,並做好隨時暫停測試的準備。儘管參與測試的可能只有一小部分使用者,但是如果測試體驗非常糟糕,仍會影響您的評分和評論;此外,其他使用者也可能經由社交媒體看到測試者分享的資訊,對您的產品產生不良印象。
  • 採用階段發佈做法 (如果平台支援)。 雖然您可能會從測試結果的統計數據中判斷做出某種變更是有利的,但是當您將這項變更對所有使用者發佈時,仍可能出現意外結果。採用分階段發佈的做法,即可分批向使用者發佈變更並全程監控,一旦無法達到預期效果便可暫停發佈。
  • 將參與測試的使用者從指標中排除。 如果您開放使用者選擇是否參與測試,進而體驗或使用測試中的新功能,請記得將這類使用者從指標中排除。