關於 Firebase A/B 測試

為協助您盡可能提高測試結果的相關性和實用性，本頁面會詳細說明 Firebase A/B Testing 的運作方式。

樣本數量

Firebase A/B Testing 推論不需要在開始實驗前，先確認最小樣本大小。一般來說，您應選擇自己最能接受的最大實驗曝光率。樣本數量越多，找到具統計顯著性的結果的機會就越高，尤其是當變化版本之間的成效差異不大時。您也可以參考線上樣本數量計算機，根據實驗特徵找出建議的樣本數量。

編輯實驗

您可以編輯執行中的實驗所選參數，包括：

• 實驗名稱
• 說明
• 指定目標條件
• 變化版本值

如何編輯實驗：

1. 開啟要修改的實驗結果頁面。
2. 在「更多」 選單中，選取「編輯正在進行的實驗」。
3. 進行所需變更，然後按一下「發布」。

請注意，在實驗執行期間變更應用程式行為可能會影響結果。

遠端設定變化版本指派邏輯

符合所有實驗指定目標條件 (包括曝光百分比條件) 的使用者，會根據變化版本權重和實驗 ID 與使用者 Firebase 安裝 ID 的雜湊，指派至實驗變化版本。

Google Analytics目標對象會受到延遲影響，使用者一開始符合目標對象條件時，系統不會立即顯示目標對象：

• 建立新的目標對象後，可能需要 24 到 48 小時才會開始累積新使用者。
• 新使用者通常會在符合資格後的 24 到 48 小時內，加入符合資格的目標對象。

如要指定時間敏感的目標，請考慮使用 Google Analytics 使用者屬性或內建的指定目標選項，例如國家/地區、語言和應用程式版本。

使用者加入實驗後，系統會持續將他們指派至實驗變化版本，並在實驗仍在進行時，持續接收實驗的參數值，即使使用者屬性變更且不再符合實驗指定條件，也是如此。

啟用事件

實驗啟動事件會將實驗評估範圍限制在觸發啟動事件的應用程式使用者。實驗啟用事件不會對應用程式擷取的實驗參數造成任何影響。凡是符合實驗指定條件的使用者，都會收到實驗參數。因此，請務必選擇在擷取及啟用實驗參數後，但在使用實驗參數修改應用程式行為之前發生的啟用事件。

變化版本權重

建立實驗時，您可以變更預設的變化版本權重，將更多實驗使用者分配至變化版本。

解讀測試結果

Firebase A/B Testing 會使用頻率推論，協助您瞭解實驗結果是否可能僅是偶然發生。這個可能性會以機率值或p 值表示。如果實際上並無效果，兩個變化版本之間的成效差異可能會因為隨機機率而發生，而 p 值就是發生這種情況的機率，以 0 到 1 之間的值來衡量。A/B Testing 使用 0.05 的顯著性水準，以便：

• 如果 p 值小於 0.05，表示如果實際差異為零，這麼極端的差異出現的機率小於 5%。由於 0.05 是閾值，因此任何小於 0.05 的 p 值都表示變化版本之間存在統計顯著差異。
• 如果 P 值大於 0.05，表示變化版本之間的差異不具統計顯著性。

實驗資料每天會更新一次，上次更新時間會顯示在實驗結果頁面的頂端。

實驗結果圖表會顯示所選指標的累積平均值。舉例來說，如果您以「每位使用者的廣告收益」做為指標，系統就會顯示每位使用者的觀察收益；如果您以「無異常中斷的使用者」做為指標，系統就會追蹤未發生異常中斷的使用者百分比。這項資料是從實驗開始累積而來。

結果會分為「觀測資料」和「推論資料」。觀察資料會直接從 Google Analytics 資料計算而得，推論資料則會提供 p 值和置信區間，協助您評估觀察資料的統計顯著性。

系統會針對每項指標顯示下列統計資料：

觀察到的資料

• 追蹤指標的總值 (留存使用者人數、發生當機的使用者人數、總收益)
• 指標專屬比率 (留存率、轉換率、每位使用者平均收益)
• 變化版本與基準版本之間的差異百分比 (提升幅度)

推論資料

• 95% CI (平均值差異) 會顯示一個間隔，其中包含追蹤指標的「實際」值，並提供 95% 的信心等級。舉例來說，如果實驗結果顯示預估總收益的 95% CI 介於 $5 美元和 $10 美元之間，則平均值的實際差異有 95% 的機率介於 $5 美元和 $10 美元之間。如果信賴區間包含 0，表示系統未偵測到變化版本和基準組之間的差異具有統計顯著性。

  信賴區間值會以與追蹤指標相符的格式顯示。例如使用者留存時間 (以 HH:MM:SS 為單位)、每位使用者的廣告收益 (以美元為單位) 和轉換率百分比。

• P 值：代表在變化版本和基準之間沒有實際差異的情況下，觀察到與實驗結果相同的極端資料的機率。P 值越低，重複實驗時，觀察到的成效越有可能維持不變。值為 0.05 或更低，表示差異顯著，且結果不太可能是偶然發生。P 值是根據單尾測試計算，其中變化版本值大於基準值。Firebase 會針對連續變數 (例如收益等數值) 使用不等變異 t 檢定，針對轉換資料 (例如使用者留存率、未受當機影響的使用者、觸發 Google Analytics 事件的使用者等二進位值) 使用比例 z 檢定。

