中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

增長團隊有三寶：埋點、漏斗、AB測。本文給大家講講，AB測試系統如何從應用到搭建？

一、什么是AB測試？

A/B 測試是一種產品優化方法；為同一個優化目標制定兩個方案，讓同一部分用戶中的一部分用戶命中 A 方案，同時另一部分用戶命中 B 方案，統計并比較不同方案的點擊率、轉化率等數據指標，通過不同方案的數據表現，在確定數據表現通過假設檢驗后，決定最終方案的實驗方法。

二、AB測試的意義？

AB測試是支持數據決策最有力的工具。

以下為最基礎的數據驅動流程，方案驗證即為AB測試過程，實驗才是檢驗真理的唯一標準。

• 數據收集
• 數據分析
• 發現問題
• 提出方案
• 方案驗證
• 發布上線

三、AB測試實驗需要滿足以下兩個特性

1. 同時性

兩個策略是同時投入使用的，而不是AB兩種策略分先后上線，這樣會有其他因素影響。

2. 同質性

兩個策略對應的使用群體需要保證盡量一致。

四、AB測試實驗詳解

1. 流量分配規則：正交與互斥

（1）正交實驗

每個獨立實驗為一層，一份流量穿越每層實驗時，都會隨機打散再重組，保證每層流量數量相同。

（2）互斥實驗

實驗在同一層拆分流量，不論如何拆分，不同組的流量是不重疊的。

（3）什么情況下正交、互斥分配流量？

我們剛剛就用的正交流量分配方式，導致了錯誤的數據結果，如果那個實驗我們用互斥的流量分配方法就完美的解決了這個問題。

AB測試實驗中，兩個或多個實驗內容相互影響則選擇互斥方法分配流量，兩個或多個實驗內容不會相互影響則選擇正交方法分配流量。

• 正交：可以節省流量；
• 互斥：可以讓耦合的實驗完美剝離開來不互相影響。

（4）舉個例子

在詳情頁面上做兩個實驗：

• 其中一個是轉化按鈕顏色的AB測試實驗；
• 另外一個是轉化按鈕文案的AB測試實驗。

如果我們使用正交分配流量的方式會出現什么情況呢？

也就是流量同時命中實驗一與實驗二，最后展現在用戶面前的就是如下圖四種情況，這種情況我們是無法統計出準確的數據結果的，因為已經違背了單一變量原則。

這種最好使用互斥來分配流量，一部分用戶命中實驗一、另一部分用戶命中實驗二。

2. AB測試系統實驗架構

AB測試系統實驗架構包括：應用層-實驗層-策略層。

（1）應用層

應用層級別最好，應用層與應用層之間的流量是正交的。

（2）實驗層

實驗層是應用層子層，實驗層與實驗層之間的流量是互斥的。

（3）策略層

策略層是實驗層子層，一個實驗可以有多個策略，多個策略之間流量相互不影響。

舉個例子：

• 應用：App客戶端
• 實驗：購買按鈕顏色
• 策略：紅色、橘色

3. 創建實驗

創建實驗時一般先設置好實驗條件和統計指標

實驗條件：AB測試系統可以對一些條件的用戶進行限制，城市、年級、新老用戶、版本號、平臺（iOS、Android、h5）。這里我們完全可以直接引入用戶畫像系統直接進行人群定向取做AB測試實驗。傳送門：《用戶畫像如何從搭建到應用實戰？》

這個功能主要是針對滿足這樣實驗條件的用戶進行分流，如不滿足這些條件則不分流，直接命中默認策略。默認策略是我們在創建策略時勾選的，如果用戶不滿足條件命中默認策略，這些用戶產生的數據是不參與計算的，也就不會影響實驗結果。

（1）城市、年級、新老用戶

這幾個條件很好理解，就是指用戶所在城市、年級、新老，但需要用戶登錄才能拿到這樣的信息。

如果設定了實驗條件，用戶處于非登錄態怎么辦呢？

非登錄態的用戶我們認為他是不滿足實驗條件的，所以會走默認策略，這樣會避免一些不滿足實驗條件的用戶卻命中實驗的可能。但為了保證同一個用戶在登入登出看到的頁面是相同的，所以這部分人即使登錄后也會走默認策略。

但不是全部未登錄用戶都會這樣，我們判斷當前時間與未登錄用戶剛登錄的時間點的差值是否大于兩天。

如果大于兩天我們會讓他命中實驗，進行分流，這樣也是為了保證每天下載的大量用戶也會命中AB測試的情況，達到一個平衡的狀態。

（2）適用版本

這里的版本是針對客戶端的AB測試提供的功能。

比如：iOS 在1.0.1 版本，Android在1.0.2版本上線一個AB測試實驗。

如果不綁定版本號會出現什么情況？

因為版本發布，除強制升級外，用戶還處于老版本。對于老版本的用戶也會命中實驗，但是這些用戶并沒有看到不同的策略，就會出現，AB測試系統分給用戶A策略，但是用戶看到的是B策略，最終影響數據準確性。

版本號設置會向上兼容，也就是說只有此版本號，或者高于此版本的用戶才能命中實驗。

（3）平臺

平臺分為3種，分別為：iOS客戶端、Android客戶端、JS（H5）

