一个CRO团队开始变贵，往往不是因为工具订阅涨价，而是因为每一次实验都像第一次做。

这周大家争论“该测什么”；下周没人记得当初为什么要测。设计稿先开发了，埋点还没准备好；结果看起来不错，却只停在PPT里，没有改变产品。三个月以后，同样的想法换了个名字又进入需求池。

解决办法通常不是再买一套实验软件，而是建立一个很小、但能坚持的运营系统：把证据变成每周任务队列，保护测量质量，并强迫每一个结果产生下一步动作。

下面这套SOP适合真实团队——营销、设计、产品、开发都有人力限制。无论你是高频A/B测试，还是把分阶段上线、定性访谈和数据分析混合使用，都可以采用。

所有CRO任务先写成一张实验卡

在任何人动手开发之前，每个CRO事项都应该能放进一页。

至少包含：

  • 问题： 什么证据说明用户正在遇到摩擦？
  • 人群： 哪类用户最明显？
  • 假设： 哪个变化应该改善这个问题？
  • 主指标： 哪个行为应该变化？
  • 护栏： 哪些指标不能明显恶化？
  • 证据方式： A/B、分阶段上线、可用性访谈、群组比较还是其他方法？
  • 负责人： 谁做最终决定？
  • 读数日期： 什么时候正式看结果？
  • 下一步： 赢、输、模糊三种情况各做什么？

这听起来像管理工作，但和“先做一个模糊方案再解释为什么”相比，成本低得多。

实验卡最大的价值，是阻止一个常见错误：先做处理方案，再倒推问题。

周一：收集证据，不开“创意大会”

不要一开周会就问：“这周测什么？”

更有价值的问题是：“哪里真的出现了摩擦？”

可以从这些地方找：

  • 漏斗断点；
  • 站内搜索暴露的困惑；
  • 客服和销售反复遇到的异议；
  • 退款理由；
  • 移动端与桌面端差异；
  • 支付失败、表单失败；
  • 可用性访谈；
  • 商品评价；
  • 不同流量来源表现差异；
  • 页面速度或交互延迟异常。

Baymard 的结账研究长期提醒行业：很多转化问题来自非常具体的可用性摩擦，而不是“营销点子不够聪明”。其当前公开统计中的在线购物车放弃率平均值约为70.22%。但这个数字不是让你直接拿来当自己网站的基准，而是提醒团队：必须研究自己用户为什么犹豫。

周一结束时，只保留一个短证据队列。每条都写清观察到的问题、受影响的人群和商业后果。

错误做法： 脑暴出20个测试创意。
更好做法： 找到5个有证据的问题，再按重要性和可解决程度排序。

周二：排序“决策价值”，不要排序“想象中的提升幅度”

很多团队会给创意打一个“预计影响分”，最后产生一种假精确感。

更好的优先级判断有四个问题：

  1. 如果得到答案，真的会改变某个决策吗？
  2. 现有证据证明问题存在的力度有多大？
  3. 能不能设计出足够清晰的处理方案？
  4. 判断错的成本和风险是什么？

低流量页面的小文案改动很容易做，却可能完全不重要；结账摩擦更难，但可能直接影响生意。

周二也要决定证据方法。低流量、长购买周期、复杂B2B漏斗，未必适合经典A/B。分阶段上线、访谈、销售质量数据和行为数据组合，可能更有价值。

错误做法： “所有问题都应该A/B。”
更好做法： 让证据方式匹配流量、风险和真正要做的决策。

周三：先把测量做通，再打磨最后5%的视觉

最终设计还没完全漂亮，也应该先确认测量链。

至少检查：

  • 控制组/处理组分配；
  • 事件是否触发、属性是否正确；
  • 跨域、结账跳转是否断链；
  • 收入、线索质量字段；
  • consent变化；
  • 设备维度；
  • 错误、退款等反向信号；
  • 页面性能变化。

