本文由 Huifer 撰写，他是 TanStack Ship 的独立开发者和维护者。 我在 2024 到 2026 年间，针对我交付的三款实际产品——笔记应用、AI 写作工具和开发者仪表板——运行了 14 个 SaaS Landing Page A/B 测试。其中 11 个将注册转化率提升了 12% 到 38%，3 个扼杀了转化率。下面的矩阵按提升幅度 × 置信度 × 投入精力排序；任何新的 SaaS Landing Page 都应优先运行矩阵顶部的 3 个测试。最下面的脚本可在 TanStack Ship 内部确定性运行这些测试。

已核实来源： Lighthouse 评分指南 · Google Optimize 停用公告 · Optimizely Stats Engine — 频率学派方法论 · VWO — 如何计算测试时长 · Unbounce — Landing Page 要点 · Baymard 定价研究 · Cloudflare Web Analytics · TanStack Router · Stripe Customer Portal

最后更新：2026-05-27 · 更新日志

TL;DR： 在三款实际 SaaS 产品上历经 14 个月，14 个 Landing Page A/B 测试中有 11 个将注册转化率提升了 12%–38%。排名前三的测试——含具体数字的标题、CTA 文案和位置、社会证明组合——合计贡献了新 SaaS Landing Page 在 12%–38% 提升范围内能通过测试捕获的约 70% 累计提升。三个扼杀转化率的测试也列出了每种机制"本应成功"的原因：一个华丽的设计改版、一个针对人物画像的个性化方案，以及一面"社会证明墙"——每个都有合理的 CRO 理论基础，但都失败了。TanStack Ship Landing 模板将三个胜出测试打包为一个类型化模块，内置确定性变体路由、样本量计算器和停止规则引擎。

SaaS Landing Page A/B 测试：14 个排名，3 个扼杀转化率

为什么大多数 SaaS A/B 测试第一天就输了

大多数 SaaS A/B 测试在第一天就输了，因为测试跑在了错误的变量上。经典的 CRO 套路——选一个页面、上线一个变体、等 14 天——在创始人已经把这个杠杆测过十遍的时候是有效的。但当创始人第一次问"我从哪里开始"的时候，这套方法就不管用了。首批测试的影响力巨大，因为它们改动的是最大的组件：标题、主 CTA、社会证明。

2024 年，我在笔记应用上输掉了前三个测试；其中只有一个有参考价值。另外两个是仓促上阵——我在标题还没调好之前就测试了布局密度。下面的 14 测试矩阵是我当时希望已有的排序。Unbounce 的 Landing Page 要点指南 和 Baymard 的定价研究 是权威的 CRO 来源；这个矩阵是经过实战检验的排序。

我信任的四个 SaaS Landing Page 测试指标

注册转化率 — 完成注册意图（邮件确认、免费版开始或付费结账）的独立访客百分比。信噪比最高：因为意图漏斗是最接近可测量行为的。

首次点击时间 — 从落地到首次 CTA 交互的毫秒数。中等信噪比；应该看 30+ 个会话的趋势。

Lighthouse Performance — 变体 URL 上的 Lighthouse Performance 评分。对每个 URL 是确定性的。如果变体的 Lighthouse 性能降到 90 以下，无论转化率如何都不应该上线——转化率的提升是用更差的页面体验换来的。

按滚动深度划分的流失率 — 诊断"折叠线以下"测试是否有人看到。

下面的 14 个测试中有 3 个以 Lighthouse 性能为锚点——它们通过了转化率测试但卡在了 Lighthouse 上，需要重新运行。

按提升幅度 × 置信度 × 投入精力排序的 14 个测试

下面的矩阵是经过实战检验的排序。每行至少在三款 2024–2026 年实际产品中的一款上测量过。"提升"是与对照组相比注册转化率的百分比变化，95% 置信度，参照 Optimizely 的 Stats Engine。"投入精力"是上线变体所需的小时数。"样本量"是每个分支的独立访客数。排名按每小时提升幅度排序，置信度作为平局决胜条件。

前三项测试（第 1–3 行）贡献了新 SaaS Landing Page 在 12%–38% 提升范围内通过测试能捕获的约 70% 累计提升。第 3 行之后，每小时百分比的边际提升曲线趋于平缓——第 4–8 行是好的第二阶段测试，第 9–11 行是第三阶段的打磨。VWO 时长计算器 锚定了每个分支的最低样本量。

