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

當您與使用者聯絡或開始新的行銷廣告活動時，請務必確保一切正確無誤。A/B 測試可讓您在選定的使用者族群中測試不同的訊息版本，找出最合適的措辭和呈現方式。無論您的目標是提高留存率，還是提高優惠轉換率，A/B 測試都能執行統計分析，判斷訊息變化版本是否優於所選目標的基準。

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

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

建立實驗

使用通知編寫器進行實驗，即可評估單一通知訊息的多個變化版本。

  1. 確認專案已啟用 Google Analytics，實驗才能存取 Analytics 資料。

    如果您在建立專案時未啟用 Google Analytics，可以在 Firebase 控制台的「 Settings > Integrations tab」中啟用。

  2. 在 Firebase 控制台中，依序前往「DevOps & Engagement」> 「A/B Testing」。

  3. 按一下「Create experiment」(建立實驗)，系統提示您選擇要實驗的服務時，請選取「Notifications」(通知)。

  4. 輸入實驗的「Name」(名稱) 和「Description」(說明) (選填)，然後按一下「Next」(下一步)。

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

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

  6. 設定「Percentage of target users」(目標使用者百分比)：選取應用程式使用者族群中符合「Target users」(目標使用者) 條件的百分比，並在實驗中平均分配給基準和一或多個變化版本。可以是 0.01% 到 100% 之間的任何百分比。 系統會隨機為每項實驗 (包括重複的實驗) 的使用者重新指派百分比。

  7. 在「Variants」(變化版本) 區段的「Enter message text」(輸入訊息文字) 欄位中，輸入要傳送給基準群組的訊息。如不想傳送訊息給基準組，請將這個欄位留空。

  8. (選用) 如要在實驗中加入多個變化版本，請按一下「Add Variant」(新增變化版本)。根據預設，實驗會包含一個基準和一個變化版本。

  9. (選用) 輸入實驗中各變化版本的名稱，取代「變化版本 A」、「變化版本 B」等名稱。

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

  11. 選擇訊息選項：

    • 傳送日期：選擇「立即傳送」，即可在儲存後立即啟動實驗；或選擇「已排定」，指定日後啟動實驗的時間。
    • 進階選項：如要為實驗中的所有通知選擇進階選項，請展開「Advanced options」(進階選項)，然後變更列出的任何訊息選項。

  12. 按一下「審查」儲存實驗。

每項專案最多可建立 300 個實驗 (包括推出作業)，其中最多可有 24 個執行中的實驗和推出作業，其餘則為已完成的實驗。

在測試裝置上驗證實驗

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

  1. 按照下列步驟取得 FCM 註冊權杖：

    Swift

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

    Objective-C

    [[FIRMessaging messaging] tokenWithCompletion:^(NSString * _Nullable token, NSError * _Nullable error) {
  if (error != nil) {
    NSLog(@"Error fetching the remote FCM registration token: %@", error);
  } else {
    NSLog(@"Remote FCM registration token: %@", token);
    NSString* message =
      [NSString stringWithFormat:@"FCM registration token: %@", token];
    // display message
    NSLog(@"%@", message);
  }
}];

    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 控制台中，依序前往「DevOps & Engagement」> 「A/B Testing」。
  3. 按一下「草稿」，將滑鼠游標懸停在實驗上，按一下內容選單 ()，然後點選「管理測試裝置」。
  4. 輸入測試裝置的 FCM 權杖，然後選擇要傳送至該測試裝置的實驗變化版本。
  5. 執行應用程式，並確認測試裝置是否收到所選變化版本。

管理實驗

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

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

開始實驗

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

監控實驗

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

  1. 在 Firebase 控制台中，依序前往「DevOps & Engagement」> 「A/B Testing」。

  2. 按一下「執行中」，然後點選或搜尋實驗名稱。這個頁面會顯示執行中實驗的各種觀測和模擬統計資料，包括：

    • 與基準的差異百分比：用來衡量特定變化版本與基準相比，指標的改善程度。計算方式是比較變化版本和基準的值範圍。
    • 超越基準的機率：特定變化版本在所選指標上超越基準的預估機率。
    • 每位使用者 observed_metric：根據實驗結果，這是指標值在一段時間後可能落入的預測範圍。
    • 總observed_metric：基準或變化版本的觀察累積值。這個值可用來評估各個實驗變化版本的成效，以及計算改善幅度、值範圍、超越基準的機率和成為最佳變化版本的機率。視評估的指標而定，這個資料欄可能會標示為「每位使用者持續時間」、「每位使用者收益」、「留存率」或「轉換率」。

  3. 實驗執行一段時間後 (FCM 和 In-App Messaging 至少 7 天，Remote Config 至少 14 天)，這個頁面上的資料會指出哪個變化版本是「勝出版本」(如果有的話)。部分測量結果會附上長條圖，以視覺化格式呈現資料。

