建立訊息實驗並進行 A/B 測試

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

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

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

建立實驗

使用通知編輯器的實驗可讓您針對單一通知訊息評估多個變化版本。

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

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

  2. Firebase 控制台導覽列的「Engage」部分中,按一下 A/B Testing

  3. 按一下「建立實驗」,然後在系統提示您要實驗的服務時,選取「通知」

  4. 輸入實驗的「名稱」和選填的「說明」,然後按一下「下一步」

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

    • 版本:應用程式的一或多個版本
    • 使用者目標對象: Analytics 用於指定可能納入實驗的使用者目標對象
    • 使用者屬性:一或多個 Analytics 使用者屬性,用於選取可能納入實驗的使用者
    • 國家/地區:一或多個國家/地區,用於選取可能會納入實驗的使用者
    • 裝置語言:一或多種語言和語言代碼,用於選取可能會納入實驗的使用者
    • 首次開啟:根據使用者首次開啟應用程式的時間指定目標使用者
    • 上次與應用程式互動:根據使用者上次與應用程式互動的時間指定目標使用者
  6. 設定目標使用者百分比:選取應用程式使用者族群中符合「目標使用者」下所設定條件的百分比,並將這些使用者平均分配至實驗中的基準和一或多個變化版本。這個值可以是 0.01% 到 100% 之間的任何百分比。系統會隨機將百分比重新指派給每項實驗的使用者,包括重複的實驗。

  7. 在「變化版本」部分的「輸入訊息文字」欄位中,輸入要傳送給基準群組的訊息。如要不向基準群組傳送訊息,請將這個欄位留空。

  8. (選用) 如要在實驗中加入多個變化版本,請按一下「新增變化版本」。根據預設,實驗會有一個控制組和一個變化版本。

  9. (選用) 為實驗中的每個變化版本輸入名稱,以取代「變化版本 A」、「變化版本 B」等名稱。

  10. 為實驗定義目標指標,以便在評估實驗變化版本時使用,並從下拉式清單中選取所需的其他指標。這些指標包括內建目標 (參與度、購買、收益、留存率等)、Analytics 轉換事件和其他 Analytics 事件。

  11. 選擇訊息選項:

    • 發布日期:您可以選擇「立即發送」,在儲存時立即啟動實驗,或是選擇「已排定」,指定日後要啟動實驗的時間。
    • 進階選項:如要為實驗中包含的所有通知選擇進階選項,請展開「進階選項」,然後變更任何列出的訊息選項。
  12. 按一下「查看」即可儲存實驗。

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

在測試裝置上驗證實驗

