网站性能分析：只看成功页面会产生什么选择偏差
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c532466442bf.html
📄
网站性能分析：只看成功页面会产生什么选择偏差
只看成功页面，等于把失败、超时、被拦截和根本没被触发的请求从样本里删掉，剩下的成功率、平均耗时和转化路径都会被系统性高估。这个偏差不会因为样本量变大而消失，因为被删掉的那部分不是随机缺失，而是与“慢”“错”“不可用”直接相关。
一个假设情境：日志只留下了 200 状态码
假设某站点把访问日志按状态码过滤，只导出 200 的请求做性能分析。分析结论是：平均响应 380 毫秒，主要页面全部正常。但真实情况可能是：支付回调接口在超时后返回 504，被过滤掉了；移动端弱网下部分请求根本没到达服务端，也不在日志里；被 WAF 拦截的请求返回 403，同样不在样本中。此时“平均 380 毫秒”描述的不是用户体验，而是“成功那部分请求”的体验。
选择偏差在这里的具体形态是：样本入选条件与结果变量相关。响应慢的请求更容易超时失败，失败后就不进入成功集合，于是成功集合里的耗时天然偏低。这不是测量误差，而是筛选机制本身造成的结构性缺口。
哪些结论在只看成功页面时不能成立
以下推论在缺少失败样本时都站不住：
- “整体成功率很高”——分母被缩小了，失败请求没有进入统计。
- “平均响应时间达标”——慢请求更可能失败并被剔除，平均值被向下拉。
- “转化漏斗各步都正常”——用户在某步反复失败后离开，失败步骤可能根本没有成功记录。
- “某次改版后性能提升”——如果改版同时改变了失败率的统计口径，前后对比不可比。
需要区分的是：这些现象只能说明“成功样本不能代表全部请求”，不能单独证明某次故障或某个改版导致了问题。要定位原因，还需要失败样本、超时记录或客户端侧数据来交叉验证。
缺少完整数据或权限时的最小动作
如果拿不到全量日志，也没有服务端权限，仍可执行一个最小动作：在现有成功样本之外，单独记录“未完成请求”的计数与分类，哪怕只有一个总数。具体做法是：
- 在能触及的层（如反向代理、CDN 边缘日志、前端错误上报）按状态码或错误类型分组计数，不追求明细字段。
- 把“成功请求数”和“非成功请求数”并列记录，而不是只留成功那一列。
- 对超时类错误单独标记，因为超时与耗时直接相关，是最容易造成偏差的一类。
这个动作的结果会直接影响下一步：如果非成功请求占比很低且分布均匀，成功样本的偏差可能有限；如果非成功请求集中在某类接口或某个时段，那么此前基于成功样本得出的耗时和成功率结论就需要重新界定适用范围。
如何判断偏差是否已经影响决策
一个可操作的检验方法是：把已知的失败计数按最保守的方式补回分母，看结论是否翻转。例如成功请求 1000 次、平均 380 毫秒，另记录到 50 次超时。即便不知道这 50 次的具体耗时，只要假设它们不低于超时阈值，就能判断“平均 380 毫秒”是否还成立。若补回后平均值明显上升或成功率跌破预期，说明原结论对缺失样本敏感，不宜直接用于容量规划或改版验收。
需要说明的是，第三方估算流量、搜索引擎报告与站内统计的口径本来就不同，三者不能直接相减来推算失败量。失败样本的补全应优先依赖同一口径下的记录，而不是用另一来源的数字去倒推。
把偏差写进分析结论的写法
与其追求“完整数据”，不如在结论里明确标注样本边界。可用的写法是：本次分析仅覆盖返回成功的请求，失败与超时请求未纳入；因此耗时与成功率仅代表成功子集，不能外推到全部访问。这种标注不会让分析失效，反而让后续决策知道该在哪里补数据。真正危险的不是样本不完整，而是把不完整样本的结论当成整体结论使用。
