建立 Firebase 遠端設定實驗並進行 A/B 測試

當您使用 Firebase Remote Config 為擁有活躍使用者群的應用程式部署設定時，請務必確保設定正確無誤。您可以使用 A/B Testing 實驗，以最佳方式判斷下列事項：

  • 實作功能的最佳做法，以改善使用者體驗。往往，應用程式開發人員在應用程式在應用程式商店的評分下降後，才會發現使用者不喜歡新功能或更新的使用者體驗。您可以透過 A/B 版本測試，評估使用者是否喜歡新功能的變化版本，或是是否偏好現有的應用程式。此外，將大多數使用者歸入基準群組，可確保大多數的使用者在實驗結束前，都能繼續使用應用程式，而不會遇到任何行為或外觀變更。
  • 為達成業務目標，最佳化使用者體驗的最佳做法。有時候，您會實施產品變更，以便盡可能提高收入或留存率等指標。您可以透過 A/B 測試設定業務目標，而 Firebase 會執行統計分析，判斷變化版本是否比所選目標的基準組成效優異。

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

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

建立實驗

Remote Config 實驗可讓您針對一或多個 Remote Config 參數評估多個變化版本。

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

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

  2. 在 Firebase 控制台導覽選單的「Engage」部分，按一下 A/B Testing。

  3. 按一下「建立實驗」，然後在系統提示要實驗的服務時，選取 Remote Config。

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

  5. 填寫「指定目標」欄位，首先選擇要使用實驗的應用程式。您也可以按一下「&」，然後從下列清單中選擇選項，指定部分使用者參與實驗：

    • 版本：應用程式的一或多個版本
    • 版本編號：應用程式的版本代碼
    • 語言：一或多種語言和語言代碼，用於選取可能參與實驗的使用者
    • 國家/地區：一或多個國家/地區，用於選取要納入實驗的使用者
    • 使用者目標對象： Analytics 用於指定可能納入實驗的使用者
    • 使用者屬性：一或多個 Analytics 使用者屬性，用於選取可能納入實驗的使用者

    • 首次開啟：根據使用者首次開啟應用程式的時間指定目標使用者

      選取 Android 或 iOS 應用程式後，即可使用「以初次開啟時間指定目標」功能。以下 Remote Config SDK 版本支援這項功能：Apple 平台 SDK 9.0.0 以上版本和 Android SDK 21.1.1 以上版本 (Firebase BoM 30.3.0 以上版本)。

      在首次開啟事件中，Analytics 也必須已在用戶端啟用。

  6. 設定「目標使用者百分比」：輸入應用程式使用者人數的百分比，這些使用者符合「目標使用者」下方設定的條件，您可以將這些使用者平均分配給實驗中的基準和一或多個變化版本。這個值可以是 0.01% 到 100% 之間的任何百分比。系統會將使用者隨機指派給各個實驗，包括重複的實驗。

  7. 您可以視需要設定啟用事件，確保實驗中只計算首次觸發某些 Analytics 事件的使用者資料。請注意，所有符合指定目標參數的使用者都會收到 Remote Config 實驗值，但只有觸發啟用事件的使用者才會納入實驗結果。

    為確保實驗有效，請確認您選擇的事件發生在應用程式啟用擷取的設定值的之後。此外，下列事件一律會在擷取的值啟用之前發生，因此無法使用：

    • app_install
    • app_remove
    • app_update
    • dynamic_link_first_open

  8. 針對實驗的目標，請選取要追蹤的主要指標，並從清單中新增要追蹤的其他指標。包括內建目標 (購買、收益、留存、無當機的使用者等)、Analytics 轉換事件和其他 Analytics 事件。完成後，請點選「下一步」。

  9. 在「變體」部分，為實驗選擇控制組和至少一個變體。使用「選擇或建立新」清單，新增一或多個參數進行實驗。您可以建立先前未在 Firebase 控制台中使用的參數，但參數必須存在於應用程式中，才能發揮作用。您可以重複執行這項步驟，在實驗中新增多個參數。

  10. (選用) 如要為實驗新增多個變化版本，請按一下「新增其他變化版本」。

  11. 變更特定變化版本的一或多個參數。對於未納入實驗的使用者，所有未變更的參數都會保持不變。

  12. 展開「變化版本權重」，即可查看或變更實驗的變化版本權重。根據預設，每個版本的權重均等。請注意，如果權重不均等，可能會導致資料收集時間加長。此外，實驗開始後即不可再變更權重。

  13. 按一下「查看」即可儲存實驗。

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

在測試裝置上驗證實驗

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

  1. 取得安裝授權憑證，如下所示：

    Swift

    do {
  let result = try await Installations.installations()
    .authTokenForcingRefresh(true)
  print("Installation auth token: \(result.authToken)")
} catch {
  print("Error fetching token: \(error)")
}

    Objective-C

    [[FIRInstallations installations] authTokenForcingRefresh:true
                                               completion:^(FIRInstallationsAuthTokenResult *result, NSError *error) {
  if (error != nil) {
    NSLog(@"Error fetching Installation token %@", error);
    return;
  }
  NSLog(@"Installation auth token: %@", [result authToken]);
}];

    Java

    FirebaseInstallations.getInstance().getToken(/* forceRefresh */true)
        .addOnCompleteListener(new OnCompleteListener<InstallationTokenResult>() {
    @Override
    public void onComplete(@NonNull Task<InstallationTokenResult> task) {
        if (task.isSuccessful() && task.getResult() != null) {
            Log.d("Installations", "Installation auth token: " + task.getResult().getToken());
        } else {
            Log.e("Installations", "Unable to get Installation auth token");
        }
    }
});
    MainActivity.java

    Kotlin+KTX

    val forceRefresh = true