您可以為每個 Firebase 安裝作業擷取與其相關聯的 FCM 註冊權杖。您可以使用這個符記,在安裝應用程式的測試裝置上測試特定實驗變化版本。如要在測試裝置上驗證實驗,請執行下列步驟:

  1. 取得 FCM 註冊權杖,如下所示:

    Swift

    Messaging.messaging().token { token, error in
      if let error = error {
        print("Error fetching FCM registration token: \(error)")
      } else if let token = token {
        print("FCM registration token: \(token)")
        self.fcmRegTokenMessage.text  = "Remote FCM registration token: \(token)"
      }
    }

    Objective-C

    [[FIRMessaging messaging] tokenWithCompletion:^(NSString *token, NSError *error) {
      if (error != nil) {
        NSLog(@"Error getting FCM registration token: %@", error);
      } else {
        NSLog(@"FCM registration token: %@", token);
        self.fcmRegTokenMessage.text = token;
      }
    }];

    Java

    FirebaseMessaging.getInstance().getToken()
        .addOnCompleteListener(new OnCompleteListener<String>() {
            @Override
            public void onComplete(@NonNull Task<String> task) {
              if (!task.isSuccessful()) {
                Log.w(TAG, "Fetching FCM registration token failed", task.getException());
                return;
              }
    
              // Get new FCM registration token
              String token = task.getResult();
    
              // Log and toast
              String msg = getString(R.string.msg_token_fmt, token);
              Log.d(TAG, msg);
              Toast.makeText(MainActivity.this, msg, Toast.LENGTH_SHORT).show();
            }
        });

    Kotlin

    FirebaseMessaging.getInstance().token.addOnCompleteListener(OnCompleteListener { task ->
        if (!task.isSuccessful) {
            Log.w(TAG, "Fetching FCM registration token failed", task.exception)
            return@OnCompleteListener
        }
    
        // Get new FCM registration token
        val token = task.result
    
        // Log and toast
        val msg = getString(R.string.msg_token_fmt, token)
        Log.d(TAG, msg)
        Toast.makeText(baseContext, msg, Toast.LENGTH_SHORT).show()
    })

    C++

    firebase::InitResult init_result;
    auto* installations_object = firebase::installations::Installations::GetInstance(
        firebase::App::GetInstance(), &init_result);
    installations_object->GetToken().OnCompletion(
        [](const firebase::Future<std::string>& future) {
          if (future.status() == kFutureStatusComplete &&
              future.error() == firebase::installations::kErrorNone) {
            printf("Installations Auth Token %s\n", future.result()->c_str());
          }
        });

    Unity

    Firebase.Messaging.FirebaseMessaging.DefaultInstance.GetTokenAsync().ContinueWith(
      task => {
        if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) {
          UnityEngine.Debug.Log(System.String.Format("FCM registration token {0}", task.Result));
        }
      });
  2. Firebase 控制台導覽列中,按一下「A/B 測試」
  3. 按一下「草稿」,將游標移至實驗項目上,然後點選內容選單 (),再點選「管理測試裝置」
  4. 輸入測試裝置的 FCM 權杖,然後選擇要傳送至該測試裝置的實驗變化版本。
  5. 執行應用程式,確認測試裝置已收到所選變化版本。

管理實驗

