网站页面浏览时长和停留时长对网站本身有何好处

　　网站页面阅读时长并不等于逗留时长，所以在数据获取阶段，假如不能准确的获取到用户在某个页面的逗留时长，那么关于后续定论也会发生必定的误导。

　　从运营视点来看，用户在网站逗留时刻，反映了网站黏性。一般状况下，用户的需求与网站内容匹配度越高，页面阅读时刻越简单聚拢在一个相对会集区间里，不会过短也不会过长。

　　在评价网站推行效果时，若来自某推行途径的访客页面阅读时刻会集在很短的区间内，则意味着该途径的流量质量过低。咱们常常会看到的转化率就与页面平均阅读时长密切相关，出现一个正态分布的图形。

　　所以在数据获取阶段，假如不能准确的获取到用户在某个页面的逗留时长，那么关于后续定论也会发生必定的误导。

　　现在三大干流核算方法

　　（1）后一页面翻开时刻减去前一页面翻开时刻，得到前一页面的逗留时长。

　　这个方法有两个显着的缺乏：

　　最后一个页面的逗留时刻是拜访不到的，假如一共只要一个页面，那么这个页面逗留再久也不会进行核算；关于一起翻开许多页面的状况，则只要倒数第二个页面会得到相对预备的逗留时长，而其它一切中心被翻开的页面的逗留时长，都会被记载为一瞬间，有可能就会被作为脏数据扔掉掉了。

　　（2）经过心跳包定时向发送数据包，为了不使客户端或服务端的负载过重，数据包发送的距离一般被控制在 15 至 30 秒之间。

　　优点是结合页面是否坐落前台，能够更准确地核算一切页面的实在被阅读的时长。缺乏则数据包发送的时刻距离决议了核算的精度以及数据上报的负载，越大的精度意味着越高的负载。

　　（3）自动在用户自动封闭页面时（onbeforeunload）发送数据包，经过封闭时刻和翻开时刻之间的差值来获取页面逗留时刻。这样做是为了处理榜首点中只翻开一页时无法核算逗留时长的问题，但这样的危险是并不能保证数据包发送100%成功。

　　关于一起翻开多个页面的状况，无法准确获取用户阅读时长的问题也仍然没有处理，用户封闭某页面的时刻减去页面被翻开的时刻，并不能真实表现用户的阅读时刻，只能表现页面被翻开的时刻。别的，假如用户长时刻不封闭页面，页面的逗留时长就会长得夸张，为了躲避这个问题，也需求引进 session 或许其它束缚。

　　干流核算方法的缺点

　　市面上简直一切的核算方法，都是在不准确的用页面翻开时长来充任页面阅读时长。说到准度和精度，又回到了数据剖析中很经典的评论，即：数据的质量要与剖析方针结合，不然咱们就会在无休止地寻求极致的道路上迷失，为了提升 1% 的精准度而投入不成比例的本钱。

　　在进行下一步的评论之前咱们先看看以上的几种核算方法中显着的缺点：

　　只阅读单页时时长无法核算；精度和负载的平衡；多页面阅读时长无法准确核算；页面被最小化或许不坐落当时Tab。以心跳包为主线，对总时长校准

　　那是否有一个本钱可控，又能躲避掉以上几种核算方法中显着的缺点的方法呢？

　　咱们的思考如下：

　　因为网页端没有安稳的网页封闭的事情能够捕获，而且存在多个页面并存的状况，想获取足够准确的阅读时长心跳包看似是最好的计划。经过心跳包核算坐落最前台的页面的时长，结合后一页进入时刻及当时页封闭时刻来对总时长进行校准。为了得到愈加精准早期阅读时长，在开始的30秒内心跳包的发送频率为5秒；30秒到90秒内，发送频率为10秒；之后固定在15秒。

　　心跳包关于长时刻逗留的，而没有用户交互的场景是非常好的处理计划，例如：观看视频，但关于APP和网页端来说，那些长时刻没有操作行为的场景并不多见，关于少量翻开但没有操作的页面，咱们就以为用户没有逗留了。所以从实践场景出发，尽管心跳包更精准，但却不行经济了。

　　所以，现在客户端数据包上报本钱仍然还是一个影响体验的要素的现状下，咱们没有选择将心跳包作为默许收集的功用，默许收集咱们使用了翻开及封闭时刻做差的计划作为核算逗留时长的默许计划。

　　最后，应用到实践的剖析中，咱们不能只看逗留，还要看转化。这并不是本文的要点，但也抛出一种常见的场景，作为本文的完毕，以表达，数据脱离事务仅仅数字。