转化率优化方法：试验上线后没变化，先查是否真正实施
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /73ec0db9b5e3.html
📄
转化率优化方法：试验上线后没变化，先查是否真正实施
先给结论：如果试验上线后核心指标几乎没动，第一件该做的事不是继续加样本，而是回放一次真实用户路径，确认新版本是否真的被目标人群看到、触发条件是否成立、以及埋点是否记录到了新版本。只有先排除“没实施”或“实施错位”，后续的样本量和显著性判断才有意义。
矛盾现象：指标没动，不等于试验无效
业务侧已经确认代码发布，但关键转化率与上周几乎重合。此时有两种解释都成立：一是试验确实生效，但影响太小，被正常波动掩盖；二是试验没有真正触达用户，数据自然不会有变化。两者的处理方向完全相反，前者需要扩大样本或延长观察，后者必须先修复实施链路。
解释一：试验对用户没有真正生效
常见原因包括分流条件写错、新旧版本同时命中、页面缓存返回旧资源、或触发事件只在部分端生效。这种情况下，数据往往呈现“整体平移”而不是“分组差异”。可以检查实验平台的分组人数是否与预期一致，如果某个变体人数明显偏少，说明分流本身就有问题。
解释二：试验生效了，但被其他因素抵消
如果分组人数正常，但指标没变，也可能是同期发生了其他变化：流量来源结构改变、促销活动结束、或外部渠道波动。这类情况下，指标变化会同时出现在对照组和实验组，而不是只出现在一侧。区分方法是看两组在同一时间段内的走势是否高度一致。
能区分两种解释的证据
最直接的证据来自一次真实用户路径回放：用无痕窗口或新设备访问目标页面，确认看到的是新版本还是旧版本。如果看到旧版本，实施问题基本确认；如果看到新版本但埋点没有记录，问题在数据采集；如果两者都正常，再去看分组人数和流量结构。
- 分组人数核对：实验组和对照组人数比例是否接近预设分流比例。偏差过大时，优先怀疑分流逻辑。
- 版本回放：用真实用户路径确认实际返回的页面内容，而不是只看发布记录。
- 埋点验证：在测试环境触发一次关键动作，确认事件是否进入对应版本的记录。
- 流量结构对比：检查实验期与基准期的来源、设备、地域构成是否发生明显变化。
一个假设例子：先修实施，再谈样本
假设某页面按钮文案试验上线三天，点击率与之前持平。回放发现移动端返回的仍是旧文案，桌面端才是新版本。此时正确动作是修复移动端缓存或发布流程，而不是继续等待。修复后重新开始观察，因为此前三天的数据并不能代表新版本的真实表现。这个例子说明：实施问题不解决，后续任何样本量判断都会建立在错误前提上。
动作与下一步决策
先执行一次版本回放和分组人数核对。如果发现实施问题，修复后重新计时，并记录修复时间点作为新的观察起点；如果实施正常，再检查流量结构是否发生迁移。只有确认实施无误后，才进入样本量和显著性判断。这样做的结果是：你排除了一类最容易被忽略的假阴性，后续决策不再建立在“试验已经生效”的默认假设上。