實驗結果會針對每個實驗變化版本提供重要洞察，包括：

• 與直接測量 (即實際觀察資料) 相比，每個實驗指標高於或低於基準值的幅度
• 變化版本與基準版本之間觀測到的差異，可能因隨機機率而發生的機率 (p 值)
• 每個實驗指標的變化版本與基準之間，可能包含「實際」成效差異的範圍，可用來瞭解「最佳」和「最差」成效情境

解讀 Google 最佳化工具實驗結果

Firebase A/B Testing 2023 年 10 月 23 日前開始的實驗結果由 Google 最佳化工具提供。Google 最佳化工具會使用貝葉斯推論，根據實驗資料產生有用的統計資料。

結果會分為「觀察資料」和「模擬資料」。觀察到的資料是直接以數據分析資料計算而得，以模型產生的資料則是對觀察到的資料採用貝葉斯模型後得到的結果。

系統會針對每項指標顯示下列統計資料：

觀察到的數據

• 總價值 (變化版本中所有使用者的指標總和)
• 平均值 (變化版本使用者的指標平均值)
• 與基準的落差百分比

模擬資料

• 超越基準的機率：這個變化版本的指標值高於基準版本的機率
• 與基準的差異百分比：根據變化版本和基準的各項指標中位數模型估計值
• 指標範圍：指標值最有可能出現的範圍，可提供 50% 和 95% 的準確度

整體來說，實驗結果為實驗中的每個變化版本提供了三項重要洞察：

1. 與直接測量 (即實際觀察資料) 相比，每個實驗指標高於或低於基準值的幅度
2. 根據貝葉斯推論，每項實驗指標高於整體基準 / 最佳值的機率 (分別為優於基準 / 最佳值的機率)
3. 根據貝葉斯推論法 (「最佳」和「最壞」情境) 推算出的每項實驗指標合理範圍 (可信區間)

領先者判斷

如果實驗使用頻率推論，只要變化版本和基準組的目標指標，在成效統計資料上有顯著差異，Firebase 就會宣告變化版本勝出。如有多個版本符合這個條件，Firebase 會選擇 p 值最低的版本。

對於使用 Google 最佳化工具的實驗，如果變化版本在主要指標上有超過 95% 的機率優於基準組，Firebase 就會宣告該變化版本是「明顯領先」。如果有多個子類符合「明顯領先」的條件，系統只會將成效最佳的子類標示為「明顯領先」。

Firebase 在判斷勝出版本時只參考主要目標指標，因此建議您考量所有相關因素，並檢視次要指標的結果，再決定是否要推出勝出版本。您可能需要考量變更的預期優勢、負面風險 (例如改善信賴區間的下限)，以及對主要目標以外指標的影響。

舉例來說，如果主要指標為「不受當機影響的使用者」，且版本 A 明顯優於基準，但版本 A 的使用者留存率指標落後於基準使用者留存率，建議您進一步調查，再將版本 A 廣泛推出。

您可以根據對主要和次要指標的整體成效評估，推出任何變數 (不限於勝出版本)。

實驗時間長度

Firebase 建議您讓實驗持續執行，直到符合下列條件為止：

1. 實驗已累積足夠的資料，可提供實用結果。實驗和結果資料每天更新一次。建議您使用線上樣本數量計算機，評估實驗的建議樣本數量。
2. 實驗已執行一段時間，可確保有足夠的代表性樣本，並評估長期成效。一般來說，建議的遠端設定實驗最短執行時間為兩週。

實驗開始後，系統最多會處理 90 天的實驗資料。實驗會在 90 天後自動停止。Firebase 控制台不再更新實驗結果，實驗也停止傳送實驗專屬參數值。此時，用戶端會開始根據 Remote Config 範本中設定的條件擷取參數值。系統會保留歷來實驗資料，直到您刪除實驗為止。

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. 選取區域並選擇匯出設定。

   注意： 如要進一步瞭解 Firebase 設定的 Google Analytics，請參閱「資料收集」一文。

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_impression 或 user_retention 事件。

提示： 如果您使用 Blaze 方案，Firebase 可以產生範例查詢，用來擷取所選實驗的實驗名稱、變化版本、事件名稱和事件數量。詳情請參閱「使用 Firebase 控制台自動產生的查詢語法查詢實驗資料

」一文。

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

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

提示： 雖然這些步驟說明如何使用 Google Cloud 主控台，但您也可以使用 CLI 或用戶端程式庫來查詢 BigQuery。詳情請參閱 BigQuery 說明文件。

使用 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_purchase 和 ecommerce_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

限制

A/B Testing 的實驗總數上限為 300 個，其中包括 24 個執行中的實驗和 24 個實驗草稿。這些限制與 Remote Config 的推出作業共用。舉例來說，如果您有兩個正在進行的推行計畫和三個正在進行的實驗，最多可以再新增 19 個推行計畫或實驗。

• 如果您達到 300 項實驗總數上限或 24 項草擬實驗上限，則必須先刪除現有實驗，才能建立新實驗。

• 如果達到 24 個進行中的實驗和推出上限，您必須先停止進行中的實驗或推出作業，才能開始新的實驗。

每項實驗最多可包含 8 個變化版本 (包括基準)，每個變化版本最多可包含 25 個參數。實驗的大小上限約為 200 KiB。包括變化版本名稱、變化版本參數和其他設定中繼資料。