為使每個版本的樣本群體具有代表性，A/B 測試平臺隨機讓用戶使用版本 A 或版本 B，或者將其排除在測試之外。測試平臺須要確保用戶在整個測試周期中體驗一致 (總是 A 或總是 B)，并向分析平臺提供額外元數據以確定對指標的影響。一旦完成指標分析并確定最佳版本，您可以通過 A/B 測試平臺向所有用戶逐步推廣獲勝版本。

譬如，您建立假設 “與應用中的標簽相比， 底部導航能更好地提高用戶參與度”。為此，您可以設計一個 A/B 測試來比較標簽 (版本 A) 和底部導航 (版本 B)。接著，測試平臺會生成一個用戶基礎樣本，并將樣本內用戶隨機分配使用版本 A 或版本 B， 同時保證每位用戶在測試期間將一直使用被分配到的版本。在測試結束時，您可比較兩個版本的用戶參與度，觀察版本 B 的參與度是否顯著高于版本 A。若版本 B 的數值更高，這說明數據支持您選用底部導航設計，并向所有用戶推廣這一版本。

△ 左邊?: ?版本 A, 標簽；右邊?: ?版本 B, 底部導航

關于 Google Play 管理中心中商店資訊實驗的說明

Google Play 管理中心還支持對應用的商店資訊進行 A/B 測試，本文對此不加贅述。商店資訊實驗能讓您測試不同的圖標、功能圖、推廣視頻、簡短描述和詳細描述，觀察應用的安裝量是否隨之增加。商店資訊實驗側重提高用戶轉換率，而本文的余下部分則著重討論應用內 A/B 測試對安裝后指標的影響，如用戶存留率，用戶參與度和應用內購買營收。

在這篇文章中，我將介紹應用內 A/B 測試的五個關鍵步驟：

1. 建立假設

2. 整合 A/B 測試平臺

3. 測試假設

4. 分析并得出結論

5. 采取措施

此外，本文還會稍微談一下您可能會用到的高級技巧。

Step 1 – 建立假設

要測試什么 (A 是什么？B 又是什么？等等)

下面的表格列舉了大致場景，可以幫助您如何決定選擇測試版本。以我們假設的導航實驗為例：

△ “從測試中排除” 這一列表示不參與測試的用戶；他們的行為不計于測試結果。詳情請參照下文 “測試誰“ 板塊。

根據假設測量指標的不同，可選擇場景 2 或場景 3。如果測量指標僅與新功能相關，請選擇場景 2 (例如，若新功能是應用內購買，那么只有新功能實現后，“應用內購買營收”這項指標才有意義)。如果假設涉及的測量項，在添加新功能之前，也具有意義，請選擇場景 3 (例如，若新功能是 “最愛” 機制，而測量項是用戶參與度)。

注意： 在下文到 “采取行動” 部分前，為簡潔起見，我將使用情景 1 為例。 相同的方法亦適用于情景 2 和情景 3，并且我會以 “現有版本” 和 “新版本” 代替 “新 1 版本” 和 “新 2 版本”。

測試誰？

若被觀察行為受到假設以外的某些因素影響 (如，已知行為根據國家不同而發生變化，而假設僅僅考慮全球收入影響)，請將該因素設定為唯一值 (單一國家) 或者使用全體人口 (所有國家) 的代表性樣本。

具有代表性的控制樣本大小也可設定為總人口的百分比。例如，測試樣本為總人口的 10% —— 版本 A 和版本 B 各占 5% —— 剩余 90% 人口則排除在測試外。即是說，這 90% 的人或使用現有功能，或完全看不到任何新功能，且他們的行為不被計入測試指標內。

測試多久？

最長時間：用戶的行為通常會隨著時間發生變化，一天中的某個時段，一周中的某一天，某個月，某個季節等等。為了體現這些差異，您會想要在統計意義和業務需求之間找到某種平衡 (您的業務可能無法等到您擁有足夠的數據完成統計)。如果知道某項特定指標會在短時間內發生變化 —— 例如一天或者一周中的某一天 —— 那就嘗試讓測試涵蓋這整個時期。對于用時較長的指標，只測試幾周可能會更合適一點，然后根據已知的隨時間變化結果進行相應推斷。