Google PageSpeed Insights 会把真实用户 field data 和实验室 lab data 分开看。CRO也应该有同样的思路：测试环境里很漂亮的方案，在真实用户设备上可能是另一回事。

给团队做一张上线清单，而且必须由非开发本人再检查一次。

一个很实用的规则是：界面做完不等于实验准备好；能可靠做决定才算准备好。

周四：QA体验，不只是QA代码

一个方案可以技术上没bug，却依然让体验更差。

发布前至少检查三层。

1. 功能QA

重要设备和浏览器能不能正常工作？表单能不能提交？支付、登录等关键链路有没有破坏？

2. 性能QA

新方案有没有明显拖慢加载和交互？Core Web Vitals 用 LCP、INP 和 CLS 分别观察加载、响应和视觉稳定，适合拿来做发布护栏。

3. 无障碍与清晰度QA

WCAG 2.2 给出可测试的无障碍要求。增长团队不需要把自己变成标准委员会，但不能因为“转化率高”就破坏键盘操作、焦点、表单标签或可读性。

同时检查商业表达。FTC 对 dark patterns 的公开材料明确警惕隐藏条款、阻碍取消、操纵式选择等做法。一个转化提升如果建立在误解上，不是健康的胜利。

错误做法： QA只问“页面能不能显示”。
更好做法： QA问“用户能不能清楚理解并完成任务，而且没有新增伤害”。

周五：带着停止规则上线

上线前就把正式读数日期，以及什么情况需要暂停或判定结果无效写清楚。

包括：

  • 计划最短运行周期；
  • 已知广告活动或促销变化；
  • 库存、价格变化；
  • 重大技术事故；
  • 哪个指标是唯一主指标；
  • 哪些护栏即使主指标变好也能阻止发布。

不要因为图表今天变绿，团队就临时重写规则。

低流量团队也一样需要停止规则，只是可以更运营化，例如：“覆盖两个完整业务周期，确认没有大规模流量结构变化，再结合5个客户访谈一起判断。”

重点是一致，而不是假装每个网站都有企业级样本量。

下一个周一：30分钟内做决定

一次CRO读数只需要回答五个问题：

  1. 原问题是什么？
  2. 我们改了什么？
  3. 主指标发生了什么？
  4. 护栏发生了什么？
  5. 下一步做什么？

最终动作通常只有五种：

  • 发布： 证据足够，护栏可接受；
  • 不发布： 处理方案没有改善决策；
  • 迭代： 结果暴露了一个更具体的新问题；
  • 暂缓： 数据质量或外部变化让结果不可靠；
  • 迁移学习： 这次结果应该改变另一个页面、人群或规则。

最后一种往往最值钱。比如“运费提示应该更早出现”的学习，可能不只影响一个结账页，而是影响整个价格透明度策略。

建学习ledger，不要建“胜出截图墙”

一堆“最佳实验截图”很漂亮，但很快失去上下文。

更有用的是一张学习ledger：

字段 为什么要留
问题 防止三个月后换个名字重复测试
证据 知道当时为什么做
处理方案 确认真正改了什么
结果 指标口径和结果一起保存
护栏 不丢失隐藏成本与风险
决策 知道结果是否真的改变产品
可迁移学习 把一次测试变成组织资产

时间久了，它会变成一张客户摩擦和历史决策地图。

小团队真正能坚持的每周节奏

如果人不多，就保留最小版本：

周一： 选一个有证据的问题。
周二： 写实验卡、选证据方法。
周三： 开发并把测量做通。
周四： 独立QA和发布检查。
周五： 上线或安排分阶段发布。
下一周期： 读数、决策、记录学习。

不要用“这周上线了几个实验”衡量CRO产能。

真正应该衡量的是：这周产生了几个可信、能改变行动的决策。

这条区别，决定CRO最后会变成一个学习系统，还是一场由仪表盘、创意和绿色箭头组成的表演。

Sources

Related Reading