增长实验模板:先定义假设,再看指标

0阅读13分钟

为什么你的增长实验总是在「看数据」这一步卡住

我在团队里见过太多这样的场景:产品周会上有人说「我们把注册流程简化一下试试」,老板点头,开发上线,两周后看数据——注册转化率涨了 3%,但没人说得清这 3% 从哪来、能不能持续、要不要继续投入。

这不是增长实验,这是「上线一个改动然后祈祷」。

真正有用的增长实验,从写假设那一刻就开始了。假设不是「我觉得改按钮颜色能提升转化」,而是「我们认为「新注册用户」在「首次登录后的引导流程中」,如果「跳过邮箱验证步骤」,那么「7 日留存率会提升 8%」,因为「验证邮件打断了用户首次体验的连贯性」」。

假设写得清楚,你才知道该看什么指标、该分多大样本、该跑多久。没有假设,指标变化很难解释,实验结束后的复盘也只能停留在「涨了/跌了」这种层面。

这篇文章给你一套可以直接套用的增长实验模板,覆盖从假设到复盘的完整流程。我会用三个真实踩过的案例来说明哪些地方容易翻车,以及怎么修。

理论基础:实验驱动增长不是拍脑袋

增长实验的方法论来源很明确。Eric Ries 在《精益创业》里提出了 Build-Measure-Learn 循环,核心思想是「不要花六个月做一个完美产品,先用最小可行实验验证你的假设」。这个思路在 Sean Ellis 提出的 Product-Led Growth(PLG)框架里得到了进一步落地——产品本身就是获客、激活和转化的主要引擎,而实验是你调整这个引擎的手段。

Statsig 在 2025 年发布的 PLG 基准报告中强调了一个关键概念:Product-Qualified Lead(PQL),即「已经体验过产品核心价值的用户」。PQL 的转化率远高于传统 MQL(Marketing-Qualified Lead),因为你测的是真实行为而非意向。实验的目的之一,就是找到让更多用户更快到达 PQL 状态的路径。

GrowthHackers 的 ICE 评分模型提供了实验优先级排序的方法。Impact(影响面)、Confidence(成功信心)、Ease(实施难度)三项各打 1-10 分,取平均值作为排序依据。这解决了另一个常见问题:团队有 50 个增长想法,先做哪个?ICE 帮你把「直觉排序」变成「可讨论的评分」。

Kameleoon 的研究团队还提出了一个容易被忽略的点: painted-door experiment(涂门实验)。在你投入开发资源之前,先用假按钮、假入口测试用户是否真的对这个功能感兴趣。这能避免团队花两周做了一个没人点的功能。

综合来看,一个合格的增长实验框架至少需要包含六个环节:

  1. 假设定义——谁、什么场景、做什么改变、预期什么结果、为什么
  2. 指标选择——核心指标 + 护栏指标
  3. 实验设计——样本量、分组策略、时间窗口
  4. 风险评估——最坏情况、回滚方案
  5. 执行与监控——上线、数据读取、异常处理
  6. 复盘归档——继续/停止/调整,学到了什么

案例一:新用户引导流程实验——从「简化三步」到「分场景引导」

场景

我们有一个 SaaS 工具,新用户注册后需要完成四步引导:设置团队名 → 邀请成员 → 选择模板 → 导入数据。数据上看,第三步到第四步的流失率高达 40%。

翻车

第一版假设是「用户觉得四步太多了」。于是我们把引导砍成两步:设置团队名 → 直接进主界面,其余设置放到后续提示里。

上线两周后,进主界面的用户确实多了 15%。但 7 日留存没动,付费转化率反而下降了 6%。原因很简单:跳过「选择模板」和「导入数据」的用户根本没体验到产品价值,他们进了主界面不知道干嘛。

修复

我们重新写假设:不是「步骤越少越好」,而是「用户在每一步都要感受到进展」。

新方案是分场景引导:检测到用户是个人使用时,跳过「邀请成员」;检测到用户没有现成数据时,提供空白模板而非强制导入。关键改变是,每一步都保留了一个「完成」的微反馈,让用户知道自己在前进。

这次 7 日留存提升了 11%,付费转化率提升了 4%。

代码示例:引导步骤的条件渲染

反面做法——硬编码跳过步骤

// 问题:所有用户走同一条简化路径,不区分场景
const onboardingSteps = ['team-name', 'main-dashboard']
 