無論您是使用 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. 實驗執行一段時間後 (FCMIn-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. 「指定目標」對話方塊會顯示一個選項,可增加參與實驗的使用者百分比。選取大於目前百分比的數字,然後按一下「發布」。實驗將推送至您指定的使用者百分比。

複製或停止實驗

  1. Firebase 控制台導覽選單的「Engage」部分,按一下 A/B Testing
  2. 按一下「已完成」或「正在執行」,將游標懸停在實驗上,然後按一下內容功能表 (),再按一下「複製實驗」或「停止實驗」

指定使用者

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

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

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

使用「contains regex」運算子時,您可以使用 RE2 格式建立規則運算式。規則運算式可以比對目標版本字串的全部或部分內容。您也可以使用 ^$ 錨點,比對目標字串的開頭、結尾或整個字串。

使用者目標對象 includes all of,
includes at least one of,
does not include all of,
does not include at least one of
選取一或多個 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 偵測到的錯誤的使用者百分比。
預估廣告收益 預估廣告收益。
預估總收益 購買和預估廣告收益的總價值。
購買收益 所有 purchasein_app_purchase 事件的總值。
保留率 (1 天) 每天回訪應用程式的使用者人數。
保留 (2 到 3 天) 在 2 到 3 天內回訪應用程式的使用者人數。
留存率 (4 到 7 天) 在 4 到 7 天內回訪應用程式的使用者人數。
留存 (8 到 14 天) 在 8 到 14 天內回訪應用程式的使用者人數。
留存 (15 天以上) 自上次使用應用程式起算,超過 15 天後回訪應用程式的使用者人數。
first_open 使用者安裝/重新安裝應用程式後,初次開啟應用程式時觸發的 Analytics 事件。用於轉換漏斗。

其他指標

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

BigQuery 資料匯出

除了在 Firebase 控制台中查看 A/B Testing 實驗資料,您也可以在 BigQuery 中檢查及分析實驗資料。雖然 A/B Testing 沒有獨立的 BigQuery 資料表,但實驗和變化版本成員資格會儲存在 Analytics 事件表格中的每個 Google Analytics 事件中。

包含實驗資訊的使用者資源格式為 userProperty.key like "firebase_exp_%"userProperty.key = "firebase_exp_01",其中 01 為實驗 ID,而 userProperty.value.string_value 則包含實驗變化版本的 (以零為起點) 索引。

您可以使用這些實驗使用者屬性來擷取實驗資料。這樣一來,您就能以多種方式切割實驗結果,並獨立驗證 A/B Testing 的結果。

如要開始使用,請按照本指南所述完成下列步驟:

  1. 在 Firebase 主控台中為 Google Analytics 啟用 BigQuery 匯出功能
  2. 使用 BigQuery 存取 A/B Testing 資料
  3. 探索查詢範例

在 Firebase 主控台中為 Google Analytics 啟用 BigQuery 匯出功能

如果您使用的是 Spark 方案,可以使用 BigQuery 沙箱免費存取 BigQuery,但須遵守沙箱限制。詳情請參閱「定價和 BigQuery 沙箱」一文。

首先,請確認您將 Analytics 資料匯出至 BigQuery

  1. 開啟「整合」分頁,您可以透過 Firebase 控制台中的 > 專案設定」存取該分頁。
  2. 如果您已將 BigQuery 與其他 Firebase 服務搭配使用,請按一下「管理」。否則,請按一下「連結」
  3. 詳閱「關於將 Firebase 連結至 BigQuery,然後按一下「下一步」
  4. 在「設定整合」部分中,啟用「Google Analytics」切換按鈕。
  5. 選取區域並選擇匯出設定。

  6. 按一下「連結至 BigQuery

視您選擇的資料匯出方式而定,表格可能需要最多一天的時間才能使用。如要進一步瞭解如何將專案資料匯出至 BigQuery,請參閱「將專案資料匯出至 BigQuery」。

BigQuery 中存取 A/B Testing 資料

在查詢特定實驗的資料之前,請先取得下列部分或全部資訊,以便在查詢中使用:

  • 實驗 ID:您可以從實驗總覽頁面的網址取得。舉例來說,如果網址類似 https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25,實驗 ID 就是 25
  • Google Analytics 房源 ID:這是 Google Analytics 房源的 9 位數 ID。您可以在 Google Analytics 中找到這個值,當您展開專案名稱來顯示 Google Analytics 事件資料表 (project_name.analytics_000000000.events) 的名稱時,這個值也會顯示在 BigQuery 中。
  • 實驗日期:如要編寫更快速且更有效率的查詢,建議您將查詢範圍限制在包含實驗資料的 Google Analytics 每日事件資料表分區,也就是以 YYYYMMDD 後置字元標示的資料表。因此,如果實驗從 2024 年 2 月 2 日開始,到 2024 年 5 月 2 日結束,您就會指定 _TABLE_SUFFIX between '20240202' AND '20240502'。如需範例,請參閱「選取特定實驗的值」。
  • 事件名稱:通常會與您在實驗中設定的目標指標相對應。例如 in_app_purchase 事件、ad_impressionuser_retention 事件。
」一文。

收集產生查詢所需的資訊後,請按照下列步驟操作:

  1. Google Cloud 控制台中開啟 BigQuery
  2. 選取專案,然後選取「建立 SQL 查詢」
  3. 新增查詢。如需執行的查詢範例,請參閱「探索查詢範例」。
  4. 按一下「執行」

使用 Firebase 控制台的自動產生查詢查詢實驗資料

如果您使用 Blaze 方案,實驗總覽頁面會提供查詢範例,用來傳回您查看的實驗名稱、變化版本、事件名稱和事件數量。

如要取得並執行自動產生的查詢,請按照下列步驟操作:

  1. Firebase 主控台中開啟 A/B Testing,然後選取要查詢的 A/B Testing 實驗,即可開啟「實驗總覽」
  2. 在「選項」選單中,選取「BigQuery 整合」下方的「查詢實驗資料」。這會在 Google Cloud 主控台內的 BigQuery 中開啟專案,並提供可用來查詢實驗資料的基本查詢。

以下範例顯示為名為「冬季歡迎實驗」的實驗產生的查詢,其中包含三個變化版本 (包括基準)。這項作業會傳回有效的實驗名稱、變體名稱、不重複事件,以及每個事件的事件計數。請注意,查詢建構工具不會在資料表名稱中指定專案名稱,因為它會直接在專案中開啟。

  /*
    This query is auto-generated by Firebase A/B Testing for your
    experiment "Winter welcome experiment".
    It demonstrates how you can get event counts for all Analytics
    events logged by each variant of this experiment's population.
  */
  SELECT
    'Winter welcome experiment' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'Welcome message (1)'
      WHEN '2' THEN 'Welcome message (2)'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_000000000.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN '20240202' AND '20240502')
    AND userProperty.key = 'firebase_exp_25'
  GROUP BY
    experimentVariant, eventName

