目录
前文
最近思考如何设计统计访问数据,做小的就是页面接口的计数,做大了和大厂的统计又没啥区别,暂时没想明白。先来看看谷歌统计和百度统计的一些明显的区别。
数据收集前端思路的对比
|
协议 |
方法 |
节流 |
访问时长统计 |
标记用户 |
百度 |
http/1.1 |
new Image |
0秒 |
未知 |
cookie |
谷歌 |
h2 or h3 |
Navigator.sendBeacon |
5秒节流 |
未知 |
未知 |
协议
百度 http/1.1
谷歌 h2 or h3
如下图:
- 按照谷歌的请求头,他是支持H3的,如下:
直观的区别
http/1.1每次都需要发起新的TCP请求,而H2有单连接并行,头部压缩等特性,相比http/1.1优势还是比较明显的。
这里可以发现一些的区别:
1.谷歌的请求由于是H2每次请求的id都是一致的。而百度使用的是keep-live进制,同时的请求或者间隔一段时间都会发起新的TCP请求
2. 百度新发起请求有可能会触发dns查询,重新进行tcp和ssl握手,导致请求时间变长。
结论
实际延迟50ms的百度统计有时会比实际延迟100ms的谷歌统计慢(加上方法的区别,在导航更新时,体验会有更大的差距)。
关于H2部分,可以移步ququ大神的HTTP/2 资料汇总查看,记得回来。
方法
百度 new Image()
百度统计是通过new Image(),把页面信息设定为图片链接参数,以GET方式访问空白图片实现数据统计。
谷歌 Navigator.sendBeacon
Navigator.sendBeacon用于通过 HTTP POST 将少量数据 异步 传输到 Web 服务器。
小结
区别
两者的区别在Navigator.sendBeacon中已经有详细的描述。简单摘取:
- image加载 会导致迟卸载文档,并使得下一个导航出现的更晚。下一个页面对于这种较差的载入表现无能为力。
- 使用 sendBeacon() 方法会使用户代理在有机会时异步地向服务器发送数据,同时不会延迟页面的卸载或影响下一导航的载入性能,这意味着:
- 数据发送是可靠的。
- 数据异步传输。
- 不影响下一导航的载入。
- image 可以通过onload 方法确定统计数据提交是否成功,sendBeacon只能指定是否成功进入队列。
关于优先级
从上面的截图可以发现,百度图片的请求和谷歌sendBeacon的请求优先级是不同的。具体可以查看HTMLImageElement.fetchPriority
和Beacon。简单的总结如下:
- image 可以设定优先级,high|low|auto,默认是auto,由浏览器决定。
百度统计没有设置,则为默认,实际的情况为低(low)
- Beacon 无法手动指定优先级,由浏览器确定优先级和调度
特别的地方:Beacon 请求可以被用户代理中止除非开发人员阻止用户代理处理其他事件(例如,通过调用同步请求,或在空循环中旋转),并且用户代理无法确定优先级并合并这些请求以优化系统资源的使用。
节流
百度 不节流
handleUrlChange: function (historyDidUpdate) {
var self = this;
// 保证处理逻辑在页面逻辑之后执行
setTimeout(function () {
var oldPath = self.path;
var newPath = self.getPath();
if (self.opts.shouldTrackUrlChange(newPath, oldPath) && oldPath !== newPath) {
self.path = newPath;
if (historyDidUpdate) {
self.sendPageview(newPath, oldPath);
}
}
}, 0);
},
谷歌 5秒延迟
//h = 5E3 = 5000
var f = y, g = f.setTimeout, h;
a.Ra() ? jD ? (jD = !1,
h = kD) : h = lD : h = 5E3;
this.s = g.call(f, function() {
return c.flush()
}, h)
直观表现
先说明,百度统计由于开启了热点统计且无法关闭,导致每次访问都会有2个请求
- 百度统计在每次触发路由变化时都会发起一个图片请求。统计数据以链接参数形式传递
- 谷歌统计会统计周期即5秒内的请求记录,只发起一个请求。统计数据部分以链接参数传递,关于链接变化和部分事件则会打包在post的数据里。
小结
暂时无法得知谷歌统计在浏览器关闭后是否还能收到最后一次的统计数据。sendBeacon有机会发送数据,但是谷歌统计这里用的是setTimeout去触发,浏览器关闭后setTimeout明显是不会执行的。不知道前面是不是有其他处理。有时间再研究。
上诉情况如果成立,导致的问题就是部分数据统计丢失。(很大可能会有个文档卸载时的强制触发,待验证)
排除上诉问题,我只能说谷歌统计的方法更为优秀,打包发送同时减少服务器和客户端的负担。
反观百度,只能说落后。http/1.1 + cookie + image + 多次发送 ,每个都是槽点。
为何会如此呢,是百度技术不行?我想只是烂透了吧。
话外
在此小节中,我在好奇谷歌统计是如何去处理单页的。节流五秒是不是只统计了最近的一次呢?这个问题困惑了一个多钟吧。还搜索了下。看了官方介绍使用 gtag.js 衡量单页应用。还安装了vue-gtag,发现没有像百度一样每次都发起请求,看了后台,又好像能统计到。最后翻了这个项目的issue,居然和新版的Google Analytics 4冲突,还会有2次请求的情况。回到页面请求中研究了下,才发现gtag新版是可以统计到单页的,并且是打包在post的数据中。
访问时长
似乎比我想象的要复杂。待续。。
- 因为在代码质量检查的时候提示过,所以以为百度是直接unload完事。看了sendBeacon的介绍后,决定再研究研究。
标记用户
与域名相同的称为一方cookie,不同的为三方cookie。实际情况如下:
百度
标志组合:1方cookie + 3方cookie + sessionStorage + localStorage
需要都清除才能在统计中多一个新用户。如果只上删除部分,似乎会被认为旧会话。
具体如下:
* 标识标识统计id
HMACCOUNT_BFESS 三方cookie
Hm_lvt_* 一方近永久cookie
Hm_lpvt_* 一方会话cookie
Hm_lpvt_*
Hm_lvt_*
测试记录
x 表示删除
– 表示保留
项 |
属性 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
a |
b |
c |
d |
e |
f |
cookie-HMACCOUNT_BFESS |
三方cookie |
x |
x |
- |
- |
- |
x |
x |
x |
- |
- |
- |
- |
x |
x |
x |
cookie-Hm_lvt_* |
一方近永久cookie |
x |
- |
- |
x |
x |
x |
x |
- |
- |
- |
- |
x |
- |
- |
- |
cookie-Hm_lpvt_* |
一方会话cookie |
x |
- |
x |
- |
x |
- |
x |
x |
- |
- |
- |
x |
- |
- |
- |
sessionStorage-Hm_lpvt_* |
|
x |
- |
- |
- |
- |
- |
- |
- |
x |
x |
- |
x |
x |
x |
- |
localStorage-Hm_lvt_* |
|
x |
- |
- |
- |
- |
- |
- |
- |
- |
x |
x |
x |
x |
- |
x |
有记录 |
|
y |
y |
y |
y |
y |
y |
y |
y |
y |
y |
y |
y |
y |
y |
y |
新会话 |
|
y |
y |
n |
n |
n |
y |
y |
y |
n |
n |
n |
n |
y |
y |
y |
新用户 |
|
y |
n |
n |
n |
n |
n |
n |
n |
n |
n |
n |
n |
n |
n |
n |
大概可以得出结论:
新的cookie-HMACCOUNT_BFESS ,一定会是个新会话。无视其他信息
只要全部删除才会认为是新用户。
请求携带方式
HMACCOUNT_BFESS 以cookie 形式提交,其他的4个参数会处理成请求参数: cc ,lt, lv。具体也没看懂啥意思,估计和会话有关吧。
关于会话时间
这里没有去深入了解,以百度后台的一个提示,部分浏览器会阻止会话时间上报猜测,这里猜测下百度统计应该是利用了页面卸载的机制进行计算。
谷歌
标志组合:1方cookie
具体如下:
* 标识标识统计id
_ga 一方近永久cookie
_ga_* 一方近永久cookie
测试记录
项 |
属性 |
1 |
2 |
3 |
_ga |
一方近永久cookie |
x |
- |
x |
ga* |
一方近永久cookie |
- |
x |
x |
新用户 |
|
y |
n |
y |
_ga被移除则会被识别为新用户。
请求携带方式
都以请求参数形式提交
_ga_* tid
_ga cid
关于会话时间
目前不确定谷歌是以什么标识去确定会话时间,大胆猜测可能是以H2的TCP会话id作为标识。也不排除与前面提到的方法一样。
按照GA4简介:
使用基于事件而非基于会话的数据
或许我们不应该用百度统计的思路去理解,在谷歌统计中或许这不是关键。
小结
按目前的情况看,百度在识别新旧用户上应该会有一点优势。
总结
2022年7月29日
原本只是想简单对比下这个统计工具的区别,越看越多。
- 谷歌的产品了解的越多,越感慨,新的技术和新的应用,新技术的倡导和实践者,带给我许多惊喜。今天也只是了解了冰山一角,还有许多东西要去学习。
- 而百度呢,已经不知道如何去平均这个掉队的了,
本地优势会比较快?(谷歌统计的服务器也在国内,ping ip的话延迟与百度相当)。看到230ms的请求时间,我表示自己掀开的粪坑自己要填回去。H2和sendBeacon新技术和新特性的诞生就是为了打过时的脸。不能发明新技术,同步更新,赶上而不掉队很难么?我确定无法用百度更懂中文去解释这个事情。中文互联网就该用这样落后的产品吗?哦!是我在用,我的错。