最短時間：須要測試足夠長的時間，以便獲取足夠數據使得結果具有統計意義。這通常意味著受測用戶至少達到 1000 人。不過，能否取得明顯的測試結取決于從假設推導出來的指標的分布情況。那么如何在合理時間內完成測試呢？您可以通過估計有多少用戶能夠在所需的時間段內進行測試，然后從中選擇一定比例的用戶作為測試者，這樣您的測試就能在這段時間內達到統計意義。一些 A/B 測試平臺能自動管理這些操作，同時也可以提高您的測試采樣率，讓您的測試更快地達到統計意義。

Step 2 – 集成 A/B 測試平臺

目前市面上已經有幾種 A/B 測試平臺，它們或是獨立的產品，或是某更大分析平臺 (如 Firebase 遠程配置及分析) 的某一組件功能。通過客戶端庫，平臺會向應用發送一組配置指令。由于應用不知道為什么要返回某個參數，因而無法獲知這是測試的哪個部分，甚至不知道這是否屬于測試的一部分?？蛻舳藘H僅是按照配置指令進行相應配置。此外，平臺不關心返回到客戶端的參數值的意義；而是由客戶端自行解釋。在最簡單的情況下，返回的參數可以是簡單的鍵值，對于控制是否啟用給定功能，如果須要啟用，則激活對應的版本。

在更復雜的情況下，如須要進行大量的遠程應用配置，應用會將參數發送到 A/B 測試平臺，測試平臺會跟據這些參數對測試進行更為精細的調整。例如，如果假設只涉及具有 xxxhdpi 屏幕密度的設備，那么應用須要將其屏幕密度發送到 A/B 測試平臺。

不要重復工作

請選擇一個能夠滿足您 A/B 測試需求的現有平臺。請注意：平臺提供的 A/B 測試以及數據驅動型決策是習慣性的。

保持測試狀態一致，并公平分配受測用戶到多個測試并非易事。沒有必要從零開始寫代碼。

當然，每個測試版本的代碼還是必須要寫的。不過，不應該由應用或某個定制服務來決定在給定時間內使用哪個版本；而是交由 A/B 測試平臺處理，這樣就可以應用標準方法，在同一時間對同一人群進行多項測試。只有當您確定只須進行單項測試的情況下，自己動手編寫 A/B 測試機制代碼才有意義。與其花大成本寫兩個測試的代碼，不如集成一個現有的 A/B 測試平臺。

整合分析工具

所以說您可以將受測群體進行自動分組，挑選一個可以直接向您現有分析平臺提供詳細測試狀態信息的分析平臺。能否緊密將兩個平臺整合在一起，取決于每個測試的具體配置以及直接在 A/B 測試平臺和分析平臺之間傳遞的版本。A/B 測試平臺會為每個版本分配一個全局唯一引用，并將其傳遞給客戶端和分析平臺。在這種情況下，客戶端只須要將該引用而不是整個版本的配置傳遞給分析平臺。

遠程配置

若應用具備遠程配置功能，那么它本身就已經擁有實現 A/B 測試所需的大部分代碼?；旧?，A/B 測試添加了一些服務器端規則來確定向應用發送何種配置。若應用不具備遠程配置功能，那么 A/B 測試平臺是引入這一功能的好方法。

Step 3 – 驗證假設

監控測試

我建議在測試過程中監控新版本所造成的影響，包括那些在假設中未被提及的指標。如果您發現負面影響，可能需要提早停止測試，讓用戶盡早恢復到之前的版本——最小化不良用戶體驗。某些 A/B 測試平臺能提供監控功能，并在測試遇到意外負面影響時發出自動警告。否則，您須要對之前監控系統監測到的影響和現有測試進行交叉對照，以識別“不良”版本。

注意： 如果須要提早停止測試，那您應該謹慎處理收集到的數據，因為無法確保測試群體樣本具有代表性。

