為協助您盡可能提高測試結果的關聯性和實用性，本頁面將詳細說明 Firebase A/B Testing 的運作方式。
樣本數
Firebase A/B Testing推論不需要在開始實驗前，先找出最小樣本大小。一般來說，建議您選擇能接受的最大實驗曝光層級。樣本數越大，越容易找出具統計顯著性的結果，尤其是變化版本之間的成效差異很小時。您也可以使用線上樣本大小計算工具，根據實驗特性找出建議的樣本大小。
編輯實驗
您可以編輯執行中實驗的特定參數，包括：
- 實驗名稱
- 說明
- 指定目標條件
- 子類值
如何編輯實驗：
- 在 Firebase 控制台中，依序前往「DevOps & Engagement」> 「A/B Testing」。
- 開啟要修改的實驗結果頁面。
- 在「更多」 選單中，選取「編輯執行中的實驗」。
- 變更完成後，按一下「發布」。
請注意，在實驗執行期間變更應用程式行為，可能會影響結果。
遠端設定變化版本指派邏輯
系統會根據變化版本權重、實驗 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% 信賴區間 (平均值差異) 顯示的區間包含追蹤指標的「實際」值，信賴度為 95%。舉例來說，如果實驗結果顯示預估總收益的 95% 信賴區間介於 $5 美元和 $10 美元之間，則平均值的實際差異有 95% 的機率介於 $5 美元和 $10 美元之間。如果信賴區間範圍包含 0，表示未偵測到變化版本和基準組之間有具統計顯著性的差異。
信賴區間值的格式會與追蹤指標相符。例如，使用者留存率的時間 (以
HH:MM:SS為單位)、每位使用者的廣告收益 (美元)，以及轉換率百分比。P 值：代表在變化版本和基準之間沒有實際差異的情況下，觀察到與實驗結果一樣極端的資料的機率。P 值越低，表示重複實驗時，觀察到的成效仍保持不變的可信度越高。如果值為 0.05 以下，表示差異顯著，結果不太可能是偶然發生。P 值是根據單尾檢定計算得出，其中變化版本值大於基準值。Firebase 會針對連續變數 (數值，例如收益) 使用異質變異數 t 檢定，並針對轉換資料 (二進位值，例如使用者留存率、未發生當機的使用者、觸發 Google Analytics 事件的使用者) 使用比例 z 檢定。
實驗結果會提供每個實驗變化版本的重要洞察資料，包括：
- 直接測量結果 (即實際觀察到的資料) 顯示，各項實驗指標與基準相比高出或低於多少
- 變化版本和基準版本之間觀測到的差異，可能是隨機發生的機率 (p 值)
- 這個範圍可能包含各實驗指標的變化版本和基準之間的「真實」成效差異，可用於瞭解「最佳情況」和「最差情況」的成效情境
決定主要元件
如果實驗採用頻率論推論，只要變化版本和基準組的目標指標，在成效統計資料上有顯著差異，Firebase 就會宣告變化版本勝出。如有多個版本符合這個條件，Firebase 會選擇 p 值最低的版本。
Firebase 在判斷勝出版本時只參考主要目標指標，因此建議您考量所有相關因素，並檢視次要指標的結果，再決定是否要推出勝出版本。建議您考量變更後預期的正面影響、負面風險 (例如改善幅度信賴區間的下限)，以及對主要目標以外指標的影響。
舉例來說，如果主要指標是「未發生當機的使用者」，而版本 A 的成效明顯優於基準，但版本 A 的使用者留存率指標落後基準，建議您先進一步調查，再擴大推出版本 A。
您可以根據主要和次要指標的整體成效評估結果，推出任何變化版本，不限於勝出版本。
實驗時間長度
Firebase 建議持續執行實驗，直到符合下列條件：
- 實驗已累積足夠資料，可提供實用結果。 實驗和結果資料每天更新一次。建議您使用線上樣本大小計算工具，評估實驗的建議樣本大小。
- 實驗已執行足夠長的時間，可確保使用者樣本具有代表性，並評估長期成效。一般遠端設定實驗的建議最短執行時間為兩週。
實驗資料最多會處理 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 的結果。
如要開始使用，請按照本指南所述完成下列步驟：
在 Firebase 控制台中，啟用 Google Analytics 的 BigQuery 匯出功能
如果您採用 Spark 方案，可以使用 BigQuery 沙箱免付費存取 BigQuery，但須遵守沙箱限制。詳情請參閱「定價和 BigQuery 沙箱」。
首先，請確認您將 Analytics 資料匯出至 BigQuery：
在 Firebase 控制台中，依序前往「
Settings 」(設定) >「Integrations」(整合) 分頁。在「BigQuery」資訊卡中，按一下「Manage」(管理)，確認 專案會將Analytics資料匯出至BigQuery。
如果資訊卡顯示「Link」(連結)，則必須設定匯出作業 (繼續下一個步驟)。
如要設定匯出功能，請按照下列步驟操作：
詳閱「關於將 Firebase 連結至 BigQuery」，然後按一下「Next」(下一步)。
在「Configure integration」(設定整合) 部分，啟用 「Google Analytics」。
選取區域和匯出設定。
按一下「連結至 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：這是 9 位數的 Google Analytics 資源 ID。您可以在 Google Analytics 中找到這個名稱；展開專案名稱以顯示 Google Analytics 事件資料表 (
project_name.analytics_000000000.events) 的名稱時，這個名稱也會顯示在 BigQuery 中。 - 實驗日期：為編寫更快速、更有效率的查詢，建議您將查詢限制在包含實驗資料的 Google Analytics 每日事件資料表分區，也就是以
YYYYMMDD後置字串識別的資料表。因此，如果實驗在 2026 年 2 月 2 日至 2026 年 5 月 2 日期間執行，請指定_TABLE_SUFFIX between '20260202' AND '20260502'。如需範例，請參閱「選取特定實驗的值」。 - 事件名稱：通常會對應您在實驗中設定的目標指標。例如
in_app_purchase事件、ad_impression或user_retention事件。
收集生成查詢所需的資訊後，請按照下列步驟操作：
使用 Firebase 控制台自動生成的查詢，查詢實驗資料
如果您使用的是 Blaze 方案，「實驗總覽」頁面會提供範例查詢，傳回您正在查看的實驗名稱、變化版本、事件名稱和事件數量。
如要取得並執行自動生成的查詢，請按照下列步驟操作：
- 在 Firebase 控制台中，依序前往「DevOps & Engagement」> 「A/B Testing」。
- 選取要查詢的 A/B Testing 實驗，開啟「Experiment overview」(實驗總覽)。
- 在「Options」(選項) 選單中，選取「BigQuery integration」(整合) 下方的 「Query experiment data」(查詢實驗資料)。這會在 Google Cloud 控制台的 BigQuery 中開啟專案，並提供基本查詢，可用於查詢實驗資料。
以下範例顯示為實驗產生的查詢，其中包含三個變化版本 (包括基準)，名為「Winter welcome experiment」。傳回進行中實驗的名稱、變化版本名稱、不重複事件，以及每個事件的事件計數。請注意，查詢建立工具不會在資料表名稱中指定專案名稱，因為它會直接在專案中開啟。
/*
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 '20260202' AND '20260502')
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 項可同時執行。這些限制與Remote Config推出作業共用。舉例來說，如果您有兩個正在執行的推出作業和三個正在執行的實驗，則最多可以再執行 19 個推出作業或實驗。
如果實驗總數達到 300 項上限，請先刪除現有實驗，再建立新實驗。
如果達到 24 項實驗和推出作業的上限，您必須先停止一項實驗或推出作業，才能開始新的實驗或推出作業。
一項實驗最多可有 8 個變化版本 (包括基準)，每個變化版本最多可有 25 個參數。實驗的大小上限約為 200 KiB。包括變化版本名稱、變化版本參數和其他設定中繼資料。