function Onboarding() {
  return (
    <StepContainer>
      {onboardingSteps.map((step) => (
        <Step key={step} component={getComponent(step)} />
      ))}
    </StepContainer>
  )
}

这种做法把所有用户当成同一类人,砍步骤只是减少了摩擦,但没有增加价值感。

正面做法——根据用户画像动态调整步骤

// 根据用户类型动态组装引导路径
type UserSegment = 'individual' | 'team-lead' | 'data-rich'
 
function buildOnboardingPath(segment: UserSegment): Step[] {
  const common: Step[] = [
    { id: 'team-name', title: '设置你的工作空间', showProgress: true },
    { id: 'choose-template', title: '选一个起始模板', showProgress: true },
  ]
 
  const segmentSteps: Record<UserSegment, Step[]> = {
    individual: [
      // 个人用户不需要邀请成员,直接给空白模板
      { id: 'blank-template', title: '从空白开始或导入数据', showProgress: true },
    ],
    'team-lead': [
      { id: 'invite-members', title: '邀请你的团队成员', showProgress: true },
    ],
    'data-rich': [
      { id: 'import-data', title: '导入你现有的数据', showProgress: true },
    ],
  }
 
  return [...common, ...segmentSteps[segment]]
}

正面做法的关键是「每一步都有明确的进展反馈」。showProgress: true 看起来是个小细节,但它让用户知道这不是一个无底洞。

案例二:定价页实验——ICE 评分帮我们避开了一个坑

场景

团队想优化定价页转化率。产品经理提出加一个「年付优惠」的对比表,设计师想做视觉重设计,运营想加社会证明(客户评价)。三个想法,先做哪个?

翻车

如果没有 ICE 评分,通常会变成「谁声音大听谁的」。上一次我们直接上了视觉重设计,花了两周,转化率纹丝不动。因为用户不是看不懂定价页,他们是不确定「我的团队用不用得上」。

修复

用 ICE 评分重新排序:

想法ImpactConfidenceEase平均
加年付对比表5475.3
视觉重设计4333.3
加客户评价(按行业筛选)8767.0

「加客户评价」得分最高,因为它直接解决用户的核心疑虑——「跟我同行业的人用了吗?」。而且实现成本低,运营可以直接从客户成功案例里摘取。

我们做了分行业的评价展示:SaaS 公司看到 SaaS 同行的评价,电商公司看到电商同行的。转化率提升了 12%。

代码示例:分行业社会证明组件

反面做法——堆一堆客户 Logo

// 问题:Logo 墙没有针对性,用户找不到和自己相关的案例
function PricingSocialProof() {
  return (
    <div className="logo-wall">
      <h3>深受客户信赖</h3>
      {allCustomers.map((c) => (
        <img key={c.id} src={c.logo} alt={c.name} />
      ))}
    </div>
  )
}

正面做法——按行业筛选的评价卡片

// 根据当前用户画像展示同行业案例
type Industry = 'saas' | 'ecommerce' | 'fintech' | 'education'
 
interface TestimonialCard {
  companyName: string
  industry: Industry
  quote: string
  metric: string // 如「节省了 40% 的协作时间」
  avatarUrl: string
}
 
function PricingSocialProof({ userIndustry }: { userIndustry?: Industry }) {
  const sortedTestimonials = useMemo(() => {
    if (!userIndustry) return testimonials
    // 同行业评价排最前面
    return [...testimonials].sort((a, b) => {
      const aMatch = a.industry === userIndustry ? 0 : 1
      const bMatch = b.industry === userIndustry ? 0 : 1
      return aMatch - bMatch
    })
  }, [userIndustry])
 
  return (
    <div className="testimonial-grid">
      <h3>同行业团队的使用反馈</h3>
      {sortedTestimonials.slice(0, 3).map((t) => (
        <div key={t.companyName} className="testimonial-card">
          <p className="quote">「{t.quote}」</p>
          <p className="metric">{t.metric}</p>
          <div className="author">
            <img src={t.avatarUrl} alt="" />
            <span>{t.companyName}</span>
          </div>
        </div>
      ))}
    </div>
  )
}

正面做法的关键是让用户在 3 秒内找到和自己相关的证据。「跟我同行业」比「10000+ 客户信赖」更有说服力。

案例三:激活邮件实验——painted-door 帮我们省了两周

场景

我们想在用户注册后第三天发一封「你还没完成设置」的提醒邮件。团队觉得应该做一个智能邮件系统,根据用户未完成的具体步骤生成不同内容。

翻车(未发生)