Step 4 – 分析并得出結論

如果假設錯誤 —— 因為相關指標沒有正面或者負面影響 —— 那么就沒有理由繼續保留這一版本了。不過有些情況下，新版本可能會對一個相關但意料之外的指標產生積極影響。這或許是支持新版本的正當理由，但是一般來說還是針對該指標重新設計一個測試更好一點。實際上，一個實驗的結果往往會產生額外的問題和假設。

Step 5 – 采取行動

漸增發布

A/B 測試平臺的常見用例之一就是轉變自身角色成為漸增發布機制，將測試的獲勝版本逐漸推廣到所有用戶，以取代舊版本?？梢园阉斪?A/B 設計測試，而漸增發布則是一種 Vcurr／Vnext 測試，用以確認所選的版本不會對更多用戶造成負面影響?？梢酝ㄟ^逐步提高接收新版本的用戶百分比 (例如，從 0.01％提高到 0.1％，1％，3％，7.5％，25％，50％，100％) 來進行漸增發布，并觀察在進入下一步之前是否有不利的結果。同時你還可以用其他方式進行分類，包括國家，設備類型，用戶組等。你還可以選擇僅向特定用戶群體 (如內部用戶) 發布新版本。

深度分組和定位

A/B 測試結果可用于分析不同分組間的差異，也可用于確定目標方法論。在這兩種情況下，可能須要提高采樣率或延長測試時間讓每個組都具有統計意義。例如，標簽 vs 底部導航假設的測試結果可能會根據國家的不同而有所不同；在另外情況下，一些國家的用戶參與度可能會大幅度增長，有些則沒有變化，有的略有下降。在這種情景下，A/B 測試平臺可以根據國家設置不同的“默認”版本，以最大限度地提高用戶總體參與度。

針對特定組可以使用同一組的數據進行測試。例如，您可以測試居住在美國的用戶和之前使用過標簽導航風格的用戶。

A/n 測試

A/n 測試是指被測版本超過兩個的測試。這可能是用幾個新版本代替某一現行版本；或者是幾個添加新功能的版本與無新功能的版本進行比較。在進行深度分組之后，您可能會發現不同的組表現最好的版本也各有不同。

多變量測試

多變量測試允許開發者在單次測試內，同時改變應用的多個項目，并根據每一組值設計出單獨測試版本用于 A/n 測試。譬如說：

若多個相關項目會共同作用影響指標整體表現，多變量測試是不錯的選擇，不過可能會無法確定影響究竟來自哪一個具體項。

擴大測試規模

若在同一人群中同時進行多項測試，那么這些測試必須由同一個平臺管理。有些平臺可以支持千項并行測試，有些平臺則只支持獨立測試 (即用戶一次只能進行一次測試)，而有些平臺則允許共享測試群 (即用戶同時進行多個測試)。前一種情況更易管理，但會迅速用完測試用戶，并達到具有統計價值的并行測試數量上限。后一種情況會增加 A/B 測試平臺管理難度，但是不存在并行測試數量上限，因為平臺把每一個測試當作另一個測試的附加組。

自我選擇

自我選擇讓用戶獲知自己正在使用某一特定測試版本。用戶可以自行選擇使用版本，或者讓 A/B 測試平臺隨機給他們分配。無論哪種情況，這些用戶數據都不可用于指標分析，因為他們并不是在不知情的狀態下參與測試 —— 由于知道這是一個測試，因此他們的反應可能帶有偏見。

• Firebase 遠程配置 (FRC) 提供客戶端庫，允許應用向 Firebase 請求并接受配置，此外也可利用基于規則的云端機制定義用戶配置。開發者可以在不發布新版本的情況下，通過遠程配置更新 (或升級) 應用；
• Firebase 遠程配置與分析支持通過 A/B 測試決定與跟蹤版本部署；
• Firebase 分析會根據版本不同給出指標分類，并直接了解到 FRC。

請記?。?/strong>在 A/B 測試中，結果分析很重要。測試和分析雙管齊下才能為您提供洞見，改善應用未來的設計及開發，激發應用最優性能。