app 裏的 A/B 測試簡介

時間 2019-11-21

標籤 app 測試簡介简体版

原文原文鏈接

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 測試在被測人不知情的真實場景中測試，其得出的結果纔是最有效的。html

要構建每一個版本的表明性樣本羣體，A/B 測試平臺須要隨機地讓用戶使用版本 A 或版本 B，或者將其排除在測試以外。而後確保用戶在整個測試中保持一致的 A/B 體驗（老是 A 或老是 B），並向分析平臺提供額外的元數據以肯定指標的影響。一旦指標分析完成，表現最佳的版本將會被選中，您可使用 A/B 測試平臺逐步向全部用戶推出獲勝版本。前端

例如，你能夠假設在你的 app 中底部導航的用戶參與度將超過標籤。您能夠設計一個 A/B 測試比較標籤（版本 A）和底部導航（版本 B）。而後，你的 A/B 測試平臺將生成一個樣本，該樣本基於用戶隨機分配到版本 A 或版本 B。而且每一個用戶在測試期間會持續看到相同的版本。當測試結束時，能夠將版本 A 用戶參與度與版本 B 的用戶參與度進行比較，看看版本 B 是否具備統計顯着性的改進。若是版本 B 更好，這就有數據支持你把導航風格改成底部導航，並讓全部用戶看到這一版本。android

左邊 —— 版本 A，標籤；右邊 —— 版本 B，底部導航ios

關於 Google Play 控制檯中商品詳情實驗的說明

Google Play 控制檯還支持在你的商品詳情中進行 A/B 測試，本文不會重點關注這一部分。商品詳情實驗，讓你在商品詳情中測試不一樣的圖標，功能圖，促銷視頻，簡短描述和詳細描述，看看這些變化是否能夠增長應用的安裝。商品詳情實驗側重於提升轉化次數，而個人文章的其他部分討論了應用內的 A/B 測試，旨在改善用戶存留率，用戶參與度和應用內購買收入等安裝後的指標。git

在個人文章中，我將介紹 app 裏 A/B 測試的五個關鍵步驟：github

創建假設
整合 A/B 測試平臺
測試假設
分析並得出結論
採起行動

而後，我還會涉及更多能夠探索的高級技巧。後端

第一步，創建假設

假設是根據一種現象提供相應的解釋，而 A/B 測試是一種肯定假設是否爲真的方法。這個假設多是經過檢查現有的數據而產生的，也可能猜想的成分多一點，或者僅僅只是一種「預測」。（對於新功能所涉及到的新指標，假設經常是基於「預測」。）在導航的例子中，能夠用這種方式來表達假設：「採用底部導航會較標籤增長用戶的參與度「。而後，若是你的 app 有對導航風格進行了更改，以及該更改對用戶參與度的有影響，你能夠根據這個假設來進行相應決策。重要一點的是要記住，測試的惟一目的是證實底部導航對每一個用戶的平均收入（或者 ARPU）有着直接，積極的影響。服務器

要測試什麼（A 是什麼？B 又是什麼？）

下面的表格列出了大部分的情景，能夠幫助你肯定要如何選擇測試的版本。以咱們假設的導航實驗爲例。app

「排除測試」這一列表示不參與測試的用戶。他們的行爲將不會有助於測試結果。咱們看看誰是測試用戶。工具

咱們根據假設想要度量什麼來選擇情景 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。