在投入开发之前,我们做了一个 painted-door 实验:给所有未完成设置的用户发了一封通用提醒邮件,内容就是简单的「你还有未完成的事项,点击继续」。这封邮件是手动发的,没有自动化。

结果:点击率只有 2.1%,完成设置的用户比例和非邮件组没有显著差异。

如果直接上智能邮件系统,我们至少会花两周做模板引擎、触发逻辑、个性化内容,最后发现「用户根本不care这封邮件」。

修复

问题不在邮件内容的个性化程度,而在渠道选择。用户没完成设置,说明他们可能已经忘了这个产品。邮件的打开率本身就低。

我们改用了应用内通知 + 浏览器推送的组合,在用户实际打开产品的时刻触发提醒。完成率提升了 18%。

代码示例:触发时机的判断逻辑

反面做法——注册后固定天数发邮件

// 问题:不管用户有没有回来,固定第 3 天发邮件
function scheduleActivationEmail(userId: string) {
  setTimeout(() => {
    const user = getUser(userId)
    if (user.onboardingStatus !== 'completed') {
      sendEmail(user.email, '你还没完成设置')
    }
  }, 3 * 24 * 60 * 60 * 1000) // 固定 3 天后
}

固定时间发邮件的问题是,用户可能第 2 天就回来了,也可能第 10 天才想起来。第 3 天的邮件对一个第 2 天已经活跃的用户来说是打扰,对一个第 10 天才回来的用户来说又太早了。

正面做法——在用户实际活跃时触发提醒

// 在用户回到产品的时刻,检查并提醒未完成事项
function onUserSessionStart(userId: string) {
  const user = getUser(userId)
 
  if (user.onboardingStatus !== 'completed') {
    // 应用内通知:用户已经在看产品了,此刻提醒最有效
    showInAppNotification({
      title: '继续完成设置',
      body: `你还有 ${user.remainingSteps} 步未完成`,
      actionUrl: `/onboarding/resume?step=${user.nextStep}`,
      priority: 'high',
    })
  }
 
  // 如果用户 7 天没回来,才用推送或邮件作为召回手段
  if (daysSinceLastActive(user) >= 7) {
    scheduleReminder(userId, {
      channel: user.preferredChannel, // 用户选择的偏好渠道
      context: 're-engagement',
    })
  }
}
 
function daysSinceLastActive(user: User): number {
  return Math.floor(
    (Date.now() - new Date(user.lastActiveAt).getTime()) / (1000 * 60 * 60 * 24)
  )
}

正面做法的核心是「在对的时机用对的渠道」。应用内通知 > 推送 > 邮件,因为用户的注意力在产品里。

实验全流程

下面这个流程图展示了一个增长实验从想法到归档的完整路径。

流程图画布 · 115%
Mermaid 流程图加载中...

指标选择:核心指标和护栏指标怎么搭配

很多团队在实验指标上犯的错误是只看一个数字。转化率涨了,但退款率也涨了;注册多了,但留存没动。护栏指标的作用就是防止这种「按下葫芦浮起瓢」的情况。

实验类型核心指标护栏指标常见误判
引导流程优化引导完成率7 日留存、付费转化率完成率涨但留存没动
定价页改动付费转化率退款率、客服工单量转化率涨但退款也涨
邀请机制调整邀请发送率被邀请人激活率、垃圾举报率邀请量涨但质量下降
推送/邮件策略点击率退订率、通知关闭率点击率涨但用户关掉通知
功能入口调整功能使用率核心流程完成率、错误率新功能入口点了但流程没走完

选指标时有三个原则:

  1. 核心指标要贴近实验假设。你的假设是「7 日留存提升」,核心指标就是 7 日留存,不是 PV 或 DAU。
  2. 护栏指标要覆盖副作用。任何增长手段都可能带来负面效果,护栏指标就是发现这些副作用的雷达。
  3. 不要一次追太多目标。一个实验解决一个问题。如果你同时改了三样东西,你不知道是哪个起了作用。

实验文档模板:每个字段为什么存在

下面是我实际在用的实验文档模板。每个字段都有它存在的理由,后面会解释。

字段说明为什么必须有
实验名称一句话说清实验内容方便归档和检索
负责人谁对这个实验负责避免没人跟进
假设「我们认为「某类用户」在「某个场景」下,如果「做某改变」,那么「某指标」会「提升/降低多少」,因为「某个原因」」没有假设就没有实验
核心指标1-2 个,贴近假设防止指标漂移
护栏指标2-3 个,覆盖副作用防止按下葫芦浮起瓢
样本量最小可检测效应 + 统计功效计算防止样本不足下结论
分组策略按用户 ID / 地区 / 设备分组防止分组污染
时间窗口至少覆盖一个完整业务周期防止工作日/周末偏差
风险与回滚最坏情况 + 回滚方案出问题时不慌
复盘结论继续 / 停止 / 调整 + 学到了什么实验价值在于学习,不在于成功

反面做法——口头约定直接上线

// 没有文档,全靠开会时说的
// 「我们试试改一下按钮颜色,看看转化率有没有变化」
// 两周后:
// - 谁说的改哪个按钮?
// - 看的是哪个转化率?
// - 样本量够不够?
// - 有没有影响其他指标?
// 没人记得清。

正面做法——结构化实验文档

# 增长实验文档
experiment:
  name: 新用户引导流程分场景优化
  owner: 张三
  date_started: 2026-06-01
  date_ended: 2026-06-15
 
  hypothesis: |
    我们认为「首次注册的新用户」在「完成引导流程时」,
    如果「根据其使用场景动态调整引导步骤」,
    那么「7 日留存率」会「提升 8% 以上」,
    因为「用户不再被无关步骤打断体验」。
 
  metrics:
    primary: 7_day_retention
    guardrail:
      - onboarding_completion_rate  # 不能因为分场景而降低完成率
      - paid_conversion_rate         # 不能影响付费
      - support_ticket_count         # 不能增加客服压力
 
  design:
    sample_size: 2000  # 基于 MDE=5%, power=80%, alpha=0.05
    split: 50/50 by user_id
    duration: 14 days  # 覆盖两个完整周
 
  risk:
    worst_case: 留存下降超过 3%,立即回滚
    rollback_plan: Feature flag 关闭,全量恢复旧版引导
 
  result:
    decision: 继续(全量上线)
    findings: |
      7 日留存从 32% 提升到 36%(+12.5%, p < 0.01)
      付费转化率从 4.2% 提升到 4.8%(+14%, p < 0.05)
      客服工单无显著变化
    learnings: |
      分场景引导的关键不是减少步骤,
      而是让用户觉得每一步都跟自己有关。

正面做法的价值在于:三个月后有人问「我们当时为什么全量上线这个改动」,你可以直接翻出这份文档,不用重新推理。

样本量与时间窗口:别在数据不够的时候下结论

样本量计算是增长实验里最容易被跳过的环节。「跑了三天,涨了 2%,上线吧」——这是最常见的错误。

概念含义实际操作
MDE(最小可检测效应)你希望检测到的最小变化幅度通常设为 5%-10%,太小需要极大样本
统计功效(Power)真实存在变化时你能检测到的概率通常设为 80%
显著性水平(Alpha)不存在变化时误判为存在的概率通常设为 5%
基线转化率当前的转化率水平从历史数据获取

一个实用的经验法则:如果你的日活用户不到 10000,MDE 至少设 5%,否则你跑一个月都达不到统计显著。

时间窗口方面,至少覆盖一个完整的业务周期。对大多数 B2B SaaS 来说,这意味着至少两周(覆盖工作日和周末的差异)。如果你的产品有明显的月初/月末效应(比如报销类工具),需要覆盖更久。

反面做法——看一天数据就下结论

# 问题:跑了 1 天就判断胜负
def check_experiment_result(experiment_id):
    data = get_experiment_data(experiment_id, days=1)
    if variant_a.conversion > variant_b.conversion:
        return "A 赢了,全量上线"
    return "B 赢了,全量上线"
 
# 1 天的数据可能有各种偏差:
# - 今天是不是工作日/周末?
# - 有没有大促活动影响?
# - 样本量够不够?

正面做法——基于统计功效计算样本量

import math
from scipy import stats
 
def calculate_sample_size(baseline_rate, mde, power=0.80, alpha=0.05):
    """
    计算 A/B 测试每组所需的最小样本量
 
    baseline_rate: 当前基线转化率(如 0.32 表示 32%)
    mde: 最小可检测效应(如 0.05 表示 5 个百分点)
    power: 统计功效,通常 0.80
    alpha: 显著性水平,通常 0.05
    """
    p1 = baseline_rate
    p2 = baseline_rate + mde
 
    z_alpha = stats.norm.ppf(1 - alpha / 2)  # 1.96
    z_beta = stats.norm.ppf(power)             # 0.84
 
    numerator = (
        z_alpha * math.sqrt(2 * ((p1 + p2) / 2) * (1 - (p1 + p2) / 2))
        + z_beta * math.sqrt(p1 * (1 - p1) + p2 * (1 - p2))
    ) ** 2
    denominator = (p2 - p1) ** 2
 
    return math.ceil(numerator / denominator)
 
# 示例:基线 32%,想检测 5% 的提升
sample = calculate_sample_size(baseline_rate=0.32, mde=0.05)
# 结果:每组约需 1475 个样本
# 如果日活 2000,50/50 分组,大约需要 7-8 天

正面做法的关键是「在实验开始前就算好需要多少样本、需要跑多久」,而不是「跑了几天看看差不多就下结论」。

复盘:失败实验的价值怎么体现

实验复盘不是走形式。一个失败的实验如果记录得好,比一个成功的实验更有价值——因为它告诉你「此路不通」,避免了团队重复踩坑。

复盘文档应该包含三个部分:

  1. 决策——继续(全量上线)、停止(下线改动)、调整(修改方案重跑)
  2. 发现——数据告诉了你什么,是否符合预期
  3. 学习——如果重做一次,你会怎么改
实验结果复盘重点归档标签
成功(指标显著提升)为什么有效、能不能复制到其他场景success, scale
失败(指标下降或无变化)为什么无效、假设哪里错了failed, learning
不确定(样本不足或干扰太多)实验设计有什么问题、下次怎么改inconclusive, redo
有副作用(核心涨但护栏报警)副作用是否可接受、能否 mitigatingconditional, risk

反面做法——复盘只写一句话

// 「实验结束,转化率提升 2%,全量上线。」
// 问题:
// - 2% 是统计显著的吗?
// - 有没有影响其他指标?
// - 下次遇到类似场景能参考什么?
// 这种复盘等于没做。

正面做法——结构化复盘

实验名称:新用户引导流程分场景优化
决策:继续(全量上线)
 
数据发现:
- 7 日留存:实验组 36% vs 对照组 32%(+12.5%, p=0.003)
- 付费转化率:实验组 4.8% vs 对照组 4.2%(+14%, p=0.041)
- 客服工单:无显著差异(p=0.72)
 
假设验证:
- 假设成立。分场景引导确实减少了无关步骤对用户体验的打断。
- 但效果来源不是「步骤减少」(实验组平均步骤数与对照组相同),
  而是「步骤相关性提升」。
 
学习:
- 「减少步骤」和「提升每步相关性」是两回事,
  前者容易做到但效果有限,后者更难但价值更高。
- 下一步可以测试:在每步引导中加入「为什么需要这一步」的解释文案。

增长实验检查清单

一、实验设计阶段

  • 假设是否用「我们认为「谁」在「什么场景」下,如果「做什么改变」,那么「什么指标」会「变化多少」,因为「什么原因」」的格式写清楚了
  • 核心指标是否只选了 1-2 个,且直接对应假设
  • 护栏指标是否选了 2-3 个,覆盖了可能的副作用
  • 是否用 ICE 评分做了优先级排序,而不是靠会议讨论
  • 样本量是否用统计功效公式计算过,而不是拍脑袋

二、执行阶段

  • 分组策略是否避免了分组污染(同一用户不会看到两个版本)
  • 时间窗口是否覆盖了至少一个完整业务周期
  • 是否有 Feature Flag 或回滚方案,最坏情况下能在 30 分钟内下线
  • 是否设置了自动报警:核心指标下跌超过 X% 自动停止实验

三、复盘阶段

  • 是否等到统计显著才下结论,而不是看了一天数据就上线
  • 复盘文档是否包含「决策 + 发现 + 学习」三部分
  • 实验结论是否归档到团队知识库,方便后续查阅
  • 失败实验是否也记录了「此路不通」的原因,避免重复踩坑

模板不是目的,学习才是

增长实验模板的价值,不是让你填完表就可以上线了。它的价值是让团队对「我们在赌什么」「怎么判断赌对了」「赌错了怎么办」这三个问题有共识。

没有模板的团队,增长动作靠拍脑袋。有模板但不认真填的团队,增长动作靠走形式。真正把模板用好的团队,每一次实验——不管成功还是失败——都变成了团队可以复用的知识。

从下一次产品周会开始,当有人说「我们试试改一下 XXX」的时候,先问他一句:「你的假设是什么?」

参考资料

评论 0

0 / 1000