網站頁面瀏覽時長并不等于停留時長，所以在數據獲取階段，如果不能準確的獲取到用戶在某個頁面的停留時長，那么對于后續結論也會產生一定的誤導。

從運營角度來看，用戶在網站停留期間，反映了網站黏性。普通情況下，用戶的需求與文章內容匹配度越高，頁面瀏覽期間越方便聚攏在一個相對集中區間里，不會過短也不會過長。

在評估網站推廣效果時，若來自某推廣渠道的訪客頁面瀏覽期間集中在很短的區間內，則意味著該渠道的流量質量過低。我們經常會看到的銷售比就與頁面平均瀏覽時長密切相關，呈現一個正態分布的圖形。

所以在數據獲取階段，如果不能準確的獲取到用戶在某個頁面的停留時長，那么對于后續結論也會產生一定的誤導。

目前三大主流計算辦法

（1）后一頁面打開時刻減去前一頁面打開時刻，得到前一頁面的停留時長。

這個辦法有兩個明顯的不足：

最后一個頁面的停留期間是訪問不到的，如果一共只有一個頁面，那么這個頁面停留再久也不會進行統計；對于同時打開大批頁面的情況，則只有倒數第二個頁面會得到相對準備的停留時長，而其它所有中間被打開的頁面的停留時長，都會被記錄為一瞬間，有或許就會被作為臟數據拋棄掉了。

（2）通過心跳包定時向發送數據包，為了不使客戶端或服務端的負載過重，數據包發送的間隔普通被控制在 15 至 30 秒之間。

好處是結合頁面是否位于前臺，可以更精準地計算所有頁面的真實被瀏覽的時長。不足則數據包發送的期間間隔決定了統計的精度以及數據上報的負載，越大的精度意味著越高的負載。

（3）主動在用戶主動關上頁面時（onbeforeunload）發送數據包，通過關上期間和打開期間之間的差值來獲取頁面停留期間。這樣做是為了解決第一點中只打開一頁時無法計算停留時長的問題，但這樣的風險是并不能確保數據包發送100%成功。

對于同時打開多個頁面的情況，無法準確獲取用戶瀏覽時長的問題也依然沒有解決，用戶關上某頁面的期間減去頁面被打開的期間，并不能真正體現用戶的瀏覽期間，只能體現頁面被打開的期間。另外，如果用戶長期不關上頁面，頁面的停留時長就會長得夸張，為了規避這個問題，也需要引入 session 或許其它約束。

主流計算辦法的缺陷

市面上幾乎所有的統計辦法，都是在不精準的用頁面打開時長來充當頁面瀏覽時長。提到準度和精度，又回到了數據分析中很經典的討論，即：數據的質量要與分析目標結合，否則我們就會在無休止地追求極致的道路上迷失，為了提升 1% 的精準度而投入不成比例的成本。

在進行下一步的討論之前我們先看看以上的幾種計算辦法中明顯的缺陷：

只瀏覽單頁時時長無法計算；精度和負載的平衡；多頁面瀏覽時長無法精準統計；頁面被最小化或許不位于當前Tab。以心跳包為主線，對總時長校準

那是否有一個成本可控，又能規避掉以上幾種計算辦法中明顯的缺陷的方法呢？

我們的思考如下：

由于網頁端沒有穩定的網頁關上的事件可以捕獲，而且存在多個頁面并存的情況，想獲取足夠精準的瀏覽時長心跳包看似是最好的方案。通過心跳包統計位于最前臺的頁面的時長，結合后一頁進入期間及當前頁關上期間來對總時長進行校準。為了得到更加精準早期瀏覽時長，在起始的30秒內心跳包的發送頻率為5秒；30秒到90秒內，發送頻率為10秒；之后固定在15秒。

心跳包對于長期間停留的，而沒有頁面互動的場景是十分好的解決方案，例如：觀看視頻，但對于APP和網頁端來說，那些長期間沒有操作行為的場景并不多見，對于少數打開但沒有操作的頁面，我們就認為用戶沒有停留了。所以從實際場景出發，雖然心跳包更精準，但卻不夠經濟了。

所以，目前客戶端數據包上報成本依然還是一個感染感想的因素的現狀下，我們沒有篩選將心跳包作為默認采集的功能，默認采集我們使用了打開及關上期間做差的方案作為計算停留時長的默認方案。

分享標題：網站頁面瀏覽時長就是停留時長嗎，有什么區別
文章地址：http://www.js-pz168.com/news33/261083.html

成都網站建設公司_創新互聯，為您提供響應式網站、商城網站、自適應網站、關鍵詞優化、服務器托管、用戶體驗

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