CRO项目做坏了，往往不是因为没人会改按钮颜色，也不是因为团队想不出新标题，而是甲乙双方从一开始买的就不是同一种东西。

甲方以为自己买的是一套“发现问题—排序—实施—验证—沉淀”的增长系统；供应商实际卖的是审计报告、设计建议和月度PPT。两边都可以合理地把服务叫作“转化率优化”，直到签约以后才发现：谁写代码、谁修埋点、谁判断实验是否有效、谁把赢家正式上线，这些关键环节根本没人负责。

所以，挑CRO供应商最先问的，不应该是“一个月能跑多少个实验”，而应该是：

什么证据会改变决策？谁负责把变化真正上线？数据不够时怎么办？哪些风险指标可以否决一个看上去漂亮的增长？

Baymard当前的结账研究提供了一个很好的提醒：其跨研究购物车放弃率基准约为70.19%，但其中相当一部分只是用户浏览、比价、暂时没准备购买，并不都是“网站缺陷”。行业里存在巨大的流失数字，不等于你的站点就有同样的问题，更不等于供应商能把这70%“优化回来”。

真正成熟的供应商，应该敢在项目开始时说一句：“我们现在还不知道原因，但我们知道怎么把它查清。”

下面这17个问题，最好在采购和签合同之前问完。

1. 审计报告交付以后，你们到底还负责什么？

先把整个链路摊开：

  • 埋点与数据检查；
  • 用户研究；
  • 漏斗诊断；
  • 假设形成；
  • 设计；
  • 文案；
  • 前端开发；
  • QA；
  • 实验配置；
  • 数据判断；
  • 上线；
  • 胜出方案正式固化；
  • 复盘与知识沉淀。

让供应商逐项标记“我负责 / 你负责 / 第三方负责”。

如果实施全部压给甲方内部团队，就要在签约前把开发工时算进去。一个看起来不贵的研究项目，如果所有建议都排进已经拥堵的开发队列，最后一样会变成昂贵的PPT。

“我们会提供可执行建议”不是答案。明确的责任人、交接点和周期才是答案。

2. 给我看一个“你们最初判断错了”的项目

只展示成功案例，没有太大价值。

真正的CRO能力，不只是找到有效方案，还包括尽快推翻错误的自信。让供应商讲一个案例：团队一开始以为A是问题，通过数据和研究发现不是，然后改变方向。

你要观察的不是最后增长了多少，而是供应商是否能放弃自己的故事。

如果所有研究最终都恰好证明“应该购买我们本来就卖的服务”，研究很可能只是包装。

3. 一个想法要满足什么条件，才能进入优化队列？

成熟团队会有准入门槛。

例如，一个假设至少需要两类证据：漏斗异常、访谈、可用性测试、客服问题、站内搜索、会话观察、已知缺陷、市场限制等。

规则不必完全一样，但一定要避免“谁声音大谁优先”。

最好直接看一份去掉客户敏感信息的真实假设卡，而不是听“我们是数据驱动的”这种口号。

4. 你们怎么区分“应该直接修的Bug”和“值得实验的问题”？

支付报错、表单校验坏掉、移动端遮挡、缺运费说明、追踪失效、键盘无法操作的控件，并不一定需要A/B测试。

可以把待办分成三类：

修复：正确行为已经明确；
研究：原因有争议；
实验：至少存在两个都合理的解决方案。

如果供应商按“实验数量”收费，它可能天然有动力把任何问题都包装成实验。这个问题能很快看出它有没有这种倾向。

5. 如果流量不够，你们会怎么做？

不要接受“我们照样能测”这种答案。

低流量、窄人群、小效应会让实验周期长得没有商业意义。成熟团队应该能提出替代路径：扩大变化幅度、做定性验证、先修明显问题、扩大适用人群、使用合适的留出组，或者干脆根据风险和可逆性直接决策。

最值得追问的一句是：

请给我一个你们曾经主动建议客户“不要做实验”的案例。

6. 哪个指标能宣布成功？哪些指标有权否决成功？

只看转化率很危险。

一个方案可能提高结账完成率，同时带来更多退款、折扣损失、低质量线索、客服投诉，甚至让用户误订阅。

在上线前就要写清楚：

  • 主指标是什么；
  • 保护指标是什么；
  • 哪一种恶化会触发暂停；
  • 是否看利润贡献，而不是只看订单数；
  • 是否看不同设备、人群和新老客。

一个“漂亮的转化率”不应该自动拥有最终解释权。

7. 你们如何阻止“操纵式优化”？

这是运营风险，不是哲学题。

美国FTC关于dark patterns的材料长期关注隐藏重要条款、制造退出障碍、隐瞒费用、诱导用户作出非本意选择等设计。

所以供应商必须有明确的红线：虚假稀缺、误导倒计时、默认勾选、隐藏附加费、取消困难、模糊同意、伪造社会证明，不能因为“数据提升”就被合理化。

最好的流程是在设计和实验评审阶段就阻止，而不是出事以后再交给法务。

8. 无障碍标准是否写进验收条件？

W3C的WCAG 2.2给出了可测试的Web无障碍成功准则，并建议在制定或更新无障碍政策时使用当前版本。

CRO经常改表单、焦点顺序、错误提示、按钮、弹层和页面结构，这些正是容易产生无障碍回退的区域。

要问清楚：

  • 设计评审是否包含无障碍；
  • 前端QA是否包含；
  • 是否只有自动扫描，还是有人工作业；
  • 实验脚本注入DOM以后是否重新检查；
  • 第三方工具造成的问题由谁负责。

