七天 CRO 优先级剧本：每周只推进一个可验证问题

CRO 周会的目标不是收集更多改进点，而是让一个高价值问题从证据走到回读。 审计一次列出几十项，通常会让易改的视觉项先被做掉，真正阻塞支付、总价或移动路径的问题继续存在。每周限制在一个主问题，能迫使团队明确取舍、完成验证并积累可复用结论。

先做判断

所有候选先分 P0、P1、P2。P0 是可复现的阻塞、错误信息或信任损害，直接修复并回归；P1 是至少有两类证据支持、对关键漏斗有业务影响的问题；P2 是理论合理但证据不足的美化与长期想法。只有同级项目才使用 ICE 排序，不能让“容易做”把 P0 压下去。

候选证据是否够强，可先看CRO 证据质量诊断；当样本不足以跑实验时，切换到低流量 CRO 验证剧本。

决策与执行框架

第 1 天：找泄漏。 查看 Landing→PDP、PDP→加购、Cart→Checkout、Checkout→Purchase，并按入口、设备、市场、商品组与新老客做最小分层。只带回影响最大的少数候选，记录绝对流失人数、阶段率和数据可信度。

第 2 天：补证据。 针对候选抽看同分群录屏、客服语料、站内搜索、评价或任务测试。把“页面不好”改写成“谁在什么条件下完成不了什么任务”。没有第二类证据的建议降为 P2 或继续研究。

第 3 天：定处方。 为主问题写一页实验卡：问题、证据、假设、改动范围、主指标、护栏、完成定义、风险与回滚方式。方案优先删除不必要摩擦和修复事实不一致，不先增加新组件。涉及平台或政策能力时，先核对当前资料。

第 4 天：制作与预验收。 在安全环境实现，覆盖桌面、移动、主要市场、正常与错误状态。检查事件仍触发、价格与政策不冲突、页面速度和无障碍没有明显退化。P0 修复需要回归同类路径。

第 5 天：受控上线。 按现有发布制度执行预览、diff、批准、发布和回读。记录版本、时间、受影响页面与流量；不能安全隔离时，缩小范围或延后，不把“赶周节奏”当作越过闸门的理由。

第 6—7 天：看早期信号，不下最终结论。 先确认实现正确、事件可信、错误减少和护栏稳定。若需要完整周期或更大样本，保持观察；周末只记录当前证据状态：已修复、实验中、无变化、反向或证据不足。

下一周从回读开始。有效做法沉淀适用人群与边界；无效和反向结果同样保留，防止团队几个月后重复提出同一主意。

常见误判

• ICE 分高就优先：ICE 依赖主观评分，不能覆盖 P0 与合规闸门。
• 一周必须看到购买显著上涨：一周是执行节奏，不是任意站点的统计周期。
• 修复 bug 也要 A/B 测试：明确阻塞应直接修复并做回归。
• 一次只做一个问题太慢：限制并行是为了得到可解释结论；独立 P0 可并行处理。
• 只记录赢家能提高效率：丢失失败证据会让团队重复浪费。

验证清单

• 候选是否先分 P0/P1/P2，再在同级内做 ICE。
• 主问题是否有一类定量加一类定性证据。
• 问题陈述是否明确人群、入口、阶段和任务。
• 实验卡是否包含主指标、护栏、完成定义与停止条件。
• 改动是否为解决问题的最小范围，并有回滚路径。
• 上线前是否覆盖主要设备、市场和错误状态。
• 上线后是否先验证实现与事件，而非直接看转化涨跌。
• 有效、无效、反向和证据不足是否全部归档。

适用边界

本剧本适合有固定运营与开发节奏的电商团队，也可由单人运营缩减执行。它不是要求每周强行上线一个实验：当数据不可信、风险不可控、审批未完成或样本不足时，正确产出可以是诊断证据与待验证方案。生产发布、支付、政策和批量配置仍需遵守各自审批与回读闸门。