见过不少后台报表，第一屏是访问量、浏览量、平均停留时长、跳出率，翻到第三页才出现这个月到底收到几条询盘。数据不缺，缺的是能回答“这个月生意比上个月好吗”的那几个。下面把三个数一个个拆开：口径怎么定、数从哪来、为什么会少算或多算、和另外两个数放在一起该怎么读。
先把口径写死，否则每周都在重新解释
同一批访问，下面几个值一定不一样大：
- 浏览量：页面被打开的次数，同一人刷新五次算五次。
- 访客数：按 cookie 或设备标识去重后的独立访客。清缓存、开无痕、换手机都会变成新访客。
- IP 数：按出口 IP 去重。同一间办公室十个人共用一个出口，会被合并成一个人。
- 会话数：30 分钟不活动就断开，之后再点算一次新会话。同一个人一天来三次，是三个会话。
报表上写“访问量”三个字，先问清是哪一个。定了之后写进周报模板，别每周换。
时区同样要写死：统计后台的时区、服务器的时区、你记账用的时区，三个不一致，月底那两天的数永远对不上。国内业务建议全部固定成同一个时区，别用默认值。
询盘表单提交：把三个节点分开算
一次询盘会经过三个节点：访客点了提交按钮、服务端收到数据并返回成功、邮箱或后台里真的多出一条记录。
漏计绝大多数出在中间那个节点。常见原因有：页面被缓存后统计脚本没绑上表单事件；访客装了拦截插件，统计请求被拦掉；表单提交成功后跳转页还没加载完就关掉了，事件没发出去。
所以对账的口径只认服务端：表单落到后台那张表里，一条就是一条。统计后台的提交事件用来观察趋势和定位来源，不用来算业绩。
对账时把三个数摆在一起：
| 数据来源 | 它说明什么 |
|---|---|
| 表单后台的记录条数 | 真实到达服务端的询盘数量，可能包含垃圾提交 |
| 统计后台的提交事件数 | 前端成功上报的次数，通常少于真实条数 |
| 邮箱里收到的通知数 | 通知链路有没有断、有没有重复发 |
几种典型的不一致：后台条数多于事件数，去查页面缓存和拦截插件；后台条数少于邮箱通知数，说明通知重复发了，查重逻辑有问题；后台有条数但邮箱一条没有，先看垃圾箱，再查发信服务是不是挂了。
垃圾询盘单独记一个数，不要直接从总数里扣掉。扣掉之后你永远不知道表单被灌到什么程度，也不知道过滤规则有没有生效。
来源渠道：直接访问里有很大一块是假的
来源渠道要准，靠的是投放链接的命名规则，不是靠统计工具猜。规则至少固定三段，写进一张表，谁投放谁照着填：
| 参数 | 写法规则 | 例子 |
|---|---|---|
| utm_source | 渠道名，小写英文，不要中文和空格 | baidu、linkedin、email |
| utm_medium | 大类：cpc、social、email、referral | cpc |
| utm_campaign | 这次活动的唯一标识，带月份 | 2026-11-tradeshow |
规则写下来还不够，投放前要有人点一遍链接看参数对不对。拼错一个字母，这次投放的数据就掉进“直接访问”里，谁也不知道它去了哪。
“直接访问”这一栏里混着这些东西：浏览器书签、从聊天软件里点开的链接（很多客户端不带来源信息）、邮件客户端里点开、短链跳转后丢掉的来源、以及统计脚本被拦掉的那一批。所以直接访问涨了，先别当成品牌变强了，先找找是不是哪次投放漏了参数。
来源丢在中间跳转上也很常见：投放链接先跳短链、再跳登录页、最后才到落地页，来源断在中间那一跳。投放链接直接指向落地页，少跳一次。
还有一种情况是域名不统一：落地页在一个域名下，表单提交到另一个域名，会话被切断，来源全归到直接访问。要么统一到一个域名下，要么在统计里把两个域名配置成同一个会话。
移动端跳出：单页会话不等于不满意
跳出指的是只看了这一页就离开。移动端天然偏高：加载慢、误触、点开发现不是要找的东西，都会算一次。所以这个数不要看全站平均，按落地页拆、按来源拆。
拆开之后看三个对比：
- 同一个落地页，移动端和桌面的跳出差多少。差得离谱通常是排版或加载问题，不是内容问题。
- 同一个页面，从投放进来的移动端和从自然搜索进来的，差多少。投放进来的人本来就更容易走。
- 表单页从“开始填写”到“提交成功”的转化，移动端是多少。
第三个比跳出率有用得多。跳出高但表单完成率不低，说明人来看了看就走，想留的留住了；跳出不高但完成率很差，说明页面把人留住了却没让人填完。后者多一半是表单太长、输入框在手机上被键盘挡住、必填项没标清楚、或者提交后没有明确的成功提示。
移动端还有两件事顺手看一眼：用真机测首屏打开时间，不要用办公室 WiFi 下的电脑模拟；以及表单页在网络一般的情况下能不能一次填完。这两项不改善，别的优化都是白做。
三个数放进一张周表
每周一行，外加一列备注：
| 周次 | 询盘数（表单后台） | 来源分布 | 移动端表单完成率 | 这周做了什么 |
|---|---|---|---|---|
| 2026-W44 | 7 | baidu 3 / linkedin 2 / email 1 / 直接 1 | 48% | 发了两篇文章，改了表单必填项 |
备注那一列不能省。没有它，两周以后你分不清数字变化是因为做了什么，还是因为什么都没做。
读的顺序也有讲究：先看询盘数，再看来源分布有没有结构性变化（比如某个渠道从第三位跳到第一位，或者直接访问突然占了四成），最后才看完成率。反过来读容易被细节带跑，盯着移动端跳出从 62% 降到 58% 高高兴兴，却没注意询盘从 12 条掉到了 5 条。
数字对不上时按什么顺序信
从可信到不可信排：真正收到并回复过的询盘、表单后台记录条数、统计后台事件数、第三方流量估算。
第三方估算适合看趋势，比如这个月比上个月整体是涨还是跌，不能当真实访问量用。它的采样口径和你的统计后台完全不是一回事，两边差几倍是正常的。
不装统计代码能看到什么
服务器访问日志和 CDN 日志能给：请求数、状态码、UA、IP、来源地址。给不了：同一台设备上的多次访问是不是同一个人、页面上的滚动和点击、表单填到一半跑掉的比例。
日志还会被两类东西污染。一是搜索引擎和其他爬虫的请求，这部分在日志里占比不低；二是缓存命中不到回源的请求，回源少不代表没人访问。用日志看量级可以，用来算转化不行。
这周就能做的一件事
把这周表单后台的记录条数、统计后台的提交事件数、邮箱里收到的通知数抄成一行，三个数对一遍。对不上，顺着缓存、拦截插件、通知链路这三处往下查，基本都能查到原因。这一行抄上四周，你就会知道自己的站到底有多少真实询盘，以及哪些渠道是白花钱。