如需其他查詢範例,請參閱「查看查詢範例」。

查看查詢範例

以下各節提供查詢範例,可用於從 Google Analytics 事件資料表中擷取 A/B Testing 實驗資料。

從所有實驗中擷取購買和實驗標準差值

您可以使用實驗結果資料,獨立驗證 Firebase A/B Testing 結果。以下 BigQuery SQL 陳述式會擷取實驗變體、每個變體的不重複使用者人數,以及 in_app_purchaseecommerce_purchase 事件的總收益,以及在 _TABLE_SUFFIX 開始和結束日期指定的時間範圍內,所有實驗的標準差。您可以使用從這項查詢取得的資料,搭配統計顯著性產生器進行單尾 t 檢定,驗證 Firebase 提供的結果是否與您自己的分析結果相符。

如要進一步瞭解 A/B Testing 如何計算推論結果,請參閱「解讀測試結果」。

  /*
    This query returns all experiment variants, number of unique users,
    the average USD spent per user, and the standard deviation for all
    experiments within the date range specified for _TABLE_SUFFIX.
  */
  SELECT
    experimentNumber,
    experimentVariant,
    COUNT(*) AS unique_users,
    AVG(usd_value) AS usd_value_per_user,
    STDDEV(usd_value) AS std_dev
  FROM
    (
      SELECT
        userProperty.key AS experimentNumber,
        userProperty.value.string_value AS experimentVariant,
        user_pseudo_id,
        SUM(
          CASE
            WHEN event_name IN ('in_app_purchase', 'ecommerce_purchase')
              THEN event_value_in_usd
            ELSE 0
            END) AS usd_value
      FROM `PROJECT_NAME.analytics_ANALYTICS_ID.events_*`
      CROSS JOIN UNNEST(user_properties) AS userProperty
      WHERE
        userProperty.key LIKE 'firebase_exp_%'
        AND event_name IN ('in_app_purchase', 'ecommerce_purchase')
        AND (_TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYMMDD')
      GROUP BY 1, 2, 3
    )
  GROUP BY 1, 2
  ORDER BY 1, 2;

選取特定實驗的值

以下查詢範例說明如何取得 BigQuery 中特定實驗的資料。這個範例查詢會傳回實驗名稱、變化版本名稱 (包括基準)、事件名稱和事件計數。

  SELECT
    'EXPERIMENT_NAME' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'VARIANT_1_NAME'
      WHEN '2' THEN 'VARIANT_2_NAME'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_ANALYTICS_PROPERTY.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN 'YYYMMDD' AND 'YYYMMDD')
    AND userProperty.key = 'firebase_exp_EXPERIMENT_NUMBER'
  GROUP BY
    experimentVariant, eventName