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

接觸使用者或推出新的行銷廣告活動時, 一定要確保自己做的都是正確的。A/B 測試可針對您的使用者族群測試訊息變化版本,找出最佳用詞和呈現方式。無論目標是提高某項優惠的留存率或轉換率,A/B 測試都可以執行統計分析,判斷訊息變化版本的成效是否優於所選目標的基準。

如要針對基準測試 A/B 版本測試功能變化版本,請按照下列步驟操作:

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

建立實驗

在實驗中使用通知編輯器,您可以評估單一通知訊息中的多個變化版本。

  1. 登入 Firebase 控制台,確認專案已啟用 Google Analytics (分析),這樣實驗才能存取 Analytics (分析) 資料。

    如果您未在建立專案時啟用 Google Analytics (分析),可在「Integrations」(整合) 分頁啟用該專案,也可以前往 Firebase 控制台的「>「Project settings」(專案設定) 存取該分頁。

  2. 在「Firebase 主控台」導覽列的「Engage」區段中,按一下「A/B Testing」

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

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

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

    • 版本:應用程式的一或多個版本
    • 使用者目標對象:使用 Analytics (分析) 目標對象來指定可能可納入實驗的使用者
    • 使用者屬性:用來選擇可能納入實驗的使用者的一或多個 Analytics (分析) 使用者屬性
    • 國家/地區:選取可能納入實驗的使用者的一或多個國家/地區
    • 裝置語言:指定可能納入實驗對象的一或多個語言和語言代碼。
    • 初次開啟:根據使用者第一次開啟應用程式的時間指定目標使用者
    • 應用程式最近一次的參與時間:根據使用者上次與應用程式互動的時間來指定使用者
  6. 設定「目標使用者百分比」:在「目標使用者」底下設定條件中,選擇要在基準和一或多個實驗變化版本之間平均分配的應用程式使用者數量百分比。這可以是介於 0.01% 至 100% 之間的任何百分比。系統會在每項實驗 (包括重複的實驗) 中,隨機將百分比重新指派給使用者。

  7. 在「Variants」區段的「Enter message text」欄位中,輸入要傳送給基準群組的訊息。如果不想傳送任何訊息給基準群組,請將這個欄位留白。

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

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

  10. 定義實驗變化版本時要使用的目標指標,以及下拉式選單中的任何需要的其他指標。包括內建目標 (參與度、購買、收益和回訪率等)Analytics (分析) 轉換事件以及其他 Analytics (分析) 事件

  11. 選擇郵件的選項:

    • 送達日期:選擇「立即傳送」可在儲存時立即啟動實驗,選擇「Scheduled」則可指定在未來啟動實驗的時間。
    • 進階選項:如要為實驗涵蓋的所有通知選擇進階選項,請展開「Advanced options」,然後變更畫面上列出的任何訊息選項。
  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+KTX

    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& 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 Testing」
  3. 按一下「草稿」,將滑鼠遊標懸停在實驗上,然後依序點選內容選單 () 和「管理測試裝置」
  4. 輸入測試裝置的 FCM 權杖,然後選擇要傳送至該測試裝置的實驗變化版本。
  5. 執行應用程式,並確認系統正透過測試裝置接收所選變化版本。

管理實驗

無論您是使用遠端設定、通知編輯器或 Firebase 應用程式內通訊來建立實驗,都可以驗證並開始實驗、在實驗執行期間監控,並增加執行實驗中的使用者數量。

實驗完成後,您可以記下勝出變化版本所用的設定,然後將這些設定發布給所有使用者。或者,您也可以進行其他實驗。

開始實驗

  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 和應用程式內通訊至少 7 天,遠端設定則是至少 14 天),本頁的資料會指出哪個變化版本 (如有) 為「領導者」。部分測量結果會提供長條圖,以圖表呈現資料。

對所有使用者推出實驗

當實驗時間夠長,讓您對目標指標產生「主要版本」(即勝出版本) 的時間,您可以向所有使用者發布實驗。方便您選取要向日後所有使用者發布的變化版本。即使實驗沒有產生明確的勝出組合,您還是可以選擇對所有使用者發布某個變化版本。

  1. 在「Firebase 主控台」導覽選單的「Engage」區段中,按一下「A/B Testing」
  2. 按一下「Completed」(已完成) 或「Running」(執行中),點選要向所有使用者發布的實驗,請按一下內容選單 ()「推出變化版本」
  3. 採取下列任一做法,向所有使用者推出實驗:

    • 如果實驗使用通知編輯器,請使用「推出訊息」對話方塊,將訊息傳送給未參與實驗的其餘目標使用者。
    • 在「遠端設定」實驗中,請選取變化版本,以決定要更新哪些遠端設定參數值。將建立實驗時定義的指定條件新增為範本中的新條件,確保推出作業只會影響實驗指定的使用者。按一下「Review in Remote Config」查看變更後,按一下「Publish changes」即可完成推出作業。
    • 進行應用程式內通訊實驗時,請使用對話方塊來判斷哪個變化版本需要以獨立的應用程式內通訊廣告活動的形式推出。選取後,系統會將您重新導向至 FIAM 撰寫畫面,以便在發布前進行任何變更。

