雙十一系列解讀:天貓 App A/B 測試實踐之路

在一篇文章《動態調整的基礎 —— 配置中心》中我們聊了關于 Native App 動態化的問題。無疑 Native 的動態化能力較 Web 要弱很多,很多操作是依賴版本節奏的。這就導致在Native App上許多決策無法快速驗證,對存在不足的邏輯沒辦法快速修正。受到這些條件的限制,那個唯快不破的鐵律在 Native App 上遭遇到了尷尬。每一個產品決策會變得異常謹慎,因為一個錯誤的決策要持續整個版本周期可能被修復。慢慢的我們就會發現,不出錯會成為做出決策的重要因素,而有意義卻退居二線。

 

所以具備快速驗證和及時修正這兩個能力就顯得非常重要,打造這樣的能力需要一個完整的解決方案。我們認為,這個方案是一個以A/B測試為核心,結合周邊多個系統能力,共同組成的一個試錯平臺。在這個平臺上,我們的團隊,不管是業務方還是工程師,都可以快速應變,不畏懼出錯,變得靈動起來。

A/B測試

說到A/B測試,這到底是個什么東西?我個人的理解是:狹隘的說,A/B測試是以分桶為核心,以依據分桶結果執行不同邏輯為基本原理,以獲取最優解為目的一種測試方案。

 

一般認為,A/B測試的主要場景有兩種:對比實驗和灰度發布。


對比實驗

所謂對比實驗,就是同一時間執行兩套甚至多套方案,通過對比反饋數據,對這些方案作出評價。

灰度發布

灰度發布則是,某個新功能或版本正式發布前,先圈一部分人作為小白鼠,試用這個功能或版本。我們從穩定性,業務效果等多方面觀察這部分試用者的反應,對這個新功能或版本作出評價。

 

不管是對比實驗還是灰度發布,最終目的都是期望只是發布帶來的效果最大化。

體系

一個單一的A/B測試框架并不能幫助我們達成目的,還需要諸多周邊能力輔助。要實現豐富的分桶條件,需要設備和用戶的信息收集機制;要實現線上邏輯實時調整,要 Native 邏輯動態化方案;要實現動態調整分桶邏輯,需要分桶條件下發系統;實現觀察對比實驗結果,需要數據收集和分析平臺,等等。

 

在天貓,我們整合各方能力搭建了一個稱為 AirTrack 的試錯平臺。在 AirTrack 平臺上動態實驗條件,實時運算SDK和數據收集和反饋平臺三部分是重中之重。


動態實驗條件

在傳統的 Web A/B測試中,實驗條件的計算和分桶邏輯執行都在后端完成,具有非常好的動態性,可以隨時發布隨時生效。在 Mobile 場景下,很多時候我們慣性的延續這種思路,把這些邏輯放在后端,通過 API 吐出不同的數據來控制 App 端的不同形態。這種方式固然有很好的動態性,但一個致命問題在于,這樣的設計依賴數據 API ,只能用于數據層面的實驗。

 

我們認為數據 API 在 Mobile 場景中僅僅占一小部分,而我們要建設的是一個代碼級別的A/B測試框架,必然不能依賴數據API,而是要具備在端上完成此前后端承擔的全部工作。具體的說,就是我們需要在App端實時運算實驗條件和執行分桶邏輯。所有的邏輯都在 App 端,那么動態化的問題怎么解決?幸好我們具有成熟的基礎設施建設,可以通過配置中心實現實驗條件動態化。

 

我們把實驗條件的數據結構設計為一棵樹。根節點是運算起點,非葉子節點是一個邏輯表達式,葉子節點都是實驗條件運算的結果。

通過一段JSON描述這棵實驗條件樹,再利用配置中心的動態能力把數據動態下發到端,從而實現了實驗條件動態化。

{
“name”: “demo”,
“expired”: 1458403200,
“tree”: {
“prop”: “device.version”,
“op”: “eq”,
“val”: “9.0”,
“son”: [
{
“prop”: “device.city”,
“op”: “in”,
“val”: “杭州市,北京市,上海市”,
“son”: [
{
“per”: [
0.33,
0.33
],
“son”: [
{
“node”: 1
},
{
“node”: 2
},
{
“node”: 3
}
]
}
]
}
]
}
}

實時運算SDK

App 端的業務代碼調用 AirTrack SDK,初始化一個 AirTrack 實例,指定該實例需要進行的實驗名稱,把需要加入實驗的若干邏輯注冊到這個實例中。 AirTrack 實例在執行階段,根據實驗名稱,通過配置中心獲取實驗條件,從條件樹的根節點開始計算,最終找到一個葉子節點,通過葉子節點中攜帶的信息定位到需要執行的實驗邏輯,并執行該邏輯。從而完成整個實驗過程。


在條件樹的 Demo 中我們可以看到非葉子節點有兩種類型:

帶屬性的運算

哈希運算

 

