流量来源统计方法 - 怎样判断采集是否遗漏
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2a785434caff.html
📄
流量来源统计方法 - 怎样判断采集是否遗漏
判断采集是否遗漏，核心不是看总流量高低，而是做一次“对账”：拿同一时间段的站内统计、搜索引擎报告、第三方估算和服务器日志，按来源、落地页、参数三个维度交叉比对。若某来源在站内统计里有量，在日志里却找不到对应请求，或反过来日志有明显请求而报表缺失，就说明采集链路存在遗漏。下面给出两种处理方案的适用条件、具体做法和验收信号。
先分清两种处理方案：补采与改口径
发现差异后，处理方式通常分两类，适用条件完全不同。
- 补采：适合“数据确实没被记录”的情况。典型信号是服务器日志或CDN日志中能看到请求，但统计脚本未触发，或触发后未成功上报。常见原因包括脚本被拦截、页面跳转丢失参数、跨域上报失败、移动端WebView未执行脚本。
- 改口径：适合“数据被记录了，但统计规则把它归错或过滤掉”的情况。典型信号是日志与统计总量接近，但某来源被归入“直接访问”，或带参数的落地页被合并。常见原因包括来源识别规则、会话切分、过滤规则、参数剥离。
选错方案会白费功夫：明明是口径问题却去补采，只会让重复数据更多；明明是漏采却去改口径，差异永远对不上。
具体做法：用三层对账定位遗漏
第一层：总量对账
取同一时间段（建议至少完整一天，避开跨时区结算），比较三组数字：站内统计的访问次数、服务器日志的去重IP或请求数、搜索引擎报告中的点击量。三者本就不该相等，因为口径不同：日志含爬虫和静态资源请求，搜索引擎报告只统计从结果页点击进入的次数。所以这一步只看数量级是否合理，比如日志请求量远大于统计访问量，可能正常；但统计访问量大于日志请求量，基本可判定异常。
第二层：来源对账
把站内统计的“来源/渠道”报表导出，与日志中Referer字段的分布对比。重点看两类遗漏：
- 日志里有大量来自某外部域的Referer，但统计报表中该来源为零或极少。
- 统计报表中某来源占比很高，但日志中找不到对应Referer。
第一种通常指向来源识别规则未覆盖，第二种可能是统计脚本把无Referer的请求错误归因，或存在刷量。
第三层：落地页与参数对账
选3到5个带参数的推广链接，手动访问一次，然后检查：统计后台是否记录了这次访问、来源是否识别正确、落地页URL参数是否完整保留。若参数在跳转中被剥离，后续来源归因就会丢失，表现为“直接访问”增多。这一步可以实际执行，且结果可复核。
一个可执行的检查清单
- 固定一个时间窗口，导出站内统计、日志、搜索引擎报告三份数据。
- 比较总量数量级，记录差异方向。
- 按Referer分布比对来源报表，标出“日志有、报表无”和“报表有、日志无”两类。
- 手动访问带参数的测试链接，确认参数保留与来源识别。
- 检查统计脚本是否在目标页面全部加载，特别是跳转页和弹窗页。
- 核对过滤规则，确认没有把真实来源误判为内部流量或机器人。
验收信号与判断结果
补采方案验收：手动测试链接在日志和统计中都能查到，且来源、参数一致；连续观察一个周期，原先缺失的来源出现稳定记录。改口径方案验收：调整规则后重新跑同一时间段数据，差异缩小到可解释范围，且不再出现某来源整体归零或整体归入“直接访问”。
如果两种方案都试过仍对不上，优先怀疑时间窗口不一致、时区设置不同或数据延迟，而不是继续加规则。此时应固定同一时区和同一结算周期再比一次。
下一步：选一个你怀疑遗漏最严重的来源，按上面的三层对账跑一遍，先确定是漏采还是口径问题，再决定补采还是改规则。
