Firebase 将于 5 月 14 日重返 Google I/O 大会！立即报名。

本頁面由 Cloud Translation API 翻譯而成。

運用 A/B 測試建立應用程式內通訊實驗

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

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

建立實驗。
在測試裝置上驗證實驗。
管理實驗。

建立實驗

使用 Firebase 應用程式內通訊的實驗，可讓您評估單一應用程式內訊息的多個變化版本。

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

如果您未在建立專案時啟用 Google Analytics (分析)，可在「Integrations」(整合) 分頁啟用該專案，也可以前往 Firebase 控制台的「」>「Project settings」(專案設定) 存取該分頁。
在「Firebase 主控台」導覽選單的「Engage」區段中，按一下「A/B Testing」。
按一下「建立實驗」，然後在系統提示您進行實驗時，選取「應用程式內通訊」。
或者，在 Firebase 主控台導覽選單中，展開「Engage」，然後按一下「In-App Messaging」。接著按一下「新增實驗」。
輸入實驗的「名稱」和選填的「說明」，然後點選「下一步」。
填寫「指定目標」欄位，請先選擇使用實驗的應用程式。您也可以選擇包含下列項目，指定一部分使用者參與實驗：
- 版本：應用程式的一或多個版本
- 使用者目標對象：使用 Analytics (分析) 目標對象來指定可能可納入實驗的使用者
- 使用者屬性：用來選擇可能納入實驗的使用者的一或多個 Analytics (分析) 使用者屬性
- 國家/地區：選取可能納入實驗的使用者的一或多個國家/地區
- 裝置語言：指定可能納入實驗對象的一或多個語言和語言代碼。
- 初次開啟：根據使用者第一次開啟應用程式的時間指定目標使用者
- 應用程式最近一次的參與時間：根據使用者上次與應用程式互動的時間來指定使用者
注意： 以 Analytics (分析) 使用者目標對象為指定目標的實驗，可能需要 24 到 48 小時才能累積資料。如要進一步瞭解這個和其他指定目標選項，請參閱「指定使用者」一文。
設定「目標使用者百分比」：在「目標使用者」底下設定條件中，選擇要在基準和一或多個實驗變化版本之間平均分配的應用程式使用者數量百分比。這可以是介於 0.01% 至 100% 之間的任何百分比。系統會在每項實驗 (包括重複的實驗) 中，隨機將百分比重新指派給使用者。
在「Variants」部分中，使用一般應用程式內通訊廣告活動所使用的訊息設計介面，設定要傳送給基準的應用程式內訊息。
如要在實驗中加入變化版本，請按一下「新增變化版本」。根據預設，實驗會有一個基準和一個變化版本。
(選用) 為每個子類輸入較一目瞭然的名稱。
(選用) 按一下「Variants」區段頂端的「Compare variants」按鈕，即可將另外一個訊息變化版本與基準訊息並排比較。
定義評估實驗變化版本時要使用的實驗目標指標，以及您要從清單中使用的其他指標。包括內建目標 (參與度、購買、收益和回訪率等)Analytics (分析) 轉換事件以及其他 Analytics (分析) 事件
設定實驗的時段設定：
- 設定實驗的「開始」和「結束日期」。
- 設定在所有變化版本中觸發應用程式內訊息的方式。
按一下「查看」儲存實驗。

每個專案最多能有 300 個實驗，其中可包含最多 24 個執行中的實驗，其餘實驗則以草稿或已完成的形式完成。

在測試裝置上驗證實驗

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

取得安裝驗證權杖，如下所示：

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

在 Firebase 控制台的導覽列上，按一下「A/B Testing」。
按一下「草稿」 (和/或遠端設定實驗的「執行中」)，將滑鼠遊標懸停在實驗上，按一下內容選單 ()，然後按一下「管理測試裝置」。
輸入測試裝置的安裝驗證權杖，然後選擇要傳送至該測試裝置的實驗變化版本。
執行應用程式，並確認系統正透過測試裝置接收所選變化版本。

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

管理實驗

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

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

開始實驗

在「Firebase 主控台」導覽選單的「Engage」區段中，按一下「A/B Testing」。
按一下「草稿」，然後點選實驗標題。
如要驗證應用程式是否有使用者將納入實驗，請展開草稿詳細資料，然後檢查「指定目標與發布」部分中是否大於「0%」(例如：1% 符合條件的使用者)。
如要變更實驗，請按一下「編輯」。
如要開始實驗，請按一下「開始實驗」。每個專案一次最多可執行 24 項實驗。

監控實驗

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

在「Firebase 主控台」導覽選單的「Engage」區段中，按一下「A/B Testing」。
按一下「執行中」，然後點選或搜尋實驗標題。在這個頁面上，您可以查看關於執行中實驗的各種觀察到和模擬統計資料，包括：
- 與基準相比的百分比差異：評估指定變化版本與基準相比的改善幅度。計算方法是比較變化版本的值範圍與基準的值範圍。
- 超過基準的機率：特定變化版本打破所選指標基準的預估機率。
- 每位使用者 observed_metric：根據實驗結果，這是指標值會隨著時間的預測範圍。
- 總 observed_metric：觀察到的基準或變化版本累計值。此值可用來評估每個實驗變化版本的成效，並用於計算「改善幅度」、「值範圍」、「超越基準的機率」和「成為最佳變化版本的機率」。視要評估的指標而定，此欄可能會標示為「每位使用者的持續時間」、「每位使用者收益」、「回訪率」或「轉換率」。
實驗執行一段時間後 (FCM 和應用程式內通訊至少 7 天，遠端設定則是至少 14 天)，本頁的資料會指出哪個變化版本 (如有) 為「領導者」。部分測量結果會提供長條圖，以圖表呈現資料。

對所有使用者推出實驗

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

在「Firebase 主控台」導覽選單的「Engage」區段中，按一下「A/B Testing」。
按一下「Completed」(已完成) 或「Running」(執行中)，點選要向所有使用者發布的實驗，請按一下內容選單 ()「推出變化版本」。
採取下列任一做法，向所有使用者推出實驗：
- 如果實驗使用通知編輯器，請使用「推出訊息」對話方塊，將訊息傳送給未參與實驗的其餘目標使用者。
- 在「遠端設定」實驗中，請選取變化版本，以決定要更新哪些遠端設定參數值。將建立實驗時定義的指定條件新增為範本中的新條件，確保推出作業只會影響實驗指定的使用者。按一下「Review in Remote Config」查看變更後，按一下「Publish changes」即可完成推出作業。
- 進行應用程式內通訊實驗時，請使用對話方塊來判斷哪個變化版本需要以獨立的應用程式內通訊廣告活動的形式推出。選取後，系統會將您重新導向至 FIAM 撰寫畫面，以便在發布前進行任何變更。

展開實驗

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

在「Firebase 主控台」導覽選單的「Engage」區段中，按一下「A/B Testing」。
選取要編輯的進行中實驗。
在「實驗總覽」中，按一下內容選單 ()，然後按一下「編輯執行中的實驗」。
「指定目標」對話方塊會顯示選項，讓您提高執行中實驗的使用者百分比。選取大於目前百分比的數字，然後按一下「Publish」。該實驗將推送至您指定的使用者百分比。

複製或停止實驗

在「Firebase 主控台」導覽選單的「Engage」區段中，按一下「A/B Testing」。
按一下「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 在您的應用程式中未遇到錯誤的使用者百分比。
預估廣告收益	預估廣告收益。
預估總收益	購買與預估廣告收益的加總值。
購買收益	所有 `purchase` 和 `in_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 (分析) 事件。詳情請參閱「自動收集的事件」一文。