610
性能對轉化率影響評估方法
1. 背景
業內已經有豐富的數據證明快速的網頁瀏覽及操作體驗對轉化率等業務指標有明顯的促進作用：
A. Google found out that slowing search results by just 4/10ths of a second would
reduce the number of searches by 8,000,000 per day.
B. You have 5 seconds to engage a customer before they leave your web site.
C. For every 1 second speed improvement to the Amazon website conversions increased +2%
....
AE有麵向全世界的用戶，這些用戶處在參差不齊的網絡環境中，且由於跨洲際訪問機房的天然的物理距離也會使得AE的用戶性能體驗無法與淘寶這樣內貿網站相提並論。在這種情況下，一方麵由於AE性能優化空間更大，對轉化率提升的空間也更大；另一這方麵由於用戶環境的千差萬別，以及天然距離，使得AE性能優化的投入成本也會非常距大，比如AE可能需要建立區域機房就近服務於用戶才能解決性能問題。
如何精確量化性能回報（即量化性能優化帶來的轉化率提升最終帶來GMV的提升），從而精確計算投入產出比，是AE性能優化工作的前提。業內雖然有較多數據證明性能與轉化的關係，但在精確衡量投入產出時，每個網站都是不同的無可比性，且很多數據結果由於數據不足夠充分也隻能定性不能定量。
基於阿裏巴巴ODPS的大數據處理能力的優勢，AE性能優化小組@桑植、@跑者、@阿四、@子偉、@馮嘉、@濤明、@震羽、@驗鈔提出並實現了大數據時代的度量方法，通過采集真實用戶訪問AE網站的性能Latency數據，以及真實的轉化率數據，實現最精確的性能轉化度量。
目前這一度量還在內部測試調優過程，且已經在內部性能優化中使用，待穩定成熟後，希望能夠貢獻出來，讓集團內部的用戶使用起來。
2. 目標
1）通過大數據的采集、計算、分析，驗證性能與轉化率等業務指標的關係
2）通過大數據的方法，量化性能對轉化率的影響
3）做出通用可複製、業務無關的方案，提供給更多有此類需求的同學使用
3. 方案
3.1 基本思路
1）瀏覽器異步執行JS，JS調用Navigation timing API獲取當前頁麵各階段Latency，並將Latency數據及當前頁麵唯一標識ID、當前用戶Cookie_id異步發送打點服務器
2）打點服務器通過TT將數據導入ODPS
3）ODPS中按Latency分組，將各請求樣本分到其Latency所對應的組中
3）將PV數據按上下遊鏈接關係關聯起來，從而計算轉化率
4）分別計算各組中樣本轉化率
5）最終得出曲線，是在頁麵功能及業務狀態基礎上，各Latency範轉內的轉化率趨勢
3.2 關鍵技術要素
A. 瀏覽器Navigation-timing和Resource-timing API是方案得以實施的關鍵技術基礎，API由W3C在2012年底提出，它可以讓我們獲取到頁麵各個重要的Latency數據，詳情參考https://www.atatech.org/articles/25750 及 https://www.atatech.org/articles/28758
B. ODPS及相關大數據附屬技術產品的的開放性、易用性、處理能力使得方案得以順利實施
3.3 實現細節及相關SQL這裏暫不詳細介紹，歡迎線下交流
3.4 量化性能優化帶來的轉化率提升
1）已經計算出性能區間內的轉化率
2）統計所有樣本在各性能區間內的分布，得出各性能區間的樣本占比
3）將優化後的樣本在性能區間內的占比乘以所在性能區間的轉化率，得出A
4）將優化前的樣本在性能區間內的占比乘以所在性能區間的轉化率，得出B
5）B-A即得出性能優化所帶來的轉化率提升
通過一段時間的觀察，在大的樣本集下，性能與轉化率曲線保持穩定。
4. 結果
圖中為真實的AE某一分站的搜索數據，柱狀圖為各性能區間的樣本占比，黑色線為各性能區域的轉化率，綠色線為各性能區間的跳出率
5. 常見Q&A
Q1:如何排除性能外的業務因素對轉化的影響？
A1:此方案單純的是按性能進行分組統計，在大的樣本下，我們可以假定各性能區間內的業務條件是等同的，因此可以不考慮業務因素的影響。當然，還需要更多的時間去證明
Q2:當業務因素變化時，會使得各性能區間內的轉化數據發生變化，一般會提升，那如何隨時時間去衡量性能帶來的轉化提升？
A2:每次度量時，以時間最接近的曲線為主，按3.4的方法進行計算。後續會按需看是否采用線性回歸，按自然時間上的表現擬合出一條曲線，這樣可以去除掉某一天的波動
最後更新：2017-11-03 13:33:35