當你接觸使用者或推出新的行銷廣告活動時 請務必確認一切正確無誤A/B 測試 測試訊息變化版本,找出最理想的用詞與呈現方式 指定的目標對像人數您的目標是否有助於提升留存率 或就建立產品的轉換,A/B 測試 可以進行統計分析 判斷某個訊息變化版本的成效是否優於基準 選取的目標
如要針對基準測試 A/B 版本測試功能變化版本,請按照下列步驟操作:
- 建立實驗。
- 在測試裝置上驗證實驗。
- 管理實驗。
建立實驗
您可以使用Firebase In-App Messaging評估實驗的多個變化版本 一則應用程式內通訊訊息。
登入 Firebase 控制台 並確認專案已啟用 Google Analytics 這項實驗可存取 Analytics 資料。
如果在建立專案時未啟用 Google Analytics, 可以透過整合服務啟用這項功能 分頁,你可以透過 存取 > 專案設定中的Firebase控制台。
在 Firebase 控制台導覽選單的「互動」部分,按一下 A/B Testing。
按一下「建立實驗」,然後選取「應用程式內通訊」 出現您想要實驗的服務時。
或者,在 Firebase 控制台的導覽選單中展開 「互動」,然後按一下「In-App Messaging」。然後按一下「新增」 實驗。
輸入實驗的名稱和選填說明,然後 點選「下一步」。
填寫「指定目標」欄位,請先選擇使用 進行實驗。您也可以指定一部分的使用者參與測試 選擇包含下列項目的選項:
- 版本:應用程式的一或多個版本
- 使用者目標對象: Analytics 目標對象,用於指定使用者 哪些使用者所屬的實驗
- 使用者屬性:一或多個 Analytics 使用者屬性 選取要納入實驗的使用者
- 國家/地區:要選取的一或多個國家/地區 有可能納入實驗的使用者
- 裝置語言:選取的一或多種語言和語言代碼 有可能納入實驗的使用者
- 初次開啟:根據初次開啟的使用者指定使用者 開啟這個應用程式
- 與應用程式上次互動的時間:根據上次使用時間指定使用者 使用者與您的應用程式互動
設定「目標使用者百分比」:選取應用程式的百分比 使用者數量必須符合「目標使用者」下方設定的條件 平均分配基準和一或多個變化版本 實驗。這可以是 0.01% 到 100% 之間的任何百分比。 系統會在每個實驗中隨機重新分配百分比給使用者。 (包括重複的實驗)。
在「變化版本」部分中,設定要傳送的應用程式內基準訊息 透過訊息設計介面加入基準群組 您用於一般的應用程式內通訊廣告活動
如要在實驗中加入變化版本,請按一下「新增」 子類:根據預設,實驗會有一個基準和一個變化版本。
(選用) 為每個子類輸入較一目瞭然的名稱。
(選用) 按一下「變化版本」變化版本頂端的「比較」 變化版本按鈕,可用來並排比較另外一個訊息變化版本與 基準訊息。
為評估實驗時要使用的實驗目標指標 變化版本,以及您想從清單中使用的其他指標。 包括內建目標 (參與度、購買、 收益和回訪率等)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"); } } });
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") } }
- 在 Firebase 控制台的導覽列中,按一下 A/B 測試。
- 按一下「草稿」,和/或遠端點選「執行」。 設定實驗),請將滑鼠遊標懸停在實驗上,然後按一下內容選單 (more_vert),然後按一下 管理測試裝置。
- 輸入測試裝置的安裝驗證權杖,然後選擇 要傳送到該測試裝置的變化版本
- 執行應用程式,並確認系統是透過 測試裝置。
如要進一步瞭解 Firebase 安裝作業,請參閱 管理 Firebase 安裝項目。
管理實驗
您是否使用「Remote Config」、「通知編輯器」或 Firebase In-App Messaging,您就可以驗證並開始實驗 讓參與測試的人數 以及執行中的實驗
實驗完成後,您可以記下 勝出版本,然後將這些設定發布給所有使用者。或者,您也可以 然後執行其他實驗
開始實驗
- 在 Firebase 控制台導覽選單的「互動」部分,按一下 A/B Testing。
- 按一下「草稿」,然後點選實驗標題。
- 驗證應用程式是否有使用者將 實驗,展開草稿詳細資料並查看數字 「指定目標與分配」部分中的「指定目標」大於「0%」 (例如:1% 符合條件的使用者)。
- 如要變更實驗,請按一下「編輯」。
- 如要開始實驗,請按一下「開始實驗」。最多可執行 24 個 一次執行每項專案
監控實驗
實驗執行一段時間後,您可以查看 看看你的成果會如何吸引已參與的使用者 實驗人數
- 在 Firebase 控制台導覽選單的「互動」部分,按一下 A/B Testing。
按一下「執行中」,然後點選或搜尋 進行實驗。這個頁面會顯示已觀察到和模擬的各種資訊 有關執行中實驗的統計資料,包括:
- 與基準相比的差異百分比:衡量指標的改善幅度 特定變化版本與基準相比的結果計算方式是比較 變化版本的值範圍和基準的值範圍。
- 超過基準的機率:特定指定字詞的預估機率 變化版本的成效高於所選指標的基準。
- 每位使用者 observed_metric:根據實驗結果, 這個預測範圍就是指標值 讓應用程式從可以最快做出回應的位置 回應使用者要求
- observed_metric總數:觀察到的累計值 基準或變化版本這個值可用來評估各項 實驗變化版本的成效,並用於計算「改善」、 數值範圍、超越基準的機率和可能性 是最佳子類。視要評估的指標而定 標題為「每位使用者的持續時間」「每位使用者的收益」 「回訪率」或「轉換率」
實驗執行一段時間後 (針對「FCM」執行至少 7 天) 和 In-App Messaging 或 14 天 (Remote Config),本頁面中的資料 會指出哪個變化版本 (如有) 為「勝出版本」。有些測量值是 並附上長條圖,以視覺化方式呈現資料。
對所有使用者推出實驗
如果實驗執行時間夠長,並能產生一個「領先者」或勝出 您可針對目標指標,向所有使用者發布實驗。 方便您選取要向日後所有使用者發布的變化版本。平均 如果實驗沒有產生明確的勝出組合,您仍然可以 您可以選擇對所有使用者發布變化版本
- 在 Firebase 控制台導覽選單的「互動」部分,按一下 A/B Testing。
- 按一下「已完成」或「執行中」,點選所需實驗 請按一下內容選單 ( )。 推出變化版本。
採取下列任一做法,向所有使用者推出實驗:
- 如果是使用通知編輯器的實驗,請使用 「推出訊息」對話方塊,用於將訊息傳送至其餘目標 未參與實驗的使用者。
- 在「Remote Config」實驗中,選取變化版本以決定 要更新的 Remote Config 參數值。定義的指定條件 這些實驗馬上成為 範本,確保推出作業只會影響 進行實驗。點選「查看遠端設定」後,即可查看 變更時,請按一下 [發布變更] 完成推出作業。
- 在 In-App Messaging 實驗中,請使用對話方塊決定 變化版本必須以獨立 In-App Messaging 廣告活動的形式推出。 選取後,系統會將您重新導向至 FIAM 撰寫畫面,藉此建立 變更進行發布。
展開實驗
如果您發現實驗無法為「A/B Testing」帶來足夠的使用者 您可以擴大實驗的分配範圍, 將更多比例的應用程式使用者
- 在 Firebase 控制台導覽選單的「互動」部分,按一下 A/B Testing。
- 選取要編輯的進行中實驗。
- 在「實驗總覽」中,按一下 內容選單 ( ),然後 按一下「編輯執行中的實驗」。
- 「指定目標」對話方塊會顯示選項,讓您提高 參與實驗的使用者。請選取較大的數字 然後按一下「發布」實驗將會是 就會向指定百分比的使用者發布
複製或停止實驗
- 在 Firebase 控制台導覽選單的「互動」部分,按一下 A/B Testing。
- 按一下「已完成」或「執行中」,將指標懸停在實驗上。 按一下內容選單 ( ) 和 然後按一下「複製實驗」或「停止實驗」。
指定使用者
您可以指定要納入 使用下列使用者指定條件來進行實驗。
指定條件 | 運算子 | 值 | 注意事項 |
---|---|---|---|
版本 | 包含
不包含 完全符合, 包含規則運算式 |
輸入您要加入一或多個應用程式版本的值 進行實驗。 |
使用任一「包含」、「不包含」或「不適用」時, 「完全符合」運算子,您可以提供以半形逗號分隔的清單 輕鬆分配獎金 使用「包含規則運算式」運算子時,您可以建立一般 RE2 中的運算式 格式。規則運算式可與目標版本的所有或部分目標版本相符 字串。您也可以使用 ^ 和 $ 錨點,與 目標字串的開頭、結尾或完整內容。 |
使用者目標對象 | 包括所有
包含至少一個 不包含所有 不包含至少一個 |
選取一或多個Analytics目標對象來指定可能的使用者 已納入實驗範圍 | 有些指定 Google Analytics 目標對象的實驗可能需要執行 系統需要幾天的時間才會累積資料,因為資料受Analytics約束 資料處理延遲時間。 新使用者很有可能遇到這個延遲 通常會在建立目標對象後 24 到 48 小時,加入符合資格的目標對象。 的 最近建立的目標對象。 |
使用者屬性 | 文字:
包含 不包含 完全符合 包含規則運算式 電話號碼: <、≤、=、≥、> |
Analytics 使用者屬性用於選取可納入的使用者
在你的實驗中,透過多種選項選取使用者屬性
輕鬆分配獎金
在用戶端中,您只能為使用者設定字串值 資源。如果是使用數字運算子的條件, Remote Config 服務會將對應的值 將使用者屬性轉換為整數/浮點值 |
使用「包含規則運算式」運算子時,您可以建立一般 RE2 中的運算式 格式。規則運算式可與目標版本的所有或部分目標版本相符 字串。您也可以使用 ^ 和 $ 錨點,與 目標字串的開頭、結尾或完整內容。 |
國家/地區 | 不適用 | 使用一或多個國家/地區,由系統挑選並納入特定使用者 | |
語言 | 不適用 | 由系統挑選的使用者,他們會使用一或多個語言和語言代碼 | |
初次開啟 |
超過
小於 介於 |
根據首次接觸的使用者 以天為單位指定開啟應用程式的方式 | |
與應用程式的最近一次互動 |
超過
小於 介於 |
根據最近一次與應用程式互動的時間來指定使用者 以天為單位。 |
A/B Testing 項指標
建立實驗時,您必須選擇主要或「目標」指標,也就是 以便決定勝出的變化版本你應該追蹤其他指標 可協助您進一步瞭解每個實驗變化版本的成效並追蹤 各變化版本的重要趨勢可能不同,例如使用者留存率、應用程式 穩定性和應用程式內購收益您最多可以追蹤 5 個非目標 實驗指標
舉例來說,假設您在應用程式中加入了新的應用程式內購項目 比較不同「自動提醒」訊息。在這個範例中 可能決定將「購買收益」設為目標指標。 因為您希望勝出的變化版本代表 是應用程式內購收益最高的國家/地區因為您也需要 追蹤哪個變化版本可帶來日後轉換量和留存使用者, 可能會在「其他要追蹤的指標」中新增下列內容:- 預估總收益,查看您應用程式內購和廣告的總和 兩個變化版本的收益差異
- 保留 (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_receive」 | 在以下情況傳送通知時觸發的 Analytics 事件: 在應用程式於背景運作時接收通知編輯器 (僅限 Android)。 |
os_update | 追蹤裝置作業系統的 Analytics 事件 更新為新版本。詳情請參閱 收集的事件 |
screen_view | Analytics 事件,用於追蹤使用者在應用程式中瀏覽的畫面。學習 詳細資訊,請參閱追蹤 畫面瀏覽: |
session_start | 用於計算應用程式內使用者工作階段的 Analytics 事件。如要瞭解詳情 查看「自動 收集的事件 |