展開實驗

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

  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 (分析) 使用者屬性可用來選取要納入實驗的使用者,並提供多個選項讓您選取使用者屬性值。

在用戶端中,您只能為使用者屬性設定字串值。針對使用數字運算子的條件,遠端設定服務會將對應使用者屬性的值轉換為整數/浮點值。
使用「包含規則運算式」運算子時,您可以透過 RE2 格式建立規則運算式。規則運算式可與所有或部分目標版本字串相符。您也可以使用 ^$ 錨點來比對目標字串的開始、結束或整個設定。
國家/地區 不適用 用來選擇可能納入實驗的一或多個國家/地區的使用者。  
語言 不適用 選擇可能應納入實驗範圍的一或多個語言和語言代碼。  
初次開啟 介於
不到
介於
根據使用者首次開啟應用程式的時間 (指定天數) 來指定使用者。
與應用程式的最近一次互動 介於
不到
介於
根據使用者上次與應用程式互動的時間 (指定天數) 來指定使用者。

A/B 測試指標

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

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

  • 預估總收益,查看兩個變化版本的應用程式內購和廣告收益總和有何差異
  • 保留 (1 天)保留 (2 至 3 天)回訪率 (4 至 7 天),以便追蹤每日/每週使用者留存率

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

「目標」指標

指標 說明
未遇到當機情形的使用者比例 在實驗期間,Firebase Crashlytics SDK 在您的應用程式中未遇到錯誤的使用者百分比。
預估廣告收益 預估廣告收益。
預估總收益 購買與預估廣告收益的加總值。
購買收益 所有 purchasein_app_purchase 事件的合併值。
回訪率 (1 天) 每日回訪您應用程式的使用者人數。
回訪率 (2 至 3 天) 在 2 到 3 天內回訪應用程式的使用者人數。
回訪率 (4 至 7 天) 在 4 到 7 天內返回應用程式的使用者人數。
回訪率 (8 至 14 天) 在 8 到 14 天內回訪應用程式的使用者人數。
回訪率 (15 天以上) 上次使用後 15 天以上回訪的使用者人數。
first_open 在安裝或重新安裝應用程式後,在使用者初次開啟應用程式時觸發的 Analytics (分析) 事件。用於轉換漏斗。

其他指標

指標 說明
通知_關閉 在通知編輯器傳送的通知關閉時觸發的 Analytics (分析) 事件 (僅限 Android)。
通知_receive 在應用程式於背景運作期間,收到通知編輯器傳送通知時觸發的數據分析事件 (僅限 Android)。
os_update 追蹤裝置作業系統更新為新版本時的 Analytics (分析) 事件。詳情請參閱「自動收集的事件」一文。
screen_view 這個 Analytics (分析) 事件,用來追蹤使用者在應用程式中瀏覽的畫面。詳情請參閱「追蹤畫面瀏覽」。
session_start 計算應用程式中使用者工作階段的 Analytics (分析) 事件。詳情請參閱「自動收集的事件」一文。

BigQuery 資料匯出

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

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

您可以使用這些實驗使用者屬性來擷取實驗資料。 這樣就能以多種不同方式劃分實驗結果,並獨立驗證 A/B 測試的結果。

首先,請依照本指南的說明完成下列步驟:

  1. 在 Firebase 控制台中啟用 Google Analytics (分析) 的 BigQuery Export
  2. 使用 BigQuery 存取 A/B 測試資料
  3. 探索查詢範例

在 Firebase 控制台中啟用 Google Analytics (分析) 的 BigQuery Export

如果您採用 Spark 方案,則可在符合沙箱限制的情況下,使用 BigQuery 沙箱免費存取 BigQuery。詳情請參閱定價和 BigQuery 沙箱一文。

首先,請將 Analytics (分析) 資料匯出至 BigQuery:

  1. 開啟「Integrations」(整合) 分頁標籤,前往 Firebase 控制台中的 >「Project settings」(專案設定) 存取該分頁。
  2. 如果您已將 BigQuery 與其他 Firebase 服務搭配使用,請按一下「管理」。如果尚未建立,請按一下「連結」。
  3. 請參閱「關於將 Firebase 連結至 BigQuery」一文,然後點選「下一步」
  4. 在「Configure integration」(設定整合) 部分中,啟用「Google Analytics (分析)」切換按鈕。
  5. 選取區域並選擇匯出設定。

  6. 按一下「連結至 BigQuery」

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

在 BigQuery 中存取 A/B 測試資料

查詢特定實驗的資料前,建議先取得下列 (或所有) 項目,以便用於查詢:

  • 實驗 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 後置字串識別的資料表。因此,如果實驗從 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 測試」,然後選取要查詢的 A/B 測試實驗,開啟「實驗總覽」
  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 測試實驗資料。

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

您可以使用實驗結果資料獨立驗證 Firebase A/B 測試結果。以下 BigQuery SQL 陳述式會擷取實驗變化版本、每個變化版本的不重複使用者人數,以及 in_app_purchaseecommerce_purchase 事件的總收益,以及在 _TABLE_SUFFIX 的開始與結束日期範圍內,所有實驗的標準差。透過從這項查詢取得的資料,可以搭配單尾 T 測試的統計顯著性產生器,驗證 Firebase 結果是否與您的分析相符。

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

  /*
    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