A/B 測試如何幫助您從 app 中獲得更多收益
- 原文地址：An introduction to in-app A/B testing: How A/B testing can help you get more out of your app
- 原文作者：Gavin Kinghall Were
- 譯文出自：掘金翻譯計劃
- 本文永久連結：github.com/xitu/gold-m…
- 譯者：mnikn
- 校對者：swants, winry01
A/B 測試是一種對照實驗方法，用來根據假設比較兩個及以上版本之間的差別，其假設可以被證實或推翻。該測試會根據原有版本派生出特定的測試版本，以此來產生可靠的結果。當 A/B 測試在被測人不知情的真實場景中測試，其得出的結果才是最有效的。
要構建每個版本的代表性樣本群體，A/B 測試平臺需要隨機地讓使用者使用版本 A 或版本 B，或者將其排除在測試之外。然後確保使用者在整個測試中保持一致的 A/B 體驗（總是 A 或總是 B），並向分析平臺提供額外的後設資料以確定指標的影響。一旦指標分析完成，表現最佳的版本將會被選中，您可以使用 A/B 測試平臺逐步向所有使用者推出獲勝版本。
例如，你可以假設在你的 app 中 底部導航 的使用者參與度將超過 標籤。您可以設計一個 A/B 測試比較標籤（版本 A）和底部導航（版本 B）。 然後，你的 A/B 測試平臺將生成一個樣本，該樣本基於使用者隨機分配到版本 A 或版本 B。並且每個使用者在測試期間會持續看到相同的版本。當測試結束時，可以將版本 A 使用者參與度與版本 B 的使用者參與度進行比較，看看版本 B 是否具有統計顯著性 的改進。如果版本 B 更好，這就有資料支援你把導航風格改為底部導航，並讓所有使用者看到這一版本。
左邊 —— 版本 A，標籤；右邊 —— 版本 B，底部導航
關於 Google Play 控制檯中商品詳情實驗的說明
Google Play 控制檯還支援在你的商品詳情中進行 A/B 測試，本文不會重點關注這一部分。商品詳情實驗，讓你在商品詳情中測試不同的圖示，功能圖，促銷視訊，簡短描述和詳細描述，看看這些變化是否可以增加應用的安裝。 商品詳情實驗側重於提高轉化次數，而我的文章的其餘部分討論了應用內的 A/B 測試，旨在改善使用者存留率，使用者參與度和應用內購買收入等安裝後的指標。
在我的文章中，我將介紹 app 裡 A/B 測試的五個關鍵步驟：
- 建立假設
- 整合 A/B 測試平臺
- 測試假設
- 分析並得出結論
- 採取行動
然後，我還會涉及更多可以探索的高階技巧。
第一步，建立假設
假設是根據一種現象提供相應的解釋，而 A/B 測試是一種確定假設是否為真的方法。這個假設可能是通過檢查現有的資料而產生的，也可能猜測的成分多一點，或者僅僅只是一種“預測”。（對於新功能所涉及到的新指標，假設常常是基於“預測”。）在導航的例子中，可以用這種方式來表達假設：“採用底部導航會較標籤增加使用者的參與度“。然後，如果你的 app 有對導航風格進行了更改，以及該更改對使用者參與度的有影響，你可以根據這個假設來進行相應決策。重要一點的是要記住，測試的唯一目的是證明底部導航對每個使用者的平均收入（或者 ARPU）有著直接，積極的影響。
要測試什麼（A 是什麼？B 又是什麼？）
下面的表格列出了大部分的情景，可以幫助你確定要如何選擇測試的版本。以我們假設的導航實驗為例。
“排除測試”這一列表示不參與測試的使用者。他們的行為將不會有助於測試結果。我們看看誰是測試使用者。
我們根據假設想要度量什麼來選擇情景 2 或者情景 3。如果僅與新功能有關（例如，如果新功能是需要 app 內購，則這個功能僅和 app 內購買收入相關），那麼選擇情景 2。如果假設要實現的新功能（例如，如果新功能是“最愛”機制，並且度量指標是使用者參與度）與之前的東西（並且是可測量的）相關，則選擇情景 3。
注意： 在接下來的部分中，為了簡潔起見，我將使用情景 1。 同樣的方法同樣適用於情景 2 和情景 3，以“現有”和“新”版本這些稱號代替“新 1”和“新 2”版本。
誰來測試
如果已知觀察到的行為會因為假設外的某個因素髮生變化 —— 例如，當假設僅考慮全球收入的影響時，已知行為會因居住國而異 —— 需要讓該因素（單一國家）的值唯一，或者使用全體人口（所有國家）的代表性樣本。
受控的代表性樣本的大小也可以設定為總人口的百分比。例如，測試樣本大小是總人口的 10％，其中 5％ 收到版本 A，5％ 收到版本 B，其餘 90％ 排除在測試之外。也就是 90％ 的使用者只會看到現有的功能，並不會看到任何新功能，他們的行為被排除在測試指標之外。
要測試多久
最長時間： 使用者的行為通常會隨著時間，這周的第幾天，月份，季節等類似因素而變化。為了讓版本之間體現出足夠的差異，您需要平衡統計顯著性和業務的需求。（您的業務可能無法等到你有足夠的資料可以完整的統計。）如果知道某個特定指標會在較短的時間段內發生變化，例如一天中的某個時間或一週中的某一天 —— 那麼就嘗試讓測試涵蓋這一整個時期。對於需要較長的時間段的指標，只測試幾周可能會更好一點，並要根據度量標準隨時間的變化進行相應地推測。
最短時間： 測試執行的時間要足夠長，來獲取足夠的資料從而能夠提供具備統計意義的結果。通常對應的測試人數是 1,000 個使用者（至少）。但是，能否得到明顯的結果取決於從假設推匯出來的指標分佈。你可以通過估計有多少使用者能夠在所需的時間段內進行測試，從而在合理的時間內完成此操作，然後選擇估計使用者數量的百分比，以便讓你的測試在這個時間段內達到統計顯著性。一些 A/B 測試平臺能自動管理這些操作，同時也可以提高你的測試取樣率，讓你的測試更快地達到統計顯著性。
第 2 步，整合 A/B 測試平臺
已經有幾種 A/B 測試平臺，既可以作為一個獨立產品進行測試，也可以作為一個更大分析平臺的元件，例如 Firebase 遠端配置分析。通過客戶端庫，平臺會向 app 傳送一組配置指令。app 不知道為什麼要返回某個引數，因此不知道它在測試哪一部分，甚至不知道是否這是測試的一部分。客戶端應該按照配置指令自己進行相應配置，由客戶端來解釋其中的價值。 在最簡單的情況下，返回的引數可以是簡單的鍵值對，用於控制是否啟用給定功能，如果是，則啟用對應的版本。
在更復雜的情況下，如果需要進行大量的遠端 app 配置，app 會將引數傳送到 A/B 測試平臺，測試平臺會跟據這些引數來選出更精細的測試配置。例如，如果假設只涉及具有 xxxhdpi 螢幕密度的裝置，那麼 app 將需要將其螢幕密度傳送到 A/B 測試平臺。
不要重複發明輪子
直接從現有平臺中選擇一個可以滿足 A/B 測試需求的。注意：需要養成相應習慣來做到 A/B 測試和資料驅動決策。
注意： 管理許多使用者，讓其保持一致的測試狀態，並公平地分配測試參與者很難。沒有必要從頭開始寫。
當然，你要為每個要測試的版本寫程式碼。但是，不應該由 app 或某個定製服務來決定在給定時間內使用哪個版本。這要交給 A/B 測試平臺來處理，應用這種標準方法，可以在集中管理同一時間內同一人群的多個測試。當你在平臺上只執行一個測試時，親自實現一個簡單的 A/B 測試機制才有意義。 對於硬編碼兩個測試的成本，您可以整合一個現成的 A/B 測試平臺。和寫兩個硬編碼測試的成本相比，不如把這些測試整合進一個現成的 A/B 測試平臺。
整合分析功能
選一個可以提供詳細的測試狀態資訊的現有分析平臺，可以自動幫你可以把測試人群進行分類。要緊密地把這兩個平臺整合在一起，取決於每個測試的具體配置，和要直接在 A/B 測試平臺和分析平臺之間傳遞的版本。A/B 測試平臺會為每個版本分配一個唯一的引用，並將其傳遞給客戶端和分析平臺。然後，只允許客戶端把該引用而不是整個版本的配置傳遞給分析平臺。
遠端配置
一個具有遠端配置功能的 app，已經有了實現 A/B 測試時所需的大部分程式碼。實質上，A/B 測試新增了一些伺服器端的規則用來確定什麼配置傳送到 app。 對於沒有遠端配置功能的 app，那麼引入 A/B 測試平臺是讓你引入這一功能的其中一個好方法。
第 3 步，測試假設
一旦確定好你的假設和設計好測試，而且也整合了 A/B 測試平臺，實現你的測試版本就是一個最簡單的操作了。下一步，開始你的測試。A/B測試平臺將一組樣本使用者分配在測試群體上，然後給每個測試使用者分配版本。然後平臺繼續在理想時間段內的分配使用者。對於更高階的平臺，平臺會一直執行測試，直至達到統計顯著性。
監控測試
我建議在測試過程中監控新版本所造成的影響，包括測試假設中未提及的指標。如果你發現它會造成不良的影響，那麼可能要儘早停止測試，儘可能快地讓使用者恢復到之前的版本 —— 最大限度地減少糟糕的使用者體驗。一些 A/B 測試平臺能夠自動監控並會提醒測試可能會有意想不到的負面影響。如果你的平臺不能做到這一點，你需要把現有的監控系統中看到的任何影響和目前的測試相互參考，來識別“不良”版本。
注意： 如果測試確實需要提前停止，那麼你應該要對收集到的資料謹慎處理，因為它不能保證測試群體樣本具有代表性。
第 4 步，分析並得出結論
一旦測試正常結束，你就可以用在分析平臺中收集到的資料確定測試的結果。如果結果指標和假設相符，那麼你可以認為這個假設是正確的。否則，你猜錯了。確定觀察結果是否具有 統計顯著性 取決於指標的性質和分佈。
如果假設錯誤 —— 因為相關指標沒有正面或者負面影響 —— 那麼就沒有理由繼續保留這一版本了。然而，新的版本可能會對相關但意想不到的指標產生積極的影響。這可能是一個選擇新版本的理由，但通常來說執行一個專門針對輔助指標的附加測試來確認其影響會更好一點。實際上，一個實驗的結果經常會引起額外的問題和假設。
第 5 步，採取行動
如果假設是真的，並且新的版本比舊的好，那麼我們可以更新要傳遞給 app 的“預設”配置引數，指示它使用新的版本。一旦新的版本為成為預設後持續了足夠的時間，你就可以把舊版本的程式碼和資源從下一個版本的 app 中刪除。
迭代展示
A/B 測試平臺的一個常見用法是將其重新作為迭代展示的機制，其中 A/B 測試的獲勝版本會逐漸取代舊版本。這可以視為 A/B 設計測試，而迭代展示是 Vcurr／Vnext 測試，用來確認所選的版本不會對大部分的使用者產生不利影響。可以通過提高接收新版本的使用者百分比（例如，從 0.01％，0.1％，1％，3％，7.5％，25％，50％，100％ 開始）來迭代展示並確定在進入下一步之前沒有不利的結果。同時你還可以用其他方式進行分類，例如國家，裝置型別，使用者組等。你還可以選擇將新的版本展示給特定的使用者組（例如內部使用者）。
更進一步的實驗
例如，你可以構建一個簡單的 A/B 測試，用於更深入的理解使用者行為範圍。您還可以同時執行多個測試，並在單個測試中比較多個版本來來讓測試更高效。
深度分組和定位
A/B 測試結果可以檢測不同組結果的變化，並定位是哪個方法所造成的。在這兩種情況下，可能需要提高取樣率或測試持續時間來達到每個組的統計顯著性。例如，標籤 vs 底部導航假設 的測試結果可能會根據國家的不同有不同的影響。在某些情況下，一些國家的使用者參與度可能會大幅度增長，有些則沒有變化，有的略有下降。 在這種情景下，A/B 測試平臺可以根據國家設定不同的“預設”版本，以最大限度地提高使用者總體參與度。
可以針對特定組使用同一組的資料進行測試。例如，您可以測試居住在美國的使用者和之前使用過標籤導航風格的使用者。
A/n 測試
A/n 測試是測試兩種以上版本的簡寫。這可能是多個新的版本要取代現有的版本，如有全新功能的幾個版本要取代沒有任何新功能的版本。當你進行了深度地分組後，可能會發現不同的版本會在不同的組中表現最好。
多變數測試
一個多變數測試是一個單一的測試，它一次性改變 app 多個部分。然後，在 A/n 測試中，將唯一的一組值作為一個單獨變數處理。例如：
當多個方面可能都會影響整體指標效能時，使用多變數測試是適當的，但是無法區分該效果是由哪一特定方面帶來。
擴大測試規模
如果在同一個人群中同時執行多個測試，那麼這些測試必須由同一個平臺管理。有些平臺能夠擴充套件到支援數千個測試同時執行，有些平臺則把完全測試孤立起來（所以使用者一次只能進行一次測試），而有些平臺可以共享一個測試使用者（所以使用者同時進行多個測試）。前一種情況更容易管理，但會迅速用完測試使用者，並導致統計顯著性的上限取決於並行測試的數量。而後一種情況，A/B 測試平臺難以管理，但是並行測試的數量沒有上限。平臺通過完全把每個測試視為另一個測試的附加組來實現這一點。
自我選擇
自我選擇讓使用者知道自己正在使用特定測試中的特定版本。使用者可以自行選擇版本，或者讓 A/B 測試平臺給他們分配。無論是哪種情況，這些使用者都應該被排除在指標分析之外，因為他們不是在不知情的狀態下參與測試 —— 他們知道這是一個測試，所以他們可能會表現出一個有偏見的迴應。
結論
app 內的 A/B 測試是一個非常靈活的工具，它可以讓你對你的 app 做出由資料驅動的決策，正如我在本文中所強調的，這可以幫助你對新功能做出明智的選擇。A/B 測試允許你在真實世界中使用真實使用者測試 app 的各個方面的版本。為了簡化 app 內的 A/B 測試設計，整合，執行和分析，Google 提供了一套工具，其中包括：
- Firebase 遠端配置 （FRC）提供了一個客戶端庫，允許 app 請求 Firebase 和並接收相應配置，另外還有一個基於規則的雲端機制來定義使用者配置。遠端配置可以在而無需釋出新版本的情況下幫你更新（和升級）你的 app。
- Firebase 遠端配置與分析 支援根據 A/B 測試來決定和跟蹤版本部署。
- Firebase 分析 根據版本給出一個指標分類，並直接連線到 FRC。
你怎麼看？
對使用 A/B 測試還有任何疑問或想法嗎？可以在下面的評論中釋出討論，或者使用標籤 #AskPlayDev，我們將會在@GooglePlayDev 裡回覆，我們會定期分享有關如何在 Google 上做得更好的新聞和提示。
記住： 分析對於 A/B 測試至關重要。 A/B 測試和分析結合在一起，可以開拓你的視野，推動你的 app 之後的設計和開發，最大限度地讓其做到最好。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智慧等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。