分別針對不同的平臺進行的AB測試。

這里不說iOS和Android，只說一下H5，因為H5的埋點上報與客戶端不一樣，H5 的分流的唯一ID也與客戶端不一樣。客戶端的分流使用的ID是設備ID，H5則是cookieID。

統計指標：

（1）對于AB兩個策略上線后，我們需要跟蹤兩個策略的數據效果

這兩個策略的效果數據來源就是頁面的瀏覽與按鈕的點擊兩個埋點事件來提供數據支持的。比如：客戶端需要對課程詳情頁的報名按鈕樣式進行AB測試實驗，數據監控的時候我們就需要統計進入詳情頁的人數與報名按鈕點擊uv進行統計。

以報名按鈕uv/詳情頁uv此數值來統計報名按鈕樣式的AB兩種策略效果，那么在創建實驗時就需要確定統計指標，確定指標后就需要確定實驗所需要哪些埋點指標統計。這里就需要詳情頁uv以及報名按鈕uv兩個埋點事件

當然還有更負責的數據指標，但都可以通過埋點數據上報來進行統計。

（2）計算方式

假設一個漏斗中包含了 A、B、C、D、E 五個步驟，選擇的時間范圍是 2015 年 1 月 1 日到 2015 年 1 月 3 日，窗口期是 1 天。那么，如果用戶在2015年1月1日到2015年1月3日觸發了步驟 A，并且在步驟 A 發生的 1 天內，依順序依次觸發了 B、C、D、E，則視作該用戶完成了一次成功的漏斗轉化。

在這個過程中，如果穿插了一些其它的步驟或者行為，例如在滿足時間限制的情況下，用戶的行為順序是 A > X > B > X > C > D > X > E，X 代表任意一個事件，則該用戶依然視作完成了一次成功的漏斗轉化。

如果該用戶在這個事件限制范圍內，依次觸發了 A > B > C > E，則該用戶沒有完成該漏斗的轉化，并且會被記作步驟 C 的流失用戶。

考慮一個更復雜的情況，如果一個用戶在所選時段內有多個事件都符合某個轉化步驟的定義，那么會優先選擇更靠近最終轉化目標的事件作為轉化事件，并在第一次達到最終轉化目標時停止轉化的計算。

假設一個漏斗的步驟定義是：訪問首頁、選擇支付方式、支付成功，那么不同用戶的行為序列及實際轉化步驟（標紅部分）見如下例子：

• 例 1：訪問首頁 -> 選擇支付方式（支付寶） -> 選擇支付方式（微信）-> 支付成功。
• 例 2：訪問首頁 -> 選擇支付方式（支付寶） -> 訪問首頁 -> 選擇支付方式（微信）-> 支付成功。
• 例 3：訪問首頁 -> 選擇支付方式（支付寶） -> 訪問首頁 -> 選擇支付方式（微信）-> 支付成功 -> 選擇支付方式（微信）-> 支付成功。

五、分流引擎

分流策略：簡單的理解就是哪些用戶會命中策略A，哪些用戶會命中策略B。

在說分流策略之前先舉個例子，配合例子更好理解。

假設報名按鈕顏色實驗分50%流量，策略“紅色”按鈕分流量40%，策略“藍色”按鈕分流量60%

例如：取模10000，那報名按鈕顏色實驗的數字區間為0-5000；10000*50%。

策略“紅色”按鈕數字區間為0-2000；5000*40%。

策略“藍色”按鈕數字區間為2000-5000；2000+5000*60%。

現在我們對用戶唯一id，應用id進行哈希。哈希后得到一個數字，這個數字落到哪個數字區間就將用戶分到哪個策略中去。經測試10w次分流，8s，流量diff在1%以內，每個應用分到的用戶正交，不相互影響。

如圖：

六、對接方式

AB測試系統和App服務端或H5服務端對接，分別有兩個接口：一個是策略請求接口、一個是埋點接口。

1. 埋點接口

AB測試系統將接口參數傳給服務端，服務端將參數傳給客戶端和H5前端。

客戶端或者前端遍歷這些 eventids（埋點事件id）如果有用戶命中這些埋點事件則上百 abtestid key及值。

2. 策略接口

例如實驗是客戶端報名按鈕“紅色”、“藍色”。

當流量進入到客戶端后， 客戶端向服務端詢問：我這有倆顏色的按鈕，我要展示哪個顏色的按鈕?。?/p>

服務端：我暫時也不知道，我幫你問問AB測試服務。

服務端問AB測試服務：客戶端來流量了，有兩個顏色的按鈕，需要展示哪個顏色的按鈕??？

AB測試服務：展示“紅色”按鈕。

服務端：我知道了，并告訴客戶端：展示“紅色”按鈕。

客戶端：我知道了，客戶端展示“紅色”報名按鈕。

七、AB測試效果分析

1. 我們為什么要做假設檢驗？

AB測試 是典型的通過樣本數據估計總體數據效果的方法，所以為了避免出現小概率錯誤，我們需要對AB測試的結果進行假設檢驗。

2. 如何進行假設檢驗？

AB測試的假設檢驗一般為兩個總體成數的假設檢驗，具體可看《一文讀懂假設檢驗怎么做》

作者：斑馬

本文由 @斑馬 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議