建立待验证原因清单,核心是把“流量来源分析”中看到的异常或变化,先翻译成一组可被证据支持或推翻的假设,再按验证成本排序。清单不是结论列表,而是待办诊断队列:每条写清现象、可能原因、验证动作、判断标准和优先级。对已有页面或项目,重点不是重新收集所有数据,而是围绕当前目标找出最值得先查的几条原因。
在列原因之前,先固定三个变量:时间范围、对比对象、流量口径。时间范围可以是最近7天对比前7天,也可以是大版本上线前后。对比对象可以是同一页面的上一周期,也可以是同类页面。流量口径必须区分站内统计、搜索引擎报告和第三方估算:站内统计通常记录到达站点的会话,搜索引擎报告通常记录展示与点击,第三方估算往往基于抽样和模型,三者不能直接相减得出“丢了 compatible 多少流量”。
如果口径不统一,原因清单会混入大量伪问题。例如站内统计下降而搜索报告点击未变,可能只是统计脚本触发条件变化,不一定是搜索流量减少。先把口径写进清单表头,后续每条原因都注明它对应哪个口径。
现象要具体到可观察层面,例如“某栏目自然搜索点击下降”“某页面跳出率上升”“某来源会话数减少”。不要写“流量变差”这类无法验证的描述。每条现象至少拆出两到三个可能原因,避免把单一现象直接归因于唯一原因。
可以按来源类型建立假设分支:
每条假设写成“如果……那么应该看到……”的形式。例如:如果某页面点击下降是因为展示量减少,那么在搜索报告中该页面的展示次数应同步下降;如果展示量稳定而点击率下降,则应优先检查标题摘要、排名位置和查询词变化。这样写的好处是,验证动作直接对应判断标准,不会看完数据仍不知道支持还是推翻。
待验证原因清单不能只按“我觉得可能”排序,而要比对验证代价和证据强度。代价包括时间、权限、是否影响线上、是否需要跨团队协作。证据强度包括数据是否可复现、口径是否一致、样本是否足够。
一个实用的排序方法是:
如果某条原因验证代价很高,例如需要全量日志或跨部门取数,就先标记为“待定”,不要让它阻塞低成本检查。清单的价值在于让团队知道下一步查什么,而不是一次把所有原因查完。
判断标准要能回答“看到什么算支持,看到什么算推翻”。例如:
如果数据只能显示相关,不能显示因果,就在清单中标注“相关,待进一步验证”。不要因为两个指标同时变化就写成已定位原因。技术排查中尤其要区分“可能原因”和“已经定位的原因”:服务器日志异常可能由爬虫减少、缓存策略变化或路由调整引起,不能只看一个现象就断言唯一原因。
可以按以下字段维护清单:现象、口径、可能原因、验证动作、判断标准、代价、优先级、状态。状态只用“待验证、验证中、已支持、已推翻、待定”几类,避免模糊描述。每次只推进优先级最高的两到三条,验证后立即更新状态,防止清单变成静态文档。
假设某页面自然搜索点击下降,清单中第一条写“口径核对:站内统计与搜索报告是否一致”,第二条写“展示量是否同步下降”,第三条写“查询词结构是否变化”。执行后如果展示量稳定、点击率下降,则把标题摘要和排名位置相关的假设提前;如果展示量下降,则把索引、收录和查询需求变化相关的假设提前。这里的例子是假设,用于说明判断路径,不代表真实项目结果。
下一步:打开你当前项目的流量来源报告,先固定一个时间范围和对比对象,然后写下三条待验证原因,并为每条补上验证动作和判断标准。只保留能在一周内执行的低成本检查,执行后再决定是否扩展清单。