FirebaseInstallations.getInstance().getToken(forceRefresh)
    .addOnCompleteListener { task ->
        if (task.isSuccessful) {
            Log.d("Installations", "Installation auth token: " + task.result?.token)
        } else {
            Log.e("Installations", "Unable to get Installation auth token")
        }
    }
    MainActivity.kt

    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.Installations.FirebaseInstallations.DefaultInstance.GetTokenAsync(forceRefresh: true).ContinueWith(
  task => {
    if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) {
      UnityEngine.Debug.Log(System.String.Format("Installations token {0}", task.Result));
    }
  });
  2. 在 Firebase 控制台導覽列中，按一下「A/B 測試」。
  3. 按一下「草稿」 (針對遠端設定實驗，也可能會看到「執行中」)，將滑鼠游標懸停在實驗上，按一下內容選單 ()，然後點選「管理測試裝置」。
  4. 輸入測試裝置的安裝驗證權杖，並選擇要傳送至該測試裝置的實驗變化版本。
  5. 執行應用程式，確認測試裝置已收到所選變化版本。

如要進一步瞭解 Firebase 安裝作業，請參閱「管理 Firebase 安裝作業」。

管理實驗

無論您是使用 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. 實驗執行一段時間後 (FCM 和 In-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 格式建立規則運算式。規則運算式可以比對目標版本字串的全部或部分內容。您也可以使用 ^ 和 $ 錨點，比對目標字串的開頭、結尾或整個字串。
使用者目標對象 包含所有、
包含至少一項、
不包含所有、
不包含至少一項		 選取一或多個 Analytics 目標對象，指定可能會納入實驗的使用者。 部分指定 Google Analytics 目標對象的實驗，可能需要幾天時間才能累積資料，因為這些實驗會受到 Analytics 資料處理延遲的影響。這種延遲最有可能發生在新使用者的情況下，他們通常會在建立後 24 到 48 小時，才會加入符合資格的目標對象，或是最近建立的目標對象。

就 Remote Config 而言，這表示即使使用者在技術上符合目標對象資格，如果 Analytics 在執行 `fetchAndActivate()` 時尚未將使用者加入目標對象，該使用者就不會納入實驗。
使用者屬性 文字：
包含、
不包含、
完全相符、
包含規則運算式

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

在用戶端上，您只能為使用者屬性設定字串值。如果條件使用數值運算子，Remote Config 服務會將對應使用者屬性的值轉換為整數/浮點數。		 使用「contains regex」運算子時，您可以使用 RE2 格式建立規則運算式。規則運算式可以比對目標版本字串的全部或部分內容。您也可以使用 ^ 和 $ 錨點，比對目標字串的開頭、結尾或整個字串。
國家/地區 不適用 一或多個國家/地區，用於選取可能納入實驗的使用者。  
語言 不適用 一或多種語言和語言代碼，用於選取可能參與實驗的使用者。  
初次開啟 變更前
變更後

根據使用者首次開啟應用程式的時間指定目標使用者：

  • 選取「新使用者」，指定在指定未來日期和時間後，首次開啟應用程式的使用者。
  • 選取「時間範圍」，指定在指定日期和時間前後的範圍內，初次開啟應用程式的使用者。結合「之前」和「之後」條件，指定特定時間範圍內的使用者。

選取 Android 或 iOS 應用程式後，即可使用初次開啟的使用者指定目標。目前，下列 Remote Config SDK 版本支援這項功能：Apple 平台 SDK 9.0.0 以上版本和 Android SDK 21.1.1 以上版本 (Firebase BoM 30.3.0 以上版本)。

Analytics 也必須在首次開啟事件期間在用戶端上啟用。

A/B Testing 項指標

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

舉例來說，假設您使用 Remote Config 在應用程式中推出兩個不同的遊戲流程，並想針對應用程式內購和廣告收益進行最佳化，但也想追蹤每個變化版本的穩定性和使用者留存率。在這種情況下，您可以考慮選擇「預估總收益」做為目標指標，因為這項指標包含應用程式內購收益和廣告收益。接著，您可以新增下列其他指標：

  • 如要追蹤每日和每週的使用者留存率，請新增「Retention (2-3 days)」和「Retention (4-7 days)」。
  • 如要比較兩個遊戲流程的穩定性，請新增不受當機影響的使用者。
  • 如要查看各收益類型的詳細資料，請新增「購買收益」和「預估廣告收益」。

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

「目標」指標

指標 說明
未遇到當機情形的使用者 在實驗期間，未在應用程式中遇到 Firebase Crashlytics SDK 偵測到的錯誤的使用者百分比。
預估廣告收益 預估廣告收益。
預估總收益 購買和預估廣告收益的總價值。
購買收益 所有 purchase 和 in_app_purchase 事件的總價值。
回訪率 (1 天) 每天回訪應用程式的使用者人數。
保留 (2 到 3 天) 在 2 到 3 天內回訪應用程式的使用者人數。
留存率 (4 到 7 天) 在 4 到 7 天內回訪應用程式的使用者人數。
留存 (8 到 14 天) 在 8 到 14 天內回訪應用程式的使用者人數。
留存率 (15 天以上) 自上次使用應用程式起算，超過 15 天後回訪應用程式的使用者人數。
first_open 使用者安裝/重新安裝應用程式後，初次開啟應用程式時觸發的 Analytics 事件。用於轉換漏斗。

其他指標

指標 說明
notification_dismiss 當使用者關閉 Notifications 編寫器傳送的通知時，系統會觸發 Analytics 事件 (僅限 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_impression 或 user_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_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