被删除页面的流量数据不必也不应继续混在“当前可访问页面”的口径里,但也不能直接丢弃。正确做法是把它拆成两层保留:一层是可追溯的原始事实(页面存在过、当时归因到哪些入口、何时下线),另一层是剔除后的对比口径(当前站点总量、当前页面排名)。前者用于解释波动,后者用于判断商城流量提升的真实趋势。规模小时凭记忆和截图能应付,一旦页面数量上百、删除动作分散在多个运营手里,就必须靠固定字段和固定口径来留痕。
这两个目标对应完全不同的数据组织方式,混在一起就会出现“总量对不上”的假异常。
判断依据很简单:如果这份报表的读者要回答“为什么变了”,保留被删页面的原始记录;如果读者要回答“现在哪些页面值得投入”,就必须剔除。两种需求同时存在时,用同一份底表加一个“页面状态”字段区分,而不是做两份互不相关的表。
只有一两个页面被删时,运营通常能记住“这个页面以前大概带来多少访问”,在复盘时口头扣除即可,误差可接受。但页面删除变成常态——比如每次活动结束都清理一批临时页、每次改版都合并一批旧分类页——就会出现三种例外:
所以边界是:样本少、删除动作一次性、且不要求跨月对比时,口头扣除够用;一旦删除常态化或需要纵向对比,就必须先固定口径再谈分析。
不需要复杂系统,关键是三件事按顺序做。
第一步,给页面加状态字段。在页面清单里增加 page_status(active / deleted)、deleted_at(下线日期)、last_full_month_views(下线前最后一个完整自然月的访问量)。这个动作的结果是:任何后续统计都能用状态字段过滤,不必回头翻聊天记录。
第二步,保留删除前的数据快照,而不是只保留汇总。快照至少包含该页面的来源拆分(搜索、站内、广告各自占比)。这一步影响下一步:只有知道来源结构,才能在总流量下滑时判断是入口问题还是页面问题。
第三步,做一张对比表,把“含被删页面”和“不含被删页面”两个口径并排放。例如假设某月总访问下降,含删除口径看是下降,剔除被删页面后现有页面其实持平——这说明问题出在页面消失,而不是现有页面变差。这只是说明比较方法的假设例子,不是真实项目数据。
被删页面的历史数据往往分散在三处,口径并不一致:第三方估算工具给的是模型推断值,搜索后台报告给的是该渠道可见的展示与点击,站内统计给的是实际到达与行为。三者对同一页面的数字天然不同,不能相加,也不能用一个去“修正”另一个。
可核查的证据链应该这样用:站内统计确认页面确实存在过并给出访问量级;搜索报告确认该页面曾从搜索获得曝光;第三方估算仅作为趋势方向的旁证。当三者方向一致时,可以较有把握地判断“删除确实带走了这部分流量”;当只有第三方估算显示下滑、站内和搜索报告都平稳时,更合理的解释可能是估算模型调整或采集波动,而不是删除动作本身。
需要特别说明:某个指标归零或骤降,不能单独证明删除处理正确或错误。它还可能来自统计脚本变更、归因窗口调整、渠道标记丢失。要排除这些解释,至少核对删除时间点与数据变化时间点是否吻合,并确认同一时间段其他页面没有同步异常。
可以简化的条件:页面总量少、删除动作集中在少数人手里、复盘只做一次性归因、不要求跨月对比。此时用一张手工维护的下线记录表就够,记录页面标识、下线日期、下线前月访问量即可。
不能简化的条件:页面数量持续增长、删除由多人分散执行、需要按月比较商城流量提升趋势、或需要向不同角色解释同一份数据。此时必须固定状态字段和快照规则,并明确“含删除”与“剔除删除”两个口径各自用在什么场合。判断标准不是数据量大小,而是同一份历史数据是否会被反复重算——只要会,就必须先把口径钉死,再开始分析。