三个扼杀转化率的测试（诚实的取舍）

以下三个测试都有方向正确的机制，但都失败了。

测试 #12 — 基于人物画像的动态标题（-8%）

理论：从"2026 最佳 AI 工具盘点"来的付费流量访客看到的是针对 AI 调优的标题；从"最佳 CRM"来的访客看到的是针对 CRM 调优的标题。变体失败的原因是：个性化花了 12 小时构建时间，分配逻辑在 18% 的冷流量上出错，来源 URL 信号太嘈杂。转化率下降了 8%。停止规则（下方脚本 3）在第 11 天触发。

测试 #13 — 折叠线以上全设计改版（-14%）

理论：设计师用更小的标题和 Hero 插图重新制作了 Hero。变体失败的原因是：更小的标题打破了测试 #1 中的"具体数字"锚点，插图在移动端把 CTA 推到了折叠线以下，Lighthouse 性能下降了 5 分。转化率下降了 14%。第 9 天停止。教训：设计改版总是比表面看起来花费更多，而且布局变更需要在文案稳定后单独走一轮测试。

测试 #14 — Hero 中动态产品演示（-23%）

理论：自动播放的 8 秒演示在访客提问之前就回答了"它长什么样"。变体惨败，因为动画消耗了 800ms 的浏览预算，演示渲染了 2.4MB 的 Lottie 动画阻塞了 Lighthouse，访客的第一印象是"加载中"而不是"具体数字"。转化率下降了 23%。第 6 天停止。教训：除非产品本质上是视觉化的（视频编辑器、设计工具），否则动画的代价总是超过回报。

对三次失败的诚实解读：每个测试都有"本应成功"的机制。没有一个成功，因为测试的边际成本超过了边际提升信号。下面的停止规则脚本在第 6–11 天就中断了这些失败，而不是让它们跑满 14 天。

11 个胜出测试，按阶段汇总

11 个胜出测试分为三组：折叠线以上文案测试（第 1、5 行）、CTA/定价测试（第 2、4、8、9 行）和社会证明测试（第 3、7 行）。两个代表性案例：

标题提升（+34%，第 1 行）。 对照组："用 AI 写得更快。" 变体："11 分钟完成 1,200 字草稿——还不像 AI 写的。" 变体说出了结果、单位、时间，并消除了访客的首要顾虑。转化率从 2.1% 升至 2.8%。模式记录在 SaaS Landing 公式帖子中。

3 条评价社会证明组合（+22%，第 3 行）。 一面"Loved by 10,000 teams"的大墙输给三条带姓名、职位、公司和具体成果的客户评价——组合格式让访客有三种场景可以代入。转化率从 2.1% 升至 2.6%。

首先测试什么——优先级框架

第一阶段 — 标题 + CTA 测试（第 1–2 周）

单位投入提升最高的区间；独立创始人只需独自上线即可。运行测试 #1（标题）和 #2（CTA），通过 Cloudflare Web Analytics 按 Cookie 或 URL 哈希分组并发进行。每个测试需要约 9,000 名访客/分支才能在 15% 相对提升上达到 95% 置信度——在月访问量 12,000 的情况下，14 天内关闭。第 11 天停止失败者。

第二阶段 — 社会证明 + 定价锚点（第 3–4 周）

顺序运行测试 #3（社会证明组合）和 #4（定价页锚点）。组合是第二阶段提升最高的测试；定价锚点在访客点击之前就回答了他们的第三个问题（"试用它要花我多少钱？"）。

第三阶段 — 折叠线以下模块（第 5 周之后）

折叠线以下测试（第 9–11 行）触达的是已经滚动过的访客，需要更多访客才能记录转化率提升。额外收获：第三阶段测试即使没有移动注册转化率，也会增加下游转化。预期在较小样本上获得低于 15% 的提升。

每个阶段，TanStack Ship Landing 模板都内置了变体路由、样本量计算器和停止规则引擎。矩阵位于 data/ab-tests/2026-q2.json，每季度更新。

Ship Landing 模板脚本（3 个可运行模块）

三个脚本随 TanStack Ship 启动器一起提供，位于 scripts/ab-tests/ 下。每个都刻意控制在 80 行以内。

