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

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

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

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

建立實驗

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

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

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

2. 在 Firebase 控制台中，使用下列任一選項啟動 Firebase In-App Messaging 實驗：

   • 來自 A/B Testing：

     1. 依序前往「DevOps 和參與度」> 「A/B 測試」

     2. 按一下「Create experiment」(建立實驗)，系統提示您選取要實驗的服務時，請選取「In-App Messaging」(應用程式內訊息)。

   • 來自 In-App Messaging：

     1. 依序前往「DevOps & Engagement」> 「Messaging」。

     2. 按一下 In-App Messaging，然後點選「新增實驗」。

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

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

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

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

6. 在「Variants」(變化版本) 部分，使用一般應用程式內訊息廣告活動的訊息設計介面，設定要傳送給基準群組的基準應用程式內訊息。

7. 如要為實驗新增變化版本，請按一下「Add Variant」(新增變化版本)。根據預設，實驗會包含一個基準和一個變化版本。

8. (選用) 為每個變化版本輸入更具描述性的名稱。

9. (選用) 按一下「Variants」(變化版本) 區段頂端的「Compare variants」(比較變化版本) 按鈕，即可並排比較一或多個訊息變化版本與基準訊息。

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

11. 設定實驗時間表：

    • 設定實驗的開始和結束日期。
    • 設定所有變化版本的應用程式內訊息觸發方式。

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

每項專案最多可建立 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

   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

   網頁

         import { getInstallations, getToken } from "firebase/installations";
   
         const installations = getInstallations(app);
         const installationAuthToken = getToken(installations);
     

2. 在 Firebase 控制台中，依序前往「DevOps & Engagement」> 「A/B Testing」。
3. 按一下「草稿」 (和/或遠端設定實驗的「執行中」)，將滑鼠游標懸停在實驗上，按一下內容選單 (more_vert)，然後按一下「管理測試裝置」。
4. 輸入測試裝置的安裝驗證權杖，並選擇要傳送至該測試裝置的實驗變化版本。
5. 執行應用程式，並確認測試裝置收到所選變化版本。

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

管理實驗

無論您是使用 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」(執行中)，然後點選要向所有使用者發布的實驗，再依序按一下「Context menu」(內容選單) more_vert「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」(內容選單) more_vert，然後點選「Edit running experiment」(編輯執行中的實驗)。
4. 「Targeting」(指定目標) 對話方塊會顯示一個選項，可提高參與實驗的使用者百分比。請選取大於目前百分比的數字，然後按一下「發布」。實驗會推送給指定百分比的使用者。

複製或停止實驗

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

指定使用者

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

指定條件	運算子	值	注意事項
版本	包含、 不包含、 完全符合、 包含規則運算式	輸入一或多個要納入實驗的應用程式版本值。	使用「包含」、「不包含」或「完全符合」運算子時，您可以提供以半形逗號分隔的值清單。 使用「包含規則運算式」運算子時，您可以建立 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 事件，用於計算應用程式中的使用者工作階段。詳情請參閱「自動收集的事件」。