在數據獲取階段，如果不能準確的獲取到用戶在某個頁面的停留時長，那麼對於後續結論也會產生一定的誤導。
從運營角度來看，用戶在網站停留時間，反映了網站黏性。一般情況下，用戶的需求與網站內容匹配度越高，頁面瀏覽時間越容易聚攏在一個相對集中區間裡，不會過短也不會過長。
在評估網站推廣效果時，若來自某推廣渠道的訪客頁面瀏覽時間集中在很短的區間內，則意味著該渠道的流量質量過低。我們經常會看到的轉化率就與頁面平均瀏覽時長密切相關，呈現一個正態分佈的圖形。
所以在數據獲取階段，如果不能準確的獲取到用戶在某個頁面的停留時長，那麼對於後續結論也會產生一定的誤導。
目前三大主流計算方法
1.後一頁面打開時刻減去前一頁面打開時刻，得到前一頁面的停留時長。這個方法有兩個明顯的不足：
1) 最後一個頁面的停留時間是訪問不到的，如果一共只有一個頁面，那麼這個頁面停留再久也不會進行統計；
2) 對於同時打開很多頁面的情況，則只有倒數第二個頁面會得到相對準備的停留時長，而其它所有中間被打開的頁面的停留時長都會被記錄為一瞬間，有可能就會被作為髒數據拋棄掉了。
2.通過心跳包定時向發送數據包，為了不使客戶端或服務端的負載過重，數據包發送的間隔一般被控制在 15 至 30 秒之間。好處是結合頁面是否位於前臺，可以更精確地計算所有頁面的真實被瀏覽的時長。不足則數據包發送的時間間隔決定了統計的精度以及數據上報的負載，越大的精度意味著越高的負載。
3.主動在用戶主動關閉頁面時（onbeforeunload）發送數據包，通過關閉時間和打開時間之間的差值來獲取頁面停留時間。這樣做是為了解決第一點中只打開一頁時無法計算停留時長的問題，但這樣的風險是並不能確保數據包發送100%成功。對於同時打開多個頁面的情況，無法準確獲取用戶瀏覽時長的問題也依然沒有解決，用戶關閉某頁面的時間減去頁面被打開的時間，並不能真正體現用戶的瀏覽時間，只能體現頁面被打開的時間。另外，如果用戶長期不關閉頁面，頁面的停留時長就會長得誇張，為了規避這個問題，也需要引入 session 或者其它約束。
主流計算方法的缺陷
市面上幾乎所有的統計方法都是在不精確的用頁面打開時長來充當頁面瀏覽時長。提到準度和精度，又回到了數據分析中很經典的討論，即：數據的質量要與分析目標結合，否則我們就會在無休止地追求極致的道路上迷失，為了提升 1% 的精準度而投入不成比例的成本。
在進行下一步的討論之前我們先看看以上的幾種計算方法中明顯的缺陷：
1.只瀏覽單頁時時長無法計算；
2.精度和負載的平衡；
3.多頁面瀏覽時長無法精確統計；
4.頁面被最小化或者不位於當前Tab。
以心跳包為主線，對總時長校準
那是否有一個成本可控又能規避掉以上幾種計算方法中明顯的缺陷的辦法呢？我們的思考如下：
由於網頁端沒有穩定的網頁關閉的事件可以捕獲，而且存在多個頁面並存的情況，想獲取足夠精確的瀏覽時長心跳包看似是最好的方案。（心跳包就是在客戶端和服務器間定時通知對方自己狀態的一個自己定義的命令字，按照一定的時間間隔發送，類似於心跳，所以叫做心跳包。）通過心跳包統計位於最前臺的頁面的時長，結合後一頁進入時間及當前頁關閉時間來對總時長進行校準。為了得到更加精準早期瀏覽時長，在起始的30秒內心跳包的發送頻率為5秒；30秒到90秒內，發送頻率為10秒；之後固定在15秒。心跳包對於長時間停留的，而沒有用戶交互的場景是非常好的解決方案，例如觀看視頻，但對於APP和網頁端來說，那些長時間沒有操作行為的場景並不多見，對於少數打開但沒有操作的頁面，我們就認為用戶沒有停留了，所以從實際場景出發，雖然心跳包更精準，但卻不夠經濟了。
所以，目前客戶端數據包上報成本依然還是一個影響體驗的因素的現狀下，我們沒有選擇將心跳包作為默認採集的功能，默認採集我們使用了打開及關閉時間做差的方案作為計算停留時長的默認方案。
最後，應用到實際的分析中，我們不能只看停留，還要看轉化。這並不是本文的重點，但也拋出一種常見的場景，作為本文的結束，以表達，數據脫離業務只是數字。
閱讀更多 Marketing聯盟 的文章