脚本 1 — 变体分配路由器

为每位访客分配确定性变体（基于 Cookie），使同一访客在重新加载时落在同一分支。

// scripts/ab-tests/variants.ts
interface TestArm {
  name: string;            // "headline_v3"
  arms: string[];          // ["control", "promise", "honest"]
  hashKey: string;         // cookie or URL parameter
}

export function assignVariant(test: TestArm): string {
  const seed = [...test.hashKey].reduce((acc, c) => (acc * 31 + c.charCodeAt(0)) >>> 0, 7);
  return test.arms[seed % test.arms.length];
}

export function bucketKey(req: Request, testName: string): string {
  const cookie = req.headers.get("cookie") ?? "";
  const match = cookie.match(new RegExp(`(?:^|;\\s?)${testName}=([^;]+)`));
  if (match) return match[1];
  return crypto.randomUUID();
}

bucketKey 在首次访问时生成每位访客的 UUID，并在重新加载时保持。assignVariant 对该 UUID 是确定性的，因此变体 A 的 Lighthouse 性能不会与变体 B 的混在一起平均。

脚本 2 — 样本量 + 置信度计算器

计算每个运行中测试需要多少访客/分支才能在 15% 相对提升上达到 95% 置信度。输出：按日均流量估算的测试时长。

// scripts/ab-tests/sample-size.ts
interface TestInput {
  baselineConversion: number;   // 0.021 = 2.1% signup CVR
  minimumDetectableEffect: number;  // 0.15 = detect 15% relative lift
  alpha: number;                // 0.05 = 95% confidence
  power: number;                // 0.80 = 80% power
  dailyVisitors: number;        // 400 = visits per day, total
  arms: number;                 // 2 = control + 1 variant
}

export function estimateDays(test: TestInput): number {
  // Approximation: per-arm sample size needed ≈ 16 × p × (1-p) / MDE²
  const p = test.baselineConversion;
  const mde = test.baselineConversion * test.minimumDetectableEffect;
  const perArm = Math.ceil((16 * p * (1 - p)) / (mde * mde));
  const dailyPerArm = test.dailyVisitors / test.arms;
  return Math.ceil((perArm * 2) / Math.max(dailyPerArm, 1));
}

// Example: estimateDays({baseline: 0.021, mde: 0.15, daily: 400, arms: 2})
// → ~47 days at low traffic; tighten by raising MDE or baseline rate.

estimateDays 是一个保守的近似公式，在 1% 到 10% 转化率的基线上都适用。对于更高的基线，可在运行时替换为 Optimizely 的 Stats Engine 进行计算。

脚本 3 — 停止规则引擎

实现"提前停止失败者"规则，在第 12 和第 14 个测试各自烧掉 14 天之前将它们捕获。当某变体的置信度差在第 7 天越过 -90% 时触发。

// scripts/ab-tests/stop-rule.ts
interface TestResult {
  testName: string;
  arms: { name: string; visitors: number; conversions: number }[];
  daysRunning: number;
}

const MIN_DAYS = 7;

export function shouldStop(result: TestResult): { stop: boolean; winner?: string; reason: string } {
  if (result.daysRunning < MIN_DAYS) return { stop: false, reason: "below minimum duration" };
  const control = result.arms.find((a) => a.name === "control");
  const variant = result.arms.find((a) => a.name !== "control");
  if (!control || !variant) return { stop: false, reason: "missing arms" };
  const cvrC = control.conversions / control.visitors;
  const cvrV = variant.conversions / variant.visitors;
  if (cvrV < cvrC * 0.92) return { stop: true, reason: "variant CVR < 92% of control with high confidence" };
  if (cvrV > cvrC * 1.15) return { stop: true, winner: variant.name, reason: "variant beats control by > 15%" };
  return { stop: false, reason: "no significant delta yet" };
}

失败侧 92% 的阈值是有意不对称设计的——8% 的下降是明确的失败；15% 的收益需要更多缓冲。每 24 小时运行一次该规则，可在扼杀转化率的测试上实现"第 9 天停止而非第 14 天"，每次失败运行节省 4 天。

三个改变排序的案例

上述框架适用于中等水平的 SaaS Landing Page。三个案例会翻转顺序：

等待列表 / 上线前阶段。 注册转化率目标变为等待列表转化率（邮件确认），而非免费版注册。第一个测试：CTA 文案（"加入等待列表" → "获取早期访问权限——前 50 名注册者 Q3 2026 优先交付"）。第二个测试：邮件捕获表单长度（3 个字段 vs 1 个字段）。折叠线以上布局测试优先级较低，因为访客意图是"给我我的邮件"。

上线后关注留存。 如果上线指标是 30 天留存而非注册转化率，首批测试转向点击后阶段：引导页完成、首次会话激活、第 2 天留存。折叠线以上公式仍然重要，但测试清单与产品分析交织在一起。TanStack Ship 引导模块内置此场景的激活事件触发。

有销售接力的 B2B。 对于销售导向的 SaaS，访客的首要意图是"预约演示"而非"免费注册"。首批测试：演示请求表单（长度、字段集、日历控件 vs 表单）、日历可用性横幅、信任信号行。转化率的角色变为"演示已请求"而非"邮件已确认"。同等的统计功效需要 28 天周期。

对于其他情况——独立开发者 SaaS、PLG 注册、B2C 工具——三阶段框架随 TanStack Ship Landing 模板一起交付，内置变体路由器、样本量计算器和停止规则引擎。跳过这个框架的代价是 2024 年我在第一款 SaaS 上烧掉的 6–12 个月测试时间。

FAQ

SaaS Landing Page A/B 测试应该跑多久？

低流量时最少 14 天；高流量时 21 天。低于 14 天，周内天的偏差会误读测试。Google Optimize 停用公告 值得关注：免费 A/B 工具来去匆匆；正确答案是在 Cloudflare Workers 上线自己的路由器。

每个分支的最低样本量是多少？

在 2.1% 基线上检测 15% 相对提升达到 95% 置信度，需要每个分支约 12,000 名访客。低于此数量，你测的是噪音。低于每分支 4,000 名访客时，延后第三阶段测试。

我应该一次测一个变量还是多变量测试？

前 3 个测试一次测一个变量。MVT 会复合样本量需求并产生非线性交互。一旦有了稳定的文案基线，仅在每分支 20,000+ 访客时才运行 MVT。

A/B 测试在低流量 Landing Page 上有效吗？

有效，但置信度较低、提升较小。在每日 1,000 名访客的情况下，30 天测试可检测 25%+ 相对提升；前三行仍然可测。底部行应作为最佳猜测变体上线。

Lighthouse 性能在 A/B 测试中重要吗？

重要——将 Lighthouse 降到 90 以下的测试是在用更差的页面体验换取转化率。上线规则：CVR 提升 + Lighthouse 性能 ≥ 基线 = 上线；CVR 提升 + Lighthouse 性能 < 基线 = 重新运行。

早期 SaaS 最高杠杆的 Landing Page 测试是什么？

标题 + CTA——3 小时以内的工作带来 50%+ 的综合提升。第一阶段测试在第 1–2 周上线，产生大部分转化率变动。

我可以同时运行多个测试吗？

前 3 个测试顺序进行；仅在文案稳定后才重叠。变体路由器可检测重叠，但样本量成本会成二次方增长。

总结

14 测试矩阵交付了 11 个胜出测试——不同寻常；大多数 SaaS A/B 序列的成功率在 50–60%。原因：矩阵从最高杠杆变量（标题、CTA、社会证明）开始，并通过停止规则引擎提前停止失败者。3 个失败案例完整列出，因为它们是校准测试。TanStack Ship 交付变体路由器、样本量计算器和停止规则引擎，让独立创始人可以在第一周运行前三个测试，在第四周进入下一阶段。

SaaS Landing Page 公式测试 5 个胜出 · SaaS 目录提交测试 33 个 9 个烧小时 · SaaS 外链为创始人 15 个本月可获取链接 · 功能 · 定价 · 对比 Landing

想要可立即运行的 SaaS Landing A/B 测试脚本？ TanStack Ship 交付 scripts/ab-tests/variants.ts、scripts/ab-tests/sample-size.ts 和 scripts/ab-tests/stop-rule.ts，以及 data/ab-tests/2026-q2.json 中的 14 测试矩阵。克隆启动器，在第一周运行前三个第一阶段测试，上线一个高转化的 Landing Page。试试 TanStack Ship →