帶屬性的運算,利用了天貓狀態中心的數據能力,通過條件節點中指定的狀態名稱獲取狀態中心中的當前屬性值,與給定值進行運算符指定的運算,當運算結果為真,則落入左子樹,假,落入右子樹。

 

哈希運算,則是使用設備 ID ,條件名稱和當前節點深度三個因素組合成一個因子,并對該因子進行0-10,000的哈希,通過哈希結果可知當前設備落入那一段區間內。根據給定的子節點和比例關系決定落入哪一棵子樹。

數據收集和反饋平臺

在天貓 App 中有一套成熟的數據采集 SDK ,數據以界面為線索被收集并同步到后端。我們對這個收集 SDK 進行一些改造,在 AirTrack SDK 中自動調用數據采集接口,把執行結果的分桶信息寫入埋點。

 

根據數據采集收集的日志,我們有一套完整的以頁面為線索的數據分析平臺。在這個平臺上我們可以看到頁面維度的全部信息,除了 PV,UV,點擊率等常規數據,該頁面的入口和出口流量,轉化率等等。

 

而我們對A/B測試數據的要求也正是這些,所以我們對數據分析平臺改造支持分桶統計,可以平行看到各個分桶的數據。

實踐配置灰度發布

之前我們說A/B測試的兩個主要場景之一是灰度發布,配置中心是一個典型場景。修改一份配置后,需要對這次變更進行灰度發布,以求安全穩定。

 

我們預先定義若干灰度方案,每一個灰度方案就是一份A/B測試的實驗條件。例如,我們有一份實驗條件是:

第一個20分鐘生效10%

第二個20分鐘生效50%

第三個20分鐘生效80%

 

通過1個小時的灰度逐步上線。在灰度過程中,我們可以在數據監控平臺上實時發現問題,隨時終止灰度進程。如果一切正常,那么這個變更就會自動全量發布。

首頁模塊對比測試

在天貓App的首頁上有很多坑位,我們會在坑位變更中,使用了對比測試方案。

 

在某次變更中,首先切20%的流量作為樣本,把樣本五五開,10%執行舊邏輯,10%執行新邏輯,在線上試運行兩天。根據反饋的數據顯示,我們對比兩個坑位的轉化率和展示效果,發現新坑位效果并沒有達到預期。所以撤回新方案,并實施改造,再次上線對比實驗,直至達到預期效果。

 

在整個決策過程中,花費了1周時間。然而這樣的決策在沒有試錯平臺的情況下,需要跨越一個甚至更多個版本。

個性化彈窗

在實施A/B測試的過程中,發現這個平臺除了處理以上的兩個場景,還可以有更多功能。甚至可以在常規業務中發揮效果。

 

大家經歷過天貓 App 首頁的紅包雨,擦霧霾等功能。這是一個獨立的彈窗系統支持的,然而這個系統并沒有很好的解決在什么條件下出現彈窗這件事。最初的方案只是分時間段彈窗,也就是說,彈窗有一個生效隊列,到了某個時間點某個界面一定會彈出某個框。

 

我們希望彈窗邏輯可以更加聰明,能根據設備和用戶信息個性化的出現。這個需求剛好與 AirTrack 所提供的能力契合,A/B測試并不一定要決定好壞,做出決策,當然也可以支持個性邏輯區分。我們使用 AirTrack SDK 的配置,把不同的彈窗條件單做桶來看待。通過動態配置 AirTrack 的分桶邏輯,并指定彈窗桶號來實現了這個個性化彈窗的需求。

 

以上就是我們在天貓 App 上最主要的三個實踐場景。天貓在A/B測試領域的探索剛剛開始,我們相信隨著探索的深入,A/B測試一定可以在 App 開發和維護中衍生出更加強大的能力,起到越來越重要的作用。

 

本文授權轉載自:快速決策方案 —— Airtrack,作者:高嘉峻

 

吆喝科技:國內唯一同時支持前端(Web/H5、iOS、Android)及后端(Node.js、PHP、Java 等) A/B 測試服務的專業 SaaS 平臺。支持線上灰度發布、多維度數據統計分析、科學的流量分配系統、一鍵發布新版本無需應用市場審核、定向測試。

用數據幫助用戶優化產品,提升轉化、留存和你想要的一切。 AppAdhoc 用數據驗證最佳方案,提高產品設計、研發、運營和營銷效率,降低產品決策風險。

4873 Views
即刻實踐文章理論 A/B測試 灰度發布 產品優化 免費申請
Please wait...

訂閱我們

對于每位訂閱讀者,每兩周,吆喝科技會為您發送4篇精選文章,可能是最新的A/B測試實踐,也會是你所期待的增長干貨。
qq宠物捕鱼大师 客彩网足彩比分 香港最快开奘现场直报六传说 27快乐10分走势图 腾讯5分时时彩开奖 时时彩一天赚2000技巧 白小姐中特网—肖中特 新浪彩票彩客网 福建体彩36选7走势图 王中王资料一肖中特 内蒙古时时开奖走势图