但不要把“我们参考WCAG”自动理解成法律合规认证，除非合同里真的定义了具体标准和责任。

9. 实验方案必须遵守什么性能预算？

有些方案在实验看板里“赢了”，但真实页面变慢了。

Google的Core Web Vitals把加载、交互响应和视觉稳定性作为重要的真实用户体验信号。采购时不要只问“你们会不会优化速度”，而要问：

什么性能恶化会触发回滚？实验上线前后怎么对比？

如果转化增长是靠让页面更慢、脚本更多、布局更不稳定换来的，它可能只是在把问题挪到别处。

10. 埋点定义、实验数据和原始记录最后归谁？

合作结束后，企业不能只剩几份截图。

至少要明确能否保留或导出：

  • 事件定义；
  • 实验ID与曝光逻辑；
  • 结果表；
  • 允许导出的明细数据；
  • 研究笔记；
  • 设计稿与代码；
  • 为什么上线、为什么停止的决策记录。

CRO最值钱的长期资产之一，是组织记得“我们已经学过什么”。

11. 当不同系统的数据互相打架时，你们听谁的？

分析平台一个数字，支付系统一个数字，CRM又是另一个数字，这很常见。

让供应商现场解释：

  • 订单到底以哪个系统为准；
  • 退款怎么算；
  • 时区如何统一；
  • 内部员工和机器人流量怎么剔除；
  • 重复事件怎么处理；
  • 同意模式造成的数据缺口怎么解释。

仪表盘做得漂亮，不等于底层定义一致。

12. 实验什么时候可以停止？

这个问题应该在平台演示之前问。

成熟团队会谈最短运行周期、样本、季节性、停止规则、重复查看数据的影响，以及业务上下文，而不是只说“工具显示显著就停”。

也要问“没有明确结果怎么办”。

好的团队会保留学习；差的团队会把失败实验改个名字再来一次。

13. 你们默认甲方每个月要投入多少内部资源？

把回答换成“小时”。

例如：

  • 前端20小时；
  • 设计12小时；
  • 数据分析4小时；
  • 法务2次评审；
  • 产品负责人每周1小时。

把这些内部成本和供应商费用放在同一张表里，项目真实成本才出现。

很多所谓“供应商推进慢”，其实是甲方根本没给实施资源。

14. 实验胜出以后，怎么真正进入正式产品？

赢家长期挂在实验平台里，是技术债。

问清楚从“实验胜出”到“正式固化”的完整流程：谁建ticket、谁开发、何时上线、谁QA、如何核验埋点、何时删掉临时代码。

失败方案同样要清理。

CRO应该奖励“实现的改变”，而不只是“完成的实验”。

15. 给我看最近5份实验复盘，包括失败的

客户名字可以删掉。

你重点看四件事：

  1. 原始不确定性是什么；
  2. 实际发生了什么；
  3. 下一步决定是什么；
  4. 哪条学习可以迁移到以后。

如果每份报告都花大量篇幅庆祝 uplift，却很少解释不确定性和失败原因，这个团队可能更擅长做续约材料，而不是做学习系统。

16. 90天后出现什么情况，我们就应该结束合作？

这个问题不是挑衅，而是提前对齐。

成熟供应商应该说得出失败条件，例如：

  • 埋点一直不可信；
  • 没有真正上线任何改变；
  • 内部实施持续堵塞；
  • 数据冲突始终没解决；
  • 待办没有证据；
  • 工作无法建立与商业价值的联系。

然后再反问：为了避免这些情况，甲方必须提供什么。

17. 即使甲方要求，你们也坚决不做什么？

这个答案最能看出成熟度。

优秀供应商应该敢拒绝虚假稀缺、隐藏费用、误导默认项、伪造评价、无法解释的测试、明显无障碍回退，以及只为让看板更漂亮却伤害长期业务的做法。

“会拒绝什么”本身就是产品能力。

一个更难被PPT骗过的评分表

维度 权重 高分意味着什么
诊断与证据质量 20% 方法清楚，有证据准入门槛
实施责任 20% 交接、工时、周期都明确
测量纪律 20% 主指标、保护指标、曝光和停止规则清楚
用户与合规护栏 15% 能处理dark pattern、同意、无障碍等风险
技术质量 10% 有性能预算、QA和实验清理机制
知识沉淀 10% 数据可导出、学习可复用
商业匹配 5% 定价和真实工作量一致

评分本身不是最重要的，真正的价值是它逼双方谈具体问题。

一个供应商可以非常优秀，但仍然不适合你当前阶段：不知道问题在哪时需要研究；旅程结构坏了时需要改版；流量和数据成熟以后才适合持续实验；个性化则往往应该在更后面。

你是在选运营模式，不是在选功能列表最长的工具。

合同至少把四个问题写清楚

交付单位是什么？
研究结论、正式上线的改动、实验、学习循环，还是工时？

谁负责上线？
双方都要有具体责任人。

成功怎么判断？
应该是带保护指标的业务结果，而不是“想法数量”。

什么情况可以叫停？
数据失真、用户伤害、无障碍回退、性能恶化、法律风险、流量不足，都应该是正当的暂停理由。

这四件事清楚，CRO才有机会成为一套学习系统，而不是“每月买建议”。

结论

真正值得买的CRO供应商，不是承诺实验最多的那一家，而是能清楚告诉你：

它知道什么、不知道什么、准备怎么查、谁负责把变化上线，以及什么证据会让它主动停止。

先买这种运营纪律，再谈工具、仪表盘和实验数量。

Sources

Related Reading