网站优化检测：访客被分配到不同版本时怎样识别样本污染
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /68749a680dab.html
📄
网站优化检测：访客被分配到不同版本时怎样识别样本污染
先给结论：当同一批访客被分流到两个或多个页面版本，而你在汇总层看指标时，样本污染最典型的信号不是“数据变差”，而是分组之间的访客构成不再可比。识别它的核心动作是：在分析前先按“分配机制”把数据切成互斥且完整的组，再检查每组的新老访客比例、来源结构和设备分布是否接近。如果这些构成差异明显，后续的转化率对比就不能直接照搬。
先判断分配是随机分流还是规则分流
两种情况的处理方式不同。随机分流指每个访客进入哪个版本由随机数决定，理论上两组构成应当接近；规则分流指按来源、地区、登录状态或设备类型指派版本，两组天然会带上不同人群特征。
判断依据可以来自分流脚本或配置本身：看分配逻辑里有没有引用访客属性。如果引用了，就属于规则分流，此时对比两个版本的转化率等于在比较两类人群，而不是比较两个页面。
对应的动作：在分流配置中打印或记录被引用的字段，并核对它们是否与转化路径相关。若某字段既影响分配又影响转化，它就是需要单独控制的混杂因素，下一步应做分层对比而不是整体对比。
用可核查的构成指标定位污染来源
不需要复杂模型，先看三组构成即可：新访客与回访访客比例、主要来源渠道占比、移动端与桌面端占比。把它们按版本分组列出，差异越大，样本污染越可能成立。
- 如果新访客比例在一组明显偏高，而新访客本身转化率低，该组的低转化可能来自人群而非页面。
- 如果来源渠道分布不同，例如一组更多来自站内推荐、另一组更多来自外部链接，行为差异可能由来源意图驱动。
- 如果设备分布不同，页面在移动端的表现差异会被误读成版本差异。
实施动作：把上述构成做成按版本分组的对照表，并标注每个字段的采集口径是否一致。若某个字段在一组缺失严重，先修复采集再谈对比，否则任何结论都建立在不同的分母上。
分层对比能救回一部分被污染的数据
当构成差异存在但样本量允许时，可以按混杂因素分层：在同一来源、同一设备类型、同一新老访客状态下分别比较两个版本。这样做的假设是层内分配接近随机。
假设一个短例子：某页面版本 A 与版本 B 分流，整体看 B 的转化率更低。按来源分层后发现，B 组里来自某推荐位的访客占比更高，而该来源的访客在两组中转化率接近。这说明整体差异主要来自来源构成，而不是版本本身。此时下一步应检查分流规则是否对该来源有偏向，而不是直接下线版本 B。
需要注意边界：分层会切薄样本，层内样本过少时对比不稳定，不能据此下结论。分层只适用于有明确混杂因素且层内样本足够的情形。
不能直接照搬整体对比的三种例外
以下情形下，整体对比的结论不能迁移到其他场景：
- 分配规则依赖访客属性，且该属性与转化相关。此时整体差异是人群差异与页面差异的混合。
- 分流比例随时间变化，例如先放少量流量再扩大。前后两段的来源和季节因素不同，合并统计会掩盖时间效应。
- 存在跨版本污染，例如同一访客在不同会话被分到不同版本，或缓存导致展示版本与记录版本不一致。此时分组本身不干净。
对应的动作：对第一种，先固定分配规则再重跑；对第二种，按时间窗口分段对比并标注每段的流量来源；对第三种，检查缓存与分流记录的版本标识是否一致，必要时用访客标识做去重核对。
把识别动作落成可复用的检查顺序
建议的顺序是：先确认分配机制，再核对构成指标，然后决定是否分层，最后才看转化对比。每一步的产出都影响下一步：分配机制决定是否需要分层；构成差异决定分层维度；分层后的样本量决定结论能覆盖的范围。
如果构成指标接近且分配机制为随机，整体对比可以作为初步依据，但仍需说明观察窗口和流量来源。如果构成差异明显，整体对比只能作为线索，不能作为决策依据。识别样本污染的目的不是否定数据，而是明确哪些对比成立、哪些需要重做分配或补充采集。
