📍 WDQWDWQD987AAAAA:216.73.216.171
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /bdeb6b0f4759.html
📄

百度司南数据，怎样判断采集是否遗漏

判断百度司南数据采集是否遗漏，核心不是看总量多不多，而是做“对账”：拿一份可独立核对的基准清单，与司南里实际能查到的条目逐项比对，找出只存在于一边的记录。如果基准里有、司南里没有，才属于采集遗漏；如果两边都没有，那是基准本身不完整，不是采集问题。

先明确“遗漏”的判定基准是什么

没有基准就无法谈遗漏。百度司南数据本身是一个分析工具，判断它是否漏采，需要先确定一个可核查的参照物。常见基准有三类：

• 站内统计：自己服务器的访问日志、埋点上报记录，能反映真实发生过的访问或转化。
• 第三方估算：其他流量估算工具给出的数字，口径与司南不同，只能做趋势参考，不能当作遗漏证据。
• 业务台账：订单号、表单提交记录、客服登记等，字段明确、可逐条核对。

站内统计与第三方估算的口径差异很大，前者记录实际请求，后者多为模型推算。用第三方估算去证明司南漏采，容易把口径差误判成遗漏。优先选站内日志或业务台账做基准。

一个假设例子：从对账到定位

假设某网站在某天通过埋点记录到 500 次表单提交，运营想在司南里核对这批提交的转化数据，结果只筛出 420 条。这时不能直接下结论说“漏了 80 条”，要按下面步骤走。

1. 统一筛选条件。确认两边的时间范围、时区、去重规则、渠道定义是否一致。司南按天统计与日志按自然日统计，跨零点时容易差出几十条。
2. 导出两份清单。把站内记录导出为带唯一标识（如订单号、提交时间戳）的表格，把司南能导出的明细也导出，用同一字段做匹配。
3. 找“只在基准里”的记录。用表格的查找或 VLOOKUP 类功能，标出基准有、司南无的条目，这些才是疑似遗漏。
4. 逐条看特征。疑似遗漏的记录是否集中在某个渠道、某个时段、某种设备或某个页面。集中出现往往指向一个可定位的原因，而不是随机丢失。
5. 验证原因。如果遗漏集中在某类流量，检查该类流量的采集代码、参数拼接、跳转链路是否完整；如果分散且无规律，优先怀疑去重或口径，而不是采集。

这个例子里 80 条的差额，可能全部来自口径差，也可能部分来自真实遗漏。只有完成第 3 步的逐条匹配，才能区分。

常见错误：把这几类情况当成遗漏

• 把去重差当遗漏。同一用户多次提交，一边按次计、一边按人去重，数字自然对不上。
• 把过滤条件当遗漏。司南里默认过滤了内部 IP、测试流量或异常访问，站内日志没过滤，差额由此产生。
• 把归因窗口当遗漏。转化归因有时间窗口，窗口外的提交不会计入对应来源，看起来像丢了。
• 把未上报当遗漏。埋点只在特定页面触发，用户从其他路径完成的行为本就没上报，基准里也不该有。
• 把抽样当全量。某些视图展示的是抽样结果，与全量明细比对必然有差。

这些错误的共同点，是拿两个口径不同的数字直接相减。正确做法是先对齐口径，再比对明细。

可执行的检查清单

按顺序做完以下检查，再判断是否存在遗漏：

1. 确认基准数据来源可靠，字段含唯一标识。
2. 对齐时间范围、时区、去重规则、过滤条件。
3. 导出两边明细，按唯一标识匹配，统计“只在基准”“只在司南”“两边都有”三类数量。
4. 对“只在基准”的记录做特征分组，看是否集中。
5. 针对集中特征，检查对应采集链路的代码与参数。
6. 若差额可被口径解释，判定为口径差；若无法解释且集中出现，判定为疑似遗漏并继续定位。

适用条件：基准必须比司南更接近真实发生量，否则对账方向会反。判断结果只有两种——能解释的差额和不能解释的差额，后者才需要进一步排查采集环节。

下一步，先选一天数据量适中的日期，按上面的清单做一次完整对账，把“只在基准”的记录单独存成一张表，再逐条看它们的共同特征。