透過 A/B 測試建立應用程式內通訊實驗

與使用者聯絡或開始新的行銷活動時，您需要確保一切順利進行。您可以透過 A/B 版本測試，在指定的使用者族群中測試訊息變化版本，找出最理想的用詞和呈現方式。無論您的目標是提高留存率還是提升商品的轉換次數，A/B 版本測試都能執行統計分析，判斷訊息變化版本是否優於所選目標的基準。

如要使用基準值進行功能變化版本的 A/B 版本測試，請按照下列步驟操作：

  1. 建立實驗。
  2. 在測試裝置上驗證實驗。
  3. 管理實驗。

建立實驗

使用 Firebase In-App Messaging 的實驗可讓您評估單一應用程式內訊息的多種變化版本。

  1. 登入 Firebase 控制台，確認專案中已啟用 Google Analytics，以便實驗能夠存取 Analytics 資料。

    如果您在建立專案時未啟用 Google Analytics，可以前往「整合」分頁標籤啟用，方法是前往 Firebase 控制台，依序點選 > 「專案設定」。

  2. 在 Firebase 控制台導覽選單的「Engage」部分，按一下 A/B Testing。

  3. 系統提示您選擇要實驗的服務時，請依序點選「建立實驗」和「應用程式內訊息」。

  4. 或者，您也可以在 Firebase 控制台的導覽選單中展開「Engage」，然後按一下「In-App Messaging」。接著按一下「新增實驗」。

  5. 輸入實驗的「名稱」和選填的「說明」，然後點選「下一步」。

  6. 填寫「指定目標」欄位，首先選擇要使用實驗的應用程式。您也可以選擇指定部分使用者參與實驗，方法是選擇下列選項：

    • 版本：應用程式的一或多個版本
    • 使用者目標對象：Analytics 用於指定可能參與實驗的使用者目標對象
    • 使用者屬性：一或多個 Analytics 使用者屬性，用於選取可能納入實驗的使用者
    • 國家/地區：一或多個國家/地區，用於選取可能會納入實驗的使用者
    • 裝置語言：指定可能納入實驗對象的一或多個語言和語言代碼。
    • 首次開啟：根據使用者首次開啟應用程式的時間指定目標使用者
    • 應用程式最近一次的參與時間：根據使用者上次與應用程式互動的時間來指定使用者

  7. 設定目標使用者百分比：選取應用程式使用者人數中，符合「目標使用者」下方設定的條件百分比，並將這些使用者平均分配至實驗中的基準和一或多個變化版本。這個值可以是 0.01% 到 100% 之間的任何百分比。系統會隨機將百分比重新指派給每項實驗的使用者，包括重複的實驗。

  8. 在「變化版本」部分，使用您用於一般應用程式內訊息廣告活動的訊息設計介面，設定要傳送至基準群組的基準應用程式內訊息。

  9. 如要在實驗中加入變化版本，請按一下「新增變化版本」。根據預設，實驗會有一個控制組和一個變化版本。

  10. (選用) 為每個變化版本輸入更具描述性的名稱。

  11. (選用) 在「變化版本」部分的頂端，按一下「比較變化版本」按鈕，即可將另一個變化版本與基準訊息並排比較。

  12. 定義實驗的目標指標，以便在評估實驗變化版本時使用，並搭配您想從清單中使用的其他指標。這些指標包括內建目標 (參與度、購買、收益、留存率等)、Analytics 轉換事件和其他 Analytics 事件。

  13. 為實驗設定排程：

    • 設定實驗的「開始」和「結束日期」。
    • 設定如何在所有變化版本中觸發應用程式內訊息。

  14. 按一下「查看」儲存實驗。

每個專案最多可建立 300 個實驗，其中最多可包含 24 個執行中的實驗，其餘則為草稿或已完成的實驗。

在測試裝置上驗證實驗

