玩運彩練小喂

利用 Firebase Remote Config 在 APP 上實現 A/B Testing

玩運彩在 WEB 上的 A/B Testing 獲得了不少成功,我們決定將 A/B Testing 也實作到 APP 上。
Web 在實作 A/B Testing 是相對較容易的,只需要把 code push 到 production 就能讓所有人看到最新的狀態。專案一旦失敗,你隨時可以終止 A/B Testing;專案成功了,所有人馬上就能享受到最新版本!
但 App 做任何變更都需要送審才能上架,審核需要時間,尤其是 iOS 上架時間更是無法預期,更別提更新後,使用者不一定會更新最新版本。

那我們怎麼在 APP 上做 A/B Testing 呢?

方法一、透過 API

一開始我們打算透過 API 來實作 A/B Testing。
APP 向 API 取得使用者相應的版本後,再顯示相應的畫面給使用者看。


在這個方法中 API 扮演重要角色,需要處理一切邏輯:

  1. 需要記住使用者被分配到的版本
    不能讓使用者看到 A 版後,下次打開 APP 又看到 B 版,這樣會讓使用者很混亂。
    使用者每次打開 APP 都必須是前一次他看到的版本,除非 A/B Testing 已有結果。
  2. 比例要算對,數據才會準確
    比如說希望將使用者平均分成兩群(也就是各 50%),那最後分出來的結果必需剛好一半一半,不能差太多。
    為了達到上述條件,我們打算利用資料表來紀錄每一位使用者分到哪個族群。
  3. 要能夠隨時更動比例,或者是直接結束 A/B Testing
    A/B Testing 最終一定得有某個結果(不管成功或失敗),我們不想等到下次更新 APP 才公佈結果,那實在是太慢了。
    我們希望使用者在 A/B Testing 有結果後,立即就能享用到最新的變更。

但我們後來找到了比自己寫 API 更好的方法。

更好的方法:利用 Firebase Remote Config

利用 Firebase Remote Config 來做 A/B Testing 比自己寫 API 更方便許多(因為不用自己寫邏輯嘛)
但我們仍對他有些疑慮,所以做了些測試,發現有下列優點:

  1. 速度穩定
  2. 能夠記住使用者的組別(除非重新安裝 app 或是更新比例,才會變更分群)
  3. 分組比例精準(我們利用 Google Analysis 來證實過了)
  4. 設定簡單,只需要更改數字就能變更比例
  5. SDK 上手容易

但他也有缺點:

  1. 比例並不會立即更新(但可以設定最低 5 分鐘)

評估過後我們認為,Firebase Remote Config 雖然不會立即更新,但透過設定更新時間後,我們能夠接受短暫的 cache 時間,且 Remote Config 優點大於缺點。

Firebase Remote Config 簡介

Remote Config 是一個 Firebase 提供的 cloud service,讓 user 不用透過更新 app 就可以改變 app 的外觀或是體驗。
Firebase 有提供一則影片,清楚易懂,可以看看!

於 Firebase 上的設定

在 Firebase Remote Config 上方可以看到有兩個按鈕,分別是 Parameters 和 Conditions

Parameters

  • 也就是參數列表
  • 這裡列出了所有參數
  • 也可以在此設定參數所指定的條件
  • 限制最多 2000 組

Conditions

  • 條件列表
  • Remote Config 提供許多不同的條件供設定,像是所在地區、國家、語言等…,也可以把使用者亂數分群
  • 設定好的條件可供 parameters 重複使用
  • 限制最多 100 組

舉例來說:
你希望有個 parameter 叫做 “使用者是否在台灣”,並設定好其中一個 condition 叫做 “在台灣的使用者”。
那麼在 parameters 中就可以設定 parameter “使用者是否在台灣” 若達成 condition “在台灣的使用者” 就要回傳 “true”,其他則回傳 “false”。

我們使用 Remote Config 的小技巧:

Conditions

由於 A/B Testing 可能會有許多不同的比例組合,為了避免混亂,我們建立了一套命名規則:

  • 0_50 表示 0% ~ 50% 的使用者
  • 66_100 表示 66% ~ 100% 的使用者
0_50 表示為被分類在 0%~50% 的使用者

這些 “隨機百分比中的使用者” 是由 Firebase 替我們將 users 分群,所以我們不必寫任何分組的 code。

Parameters

編輯好 A/B Testing 的比例後,接著編輯 Parameters。
下圖為參數的範例:
my_abtesting 就是 Firebase 拿回來的資料中,要取的 key。
當 APP 向 Remote Config 取得 my_abtesting 這個參數時,若你被分類在前 50%,則會拿到 string A,否則拿到 B。
接收到 my_abtesting 的值後,就可以在 UI 上利用 if else 來判斷使用者會看到 A or B 版本的畫面了!

my_abtesting 就是 Firebase 拿回來的資料中,要取的 key。以此範例,可能回傳 A 或 B。

假如 A/B Testing 進行到一半,需要更改比例,那只需要到 Firebase Remote Config 內再做調整就好了。
別忘了做任何更動,都需要在右上方存檔。

SDK

在 APP 中的設定可以參考 SDK Document:

iOS SDK document
Android SDK document

因為筆者是 iOS 工程師,提供 swift code 供大家參考

 

數據分享

這是我們 A/B Testing 中的某項實驗,在這個實驗中我們分為三群,每個群組各 33.3%。
我們利用 Google Analysis 來作為驗證比例的工具。

可以看到 abtesting_1  abtesting_2 都是剛好 1/3,唯有 abtesting_3 稍微多了兩萬次。
這是因為 abtesting_3 是 default 值的關係。

至於 default 值會較多的原因,是因為 APP 第一次向 Remote Config 取得參數值的時候,使用者會有一小段時間需要要等待 Remote Config return back。在這小段時間差中(約幾百 ms 左右),會先被分類到 Default 中,等到 Remote Config return 數值後,使用者才會看到屬於他們版本的 UI。
這個時間差是很短的,使用者幾乎感受不到差異,且只要取得一次參數後,接下來都將會是同一個版本,所以我們選擇忽略不計。

如果我還是希望避免 Default 值比較多呢?

如果要避免這樣的情形,可以將 default 視為不在 A/B Testing 內的分群就好了!
也就是說,除了指定三個分群外,還需要再指定一個 default 的分群。這樣 abtesting_1、abtesting_2、abtesting_3 分到的比例就會一模模一樣樣了!

分群範例:

  • abtesting_1 – 0 ~ 33.3%
  • abtesting_2 – 33.3 ~ 66.6%
  • abtesting_3 – 66.6 ~ 100%
  • default – 其他

當使用者尚未取得 Remote Config 回傳的資料時,會先被分到 default,這時可以設定若使用者被分到 default,就看不到 UI,直到取得使用者的分群,再把屬於他分群的 UI 給顯示出來。


在我們找到 Firebase Remote Config 這個方案後,我們在 app 上的 A/B Testing 變得非常容易且好維護,後續也不只將 Remote Config 應用在 A/B Testing 上,Firebase 真是個前景可望的好服務 :)。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *