先给结论:报告页数通常不等于实际对象数量,去重的正确起点不是删掉重复行,而是先确定“对象”的判定键,再决定哪些行需要合并、哪些行必须保留。假设你从自动化工具导出一份内容清单,报告显示 1200 行,实际独立页面只有 800 个,差额往往来自同一对象被不同 URL、参数或渠道重复记录。此时直接按标题去重会误删真实页面,按 URL 去重又会漏掉同一页面的变体,所以要先区分重复类型。
报告行数与对象数量的差异,常见来源有三层。第一层是采集层:同一页面被带参数、带尾斜杠、带大小写变体的 URL 重复抓取。第二层是对象层:一个页面在工具里被拆成多个内容单元,例如分页、筛选页、打印页。第三层是业务层:同一对象在不同渠道或不同账号下各生成一条记录。
这三层的处理方式不同。采集层重复可以归一化后合并;对象层重复要先确认这些变体是否算独立对象;业务层重复则要看报告用途,如果用于投放复盘,渠道维度不能丢。判断方法很简单:随机抽 20 行,逐行问“它代表的是不是同一个可访问对象”。如果 20 行里超过一半指向同一对象的不同 URL 形式,问题在采集层;如果指向同一对象的不同功能视图,问题在对象层。
去重需要一个稳定的对象键。对大多数内容页面,规范化后的 URL 可以作为主键;对商品、SKU 或账号类对象,业务 ID 更可靠。规范化至少包括:统一协议与主机名大小写、去掉无意义的跟踪参数、统一尾斜杠策略、处理默认端口。注意,这里说的“去掉参数”不是无条件删除,而是只删除不影响内容判定的参数,例如会话标识和来源标记;如果参数决定页面内容,例如分页参数,就不能删。
一个可执行的短例子(假设情境):某工具导出 1200 行,其中 300 行是同一批 URL 带不同跟踪参数,100 行是同一批 URL 的 http 与 https 两种写法。按“规范化 URL”作为对象键合并后,剩 800 行。此时不要急着认为去重完成,还要检查是否有 50 行是同一对象的分页视图。如果报告目标是统计独立落地页数量,分页应合并;如果目标是统计可投放的广告落地位置,分页可能算独立对象。这一步的选择直接决定下一步是继续合并还是回退保留。
个别样本去重容易,规模上去后例外会变多。常见例外包括:同一对象在不同语言站点下各有 URL;同一对象有移动端与桌面端两套地址;同一对象在工具里因抓取失败被重复记录。处理这些例外,不要逐条手工判断,而是先写保留规则:
假设去重后得到 800 个对象,其中 30 个对象有语言变体,按合并规则变成 770 个。这个数字变化会影响下一步:如果后续要做内容覆盖率对比,应该用合并后的对象数作分母;如果后续要做多语言投放排期,应该回退到 800 并保留语言维度。也就是说,去重结果不是唯一正确的数字,而是取决于报告要回答的问题。
去重完成后,不要只检查总数变小就结束。可以观察三个信号:第一,随机抽取合并前后的对象,确认合并组内确实指向同一可访问对象;第二,检查被合并掉的行里是否包含独立业务 ID,如果有,说明对象键选错了;第三,把去重后的对象数与站内实际可访问对象数做一次抽样比对,差异应能逐条解释。
需要提醒的是,报告行数下降、抓取量下降或某个统计归零,都不能单独证明去重正确。它们也可能是抓取失败、过滤条件变化或导出范围调整造成的。因此,验证要回到对象本身,而不是只看数字变化。如果抽样中仍有无法解释的重复,下一步不是继续批量删,而是回到对象键定义,确认是否漏掉了某个业务维度。
一次去重完成后,把规则固化成可复用条件:对象键是什么、哪些参数必须保留、哪些变体合并、哪些变体保留、例外如何标记。这样下次报告行数与对象数量再次不一致时,可以直接套用规则,而不是重新争论。假设你下次导出的报告是 1500 行,按同一规则合并后得到 950 个对象,其中 40 个被标记为例外。这个结果可以继续用于覆盖率或排期,但前提是规则没有变化;如果报告用途从内容统计变成广告投放,规则中的保留项需要重新确认。
去重的边界在于:它解决的是同一对象被重复计数的问题,不解决对象本身是否应该存在、是否有效或是否值得投放。后者需要另外的判断依据。因此,去重之后应把结果交给下一步决策,而不是把去重数字直接当作最终结论。