您可以針對每個 Firebase 安裝作業，擷取與其相關聯的安裝驗證權杖。您可以使用這個權杖，在已安裝應用程式的測試裝置上測試特定實驗變化版本。如要在測試裝置上驗證實驗，請按照下列步驟操作：

  1. 取得安裝授權憑證，如下所示：

    Swift

    do {
  let result = try await Installations.installations()
    .authTokenForcingRefresh(true)
  print("Installation auth token: \(result.authToken)")
} catch {
  print("Error fetching token: \(error)")
}

    Objective-C

    [[FIRInstallations installations] authTokenForcingRefresh:true
                                               completion:^(FIRInstallationsAuthTokenResult *result, NSError *error) {
  if (error != nil) {
    NSLog(@"Error fetching Installation token %@", error);
    return;
  }
  NSLog(@"Installation auth token: %@", [result authToken]);
}];

    Java

    FirebaseInstallations.getInstance().getToken(/* forceRefresh */true)
        .addOnCompleteListener(new OnCompleteListener<InstallationTokenResult>() {
    @Override
    public void onComplete(@NonNull Task<InstallationTokenResult> task) {
        if (task.isSuccessful() && task.getResult() != null) {
            Log.d("Installations", "Installation auth token: " + task.getResult().getToken());
        } else {
            Log.e("Installations", "Unable to get Installation auth token");
        }
    }
});
    MainActivity.java

    Kotlin+KTX

    val forceRefresh = true
FirebaseInstallations.getInstance().getToken(forceRefresh)
    .addOnCompleteListener { task ->
        if (task.isSuccessful) {
            Log.d("Installations", "Installation auth token: " + task.result?.token)
        } else {
            Log.e("Installations", "Unable to get Installation auth token")
        }
    }
    MainActivity.kt
  2. 在 Firebase 控制台的導覽列上，按一下「A/B Testing」。
  3. 按一下「草稿」 (和/或遠端設定實驗的「執行中」)，將滑鼠遊標懸停在實驗上，按一下內容選單 ()，然後按一下「管理測試裝置」。
  4. 輸入測試裝置的安裝驗證權杖，然後選擇要傳送至該測試裝置的實驗變化版本。
  5. 執行應用程式，確認測試裝置已收到所選變化版本。

如要進一步瞭解 Firebase 安裝作業，請參閱「管理 Firebase 安裝作業」。

管理實驗

無論您是使用 Remote Config、通知編輯器或 Firebase In-App Messaging 建立實驗，都可以驗證並開始實驗、在實驗執行期間進行監控，以及增加實驗中納入的使用者人數。

實驗完成後，您可以記下勝出變化版本使用的設定，然後向所有使用者推出這些設定。或者，您也可以執行其他實驗。

開始實驗

  1. 在 Firebase 控制台導覽選單的「Engage」部分，按一下 A/B Testing。
  2. 按一下「草稿」，然後點選實驗的標題。
  3. 如要驗證應用程式是否有可納入實驗的使用者，請展開草稿詳細資料，並檢查「指定目標和發布」部分是否有大於 0% 的數字 (例如 符合條件的使用者有 1%)。
  4. 如要變更實驗，請按一下「編輯」。
  5. 如要開始實驗，請按一下「開始實驗」。每個專案一次最多可執行 24 項實驗。

監控實驗

實驗執行一段時間後，您可以查看實驗進度，並瞭解參與實驗的使用者目前的結果。

  1. 在 Firebase 控制台導覽選單的「Engage」部分，按一下 A/B Testing。

  2. 按一下「執行中」，然後點選或搜尋實驗標題。您可以在這個頁面上查看各種觀察和模擬統計資料，瞭解目前執行中的實驗，包括：

    • 與基準的落差百分比：評估指定變化版本的指標改善幅度，相較於基準值。計算方式是將變化版本的值範圍與基準值範圍進行比較。
    • 超越基準的機率：指定變化版本超越所選指標基準的預估機率。
    • observed_metric 每位使用者：根據實驗結果，這是指標值隨著時間推移而落在的預測範圍。
    • 總計 observed_metric：觀察到的基準或變體累積值。此值可用來評估每個實驗變化版本的成效，並用於計算「改善幅度」、「值範圍」、「超越基準的機率」和「成為最佳變化版本的機率」。視所評估的指標而定，這個資料欄可能會標示為「每位使用者的時間長度」、「每位使用者的收益」、「留存率」或「轉換率」。

  3. 實驗執行一段時間後 (FCM 和 In-App Messaging 至少 7 天，Remote Config 至少 14 天)，這個頁面會顯示哪個變化版本是「領先者」。部分評估項目會搭配長條圖，以視覺格式呈現資料。

向所有使用者推出實驗

實驗執行一段時間後，如果目標指標有「領先者」(即勝出版本)，即可向所有使用者發布實驗。方便您選取要向日後所有使用者發布的變化版本。即使實驗結果沒有明顯的勝出組合，您仍可向所有使用者發布變化版本。

  1. 在 Firebase 控制台導覽選單的「Engage」部分，按一下 A/B Testing。
  2. 按一下「已完成」或「正在執行」，然後點選要發布給所有使用者的實驗，接著按一下內容選單 () 中的「導入變化版本」。

  3. 採取下列任一做法，向所有使用者推出實驗：

    • 如果實驗使用通知編輯器，請使用「推出訊息」對話方塊，將訊息傳送給未參與實驗的其餘目標使用者。
    • 針對 Remote Config 實驗，請選取變化版本，決定要更新哪些 Remote Config 參數值。建立實驗時定義的指定條件，在範本中會顯示為新條件，確保該版推出後只會影響實驗所指定的使用者。點選「在遠端設定中查看」並檢查變更後，請按一下「發布變更」完成導入。
    • 如果是 In-App Messaging 實驗，請使用對話方塊判斷是否需要以獨立 In-App Messaging 廣告活動的形式推出哪個變化版本。選取後，系統會將您重新導向至 FIAM Compose 畫面，以便在發布前進行任何變更 (如有需要)。

展開實驗

如果您發現實驗並未吸引足夠的使用者，讓「A/B Testing」宣告勝出版本，可以增加實驗的分配比例，觸及更多應用程式使用者族群。

  1. 在 Firebase 控制台導覽選單的「Engage」部分，按一下 A/B Testing。
  2. 選取要編輯的進行中實驗。
  3. 在「實驗總覽」中，按一下內容選單 ()，然後點選「編輯執行中的實驗」。
  4. 「指定目標」對話方塊會顯示選項，讓您提高執行中實驗的使用者百分比。選取大於目前百分比的數字，然後按一下「Publish」。該實驗將推送至您指定的使用者百分比。

複製或停止實驗

  1. 在 Firebase 控制台導覽選單的「Engage」部分，按一下 A/B Testing。
  2. 按一下「Completed」(已完成) 或「Running」(執行中)，將滑鼠遊標懸停在實驗上，按一下內容選單 ()，然後點選「Duplicate experiment」(複製實驗) 或「Stop experiment」(停止實驗)。

指定使用者

您可以使用下列使用者指定條件，指定要納入實驗的使用者。

指定條件 運算子 值 注意事項
版本 包含、
不包含、
完全相符、
包含規則運算式		 為想要納入實驗的一或多個應用程式版本輸入值。

使用「包含」、「不包含」或「完全比對」運算子時，您可以提供以逗號分隔的值清單。

使用「包含規則運算式」運算子時，您可以透過 RE2 格式建立規則運算式。規則運算式可與所有或部分目標版本字串相符。您也可以使用 ^ 和 $ 錨點，比對目標字串的開頭、結尾或整個字串。
使用者目標對象 包含所有、
包含至少一個、
不包含所有、
不包含至少一個		 選取一或多個 Analytics 目標對象，指定可能會納入實驗的使用者。 部分指定 Google Analytics 目標對象的實驗，可能需要幾天的時間累積資料，因為這些實驗會受到 Analytics 資料處理延遲的影響。這種延遲最有可能發生在新使用者的情況下，他們通常會在建立後 24 到 48 小時，才會加入符合資格的目標對象，或是最近建立的目標對象。
使用者屬性 如為文字：
包含、
不包含、
完全符合、
包含規則運算式

數字：
<、≤、=、≥、> 		Analytics 使用者資源用於選取可能納入實驗的使用者，並提供多種選項可用來選取使用者資源值。

在用戶端中，您只能為使用者屬性設定字串值。如果條件使用數值運算子，Remote Config 服務會將對應使用者屬性的值轉換為整數/浮點數。		 使用「contains regex」運算子時，您可以使用 RE2 格式建立規則運算式。規則運算式可與所有或部分目標版本字串相符。您也可以使用 ^ 和 $ 錨點，比對目標字串的開頭、結尾或整個字串。
國家/地區 不適用 用於選擇可能納入實驗的一或多個國家/地區。  
語言 不適用 挑選可能應納入實驗的使用者的一或多個語言和語言代碼。  
初次開啟 大於
小於
介於		 根據使用者第一次開啟應用程式的時間指定目標使用者，以天為單位指定。
與應用程式的最近一次互動 大於
小於
介於		 根據使用者上次與應用程式互動的時間指定目標使用者，以天為單位指定。

A/B Testing 項指標

建立實驗時，您會選擇用來決定勝出組合的主要或目標指標。您也應該追蹤其他指標，以進一步瞭解每個實驗變化版本的成效，並追蹤各變化版本可能有所不同的重要趨勢，例如使用者留存率、應用程式穩定性和應用程式內購收益。您最多可以在實驗中追蹤五個非目標指標。

舉例來說，假設您已在應用程式中新增新的應用程式內購買項目，並想比較兩種不同的「提醒」訊息成效。在這種情況下，您可能會選擇將「購買收益」設為目標指標，因為您希望勝出版本代表能帶來最高應用程式內購買收益的通知。此外，由於您還想追蹤哪個變化版本能促成更多日後轉換和留存使用者，因此可以在「其他要追蹤的指標」中加入下列指標：

  • 預估總收益：查看兩種變化版本的應用程式內購和廣告收益總和差異
  • Retention (1 day)、Retention (2-3 days)、Retention (4-7 days)，以便追蹤每日/每週的使用者續留率

下表詳細說明如何計算目標指標和其他指標。

「目標」指標

指標 說明
未遇到當機情形的使用者 在實驗期間，Firebase Crashlytics SDK 偵測到，並未在應用程式中遇到錯誤的使用者百分比。
預估廣告收益 預估廣告收益。
預估總收益 購買和預估廣告收益的總價值。
購買收益 所有 purchase 和 in_app_purchase 事件的總價值。
留存 (1 天) 每天回訪應用程式的使用者人數。
回訪率 (2 至 3 天) 在 2 到 3 天內回訪應用程式的使用者人數。
留存率 (4 到 7 天) 在 4 到 7 天內回訪應用程式的使用者人數。
留存 (8 到 14 天) 在 8 到 14 天內回訪應用程式的使用者人數。
留存率 (15 天以上) 上次使用後 15 天以上回訪的使用者人數。
first_open 使用者安裝/重新安裝應用程式後，初次開啟應用程式時觸發的 Analytics 事件。用於轉換漏斗。

其他指標

指標 說明
通知_關閉 Analytics 事件：在使用者關閉 Notifications 編寫器傳送的通知時觸發 (僅限 Android)。
notification_receive 在應用程式於背景運作期間，收到 Notifications 編寫器傳送的通知時觸發的 Analytics 事件 (僅限 Android)。
os_update Analytics 事件，用於追蹤裝置作業系統更新為新版本的時機。詳情請參閱「自動收集的事件」。
screen_view Analytics 事件，可追蹤應用程式內的螢幕瀏覽次數。如需更多資訊，請參閱「追蹤螢幕瀏覽次數」。
session_start 用於計算應用程式中使用者工作階段的 Analytics 事件。如需更多資訊，請參閱「自動收集的事件」。