网站统计审计：七个方面的检查清单

数字会悄悄跑偏：改版丢了一段代码，活动链接丢了 UTM 参数，机器人混进了访客数。本文从七个方面做网站统计审计，每个方面一项具体检查，说明怎么和后台对账，以及怎么把审计变成提醒。

什么时候做统计审计

网站统计审计检查你的数字是否可信：每个页面只被统计一次，事件在该触发时触发，来源归因正确，垃圾数据被挡在外面，隐私设置和你的政策一致。接手一套配置时、改版或迁移后、要基于数据做重大决定之前都该做一次，平时每年也做一两次。

要务实。目标是一份按「对大家在用的数字扭曲多大」排序的修复清单，而不是一份没人看的文档。

要检查的七个方面

下表列出七个方面，每个方面一项关键检查，以及失败时的表现。先查覆盖和对账：如果页面缺失、或总数和后台差得很远，其他的先不用看。

先查覆盖和对账。

每项怎么检查

1. 覆盖。 抓取或列出页面模板，确认每个模板只加载一次脚本。单页应用需要跟踪路由切换；除了首页之外都没有浏览量的网站就是这个问题。也要找重复的代码。
2. 会话和身份。 检查会话超时设置，以及登录时有没有识别用户。看新老访客的占比是否符合预期。
3. 事件。 把埋点方案和实际到达的事件对照：缺失的事件、属性为空的事件、网页和 App 名称不一致、属性里有个人信息。见事件埋点。
4. 来源。 看渠道占比和直接访问。检查活动链接有没有带 UTM 参数，跳转有没有保住点击 ID。
5. 筛选和机器人。 确认内部流量被排除，机器人被分开，没有垃圾来源（见引荐垃圾流量）。
6. 隐私。 检查同意、保留期和 IP 处理是否和隐私政策一致，网址和属性里没有邮箱或手机号。
7. 对账。 把关键总数和源头系统的数字比较（见下文）。

示例结果

示例是一份审计汇总。两项不通过：一个结账模板加载了两次脚本（这些页面的浏览量翻倍），一个注册事件漏掉了社交账号登录。一项警告：直接访问占 34%，里面有邮件简报的落地页。先修不通过的两项，因为它们会改变大家已经在报的数字。

和后台对账

最有力的检查，是拿统计和另一个独立统计同一件事的系统比较：

• 统计里的注册 vs 数据库里的新账户。
• 购买和收入 vs 计费系统里的订单（见转化跟踪）。
• 访客 vs 去掉机器人后的服务器日志。

由于拦截插件和关闭的标签页，前端事件通常比后台少几个百分点，服务端事件应该很接近。差距很大、在扩大或在不同浏览器上不均匀，就说明埋点有问题。不同工具的访客数差异有结构性原因，见独立访客为什么总对不上。

保持健康

把审计变成提醒，下一个问题几小时内就能发现，而不用等到下次审计：

• 数据中断超过设定时长时提醒。
• 浏览量和注册的异常提醒。
• 每周把关键事件和后台比较一次。
• 变更记录：谁在什么时候改了代码、排除规则或渠道规则。

在 TapCub 里做审计

TapCub 的排错指南给出了数据缺失时的检查顺序：只有一个带正确站点密钥的脚本标签、本地主机、Do Not Track 或 Global Privacy Control、请求来源是否在允许域名里、项目是否暂停、排除规则（路径、主机名、User-Agent、IP）、套餐限制和时区。注意采集端即使拒绝了事件也会返回 202，所以响应成功不代表已存储（见文档排错）。同一份指南还讲了重复事件、单页应用缺浏览量，以及和其他工具对不上的情况。

隐私中心显示采集档位、同意规则、地址截断和保留期（见文档隐私与合规）。监控可以按固定阈值、周期变化、预测区间、异常、狂点率或采集中断来提醒，试运行会显示规则在过去 30 天里会触发几次（见文档监控与告警）。排除自己团队的访问见排除内部流量；提醒的概念见监控。

常见问题

什么是网站统计审计？

一次有条理的检查，确认统计配置把正确的数据只记一次、归因正确、排除了垃圾数据、并遵守你的隐私设置。

多久审计一次？

每次改版、迁移或改代码之后都做，平时每年至少一两次。中间的时间靠持续提醒覆盖。

统计审计清单应该包括什么？

覆盖、会话和身份、事件和埋点方案的对照、来源和 UTM 参数、筛选和机器人、隐私，以及和后台总数的对账。

怎么知道统计数据准不准？

拿关键总数和独立系统（比如数据库或计费系统）比较。前端数据有小而稳定的差距是正常的，差距大或在扩大就不正常。

一次统计审计要多久？

一般网站检查一两天，修复再花几天，取决于页面模板和事件有多少。

另见：网站分析、实施网站统计。