向所有使用者推出實驗

實驗執行一段時間後，目標指標會出現「領先者」(即勝出版本)，此時即可向所有使用者套用實驗設定。您可以選取此後要向所有人發布的變化版本。即使實驗結果沒有明顯的勝出版本，您仍可向所有使用者發布特定變化版本。

  1. 在 Firebase 控制台中，依序前往「DevOps & Engagement」> 「A/B Testing」。
  2. 按一下「Completed」或「Running」，然後點選要 向所有使用者發布的實驗，接著依序點選 「」 內容選單和「Roll out variant」。

  3. 如要向所有使用者推出實驗，請執行下列任一操作：

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

展開實驗

如果發現實驗吸引的使用者不足，A/B Testing無法判斷勝出組合，可以提高實驗的分配比例，觸及更高比例的應用程式使用者族群。

  1. 在 Firebase 控制台中，依序前往「DevOps & Engagement」> 「A/B Testing」。
  2. 選取要編輯的執行中實驗。
  3. 在「Experiment overview」(實驗總覽) 中，按一下「context menu」(內容選單) ，然後點選「Edit running experiment」(編輯執行中的實驗)。
  4. 「Targeting」(指定目標) 對話方塊會顯示一個選項，可提高參與實驗的使用者百分比。請選取大於目前百分比的數字，然後按一下「發布」。實驗會推送給指定百分比的使用者。

複製或停止實驗

  1. 在 Firebase 控制台中，依序前往「DevOps & Engagement」> 「A/B Testing」。
  2. 按一下「已完成」或「執行中」，將滑鼠游標懸停在實驗上，按一下內容選單 ()，然後點選「複製實驗」或「停止實驗」。

指定使用者

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

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

使用「contains」(包含)、「does not contain」(不包含) 或「matches exactly」(完全符合) 運算子時，您可以提供以半形逗號分隔的值清單。

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

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

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

A/B Testing 項指標

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

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

  • 預估總收益：查看兩個版本在應用程式內購和廣告收益的總和差異。
  • 留存率 (1 天)、留存率 (2-3 天)、留存率 (4-7 天)：追蹤每日或每週的使用者留存率。

下表詳細說明目標指標和其他指標的計算方式。

「目標」指標

指標 說明
未遇到當機情形的使用者 實驗期間，Firebase Crashlytics SDK 偵測到應用程式發生錯誤，未遇到錯誤的使用者百分比。

注意：Firebase Crashlytics 不支援網頁應用程式。
預估廣告收益 預估廣告收益。
預估總收益 購買和預估廣告收益的合併價值。
購買收益 所有 purchase 和 in_app_purchase 事件的合併價值。
留存 (1 天) 每天回訪應用程式的使用者人數。
留存 (2 至 3 天) 在 2 到 3 天內回訪應用程式的使用者人數。
留存率 (4 到 7 天) 4 到 7 天內回訪應用程式的使用者人數。
留存率 (8 至 14 天) 在 8 到 14 天內回訪應用程式的使用者人數。
留存率 (15 天以上) 上次使用應用程式後，15 天以上才再次開啟應用程式的使用者人數。
first_open 使用者安裝或重新安裝應用程式後，初次開啟應用程式時觸發的 Analytics 事件。做為轉換漏斗的一部分。

其他指標

指標 說明
notification_dismiss Analytics 事件，會在通知編寫器傳送的通知遭到關閉時觸發 (僅限 Android)。
notification_receive 當應用程式在背景執行時，收到通知編寫器傳送的通知，就會觸發 Analytics 事件 (僅限 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 控制台中，依序前往「 Settings」(設定) >「Integrations」(整合) 分頁。

  2. 在「BigQuery」資訊卡中，按一下「Manage」(管理)，確認 專案會將Analytics資料匯出至BigQuery。

    如果資訊卡顯示「Link」(連結)，則必須設定匯出作業 (繼續下一個步驟)。

  3. 如要設定匯出功能，請按照下列步驟操作：

    1. 詳閱「關於將 Firebase 連結至 BigQuery」，然後按一下「Next」(下一步)。

    2. 在「Configure integration」(設定整合) 部分，啟用 「Google Analytics」。

    3. 選取區域和匯出設定。

    4. 按一下「連結至 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 事件。
」

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

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

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

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

如要取得並執行自動生成的查詢，請按照下列步驟操作：

  1. 在 Firebase 控制台中，依序前往「DevOps & Engagement」> 「A/B Testing」。
  2. 選取要查詢的 A/B Testing 實驗，開啟「Experiment overview」(實驗總覽)。
  3. 在「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