《互联网产品的服务端架构·交易、增长与平台化》附录 B 实验与指标口径

指标争议大多不是算错，而是分子分母、时间窗口、去重口径三者中至少有一个没说清。本附录把卷三用到的指标与实验口径列成表，供评审与对账时直接引用。

口径三要素

任何指标在写进报表之前，必须回答三个问题：

1. 分子是什么？ 事件、用户、订单，还是金额？
2. 分母是什么？ 同一批人、同一时间窗，还是全体？
3. 去重与归属怎么算？ 按用户去重、按订单去重，还是按设备去重？

三个问题没答完，指标名就只是一个词，不是口径。下面每张表都按这三要素展开。

流量指标

流量指标看似简单，实际最容易口径打架，因为「一次访问」在不同端有不同定义。

「新用户」至少有三个口径：首次安装、首次注册、首次下单。增长团队关心首单，市场团队关心安装，产品团队关心注册。报表里必须写明用的是哪一个，否则同一个「新增」在不同看板上能差一倍。

跨端去重需要统一 ID。没有登录态时用设备 ID，登录后用账号 ID，并在登录时做一次归并。归并规则要写进口径文档，不能靠分析师个人习惯。

转化指标

转化率的分母决定了它回答什么问题。

转化率必须带窗口。「7 日转化率」和「当日转化率」不是同一个指标。跨天归因时，分子的事件可以发生在分母之后，只要在窗口内。

支付成功率不要只看总数。按渠道、金额段、机型分桶后，经常会出现「总体 96%，某渠道 71%」的情况。总体好看，是因为该渠道占比小。

留存指标

留存的定义比转化更容易被误读，因为「第 N 日」有两种算法。

两种日留存算法在跨时区、跨夏令时的时候会差一天。实验里用滚动 24 小时，报表里用自然日，两者不能混着比较。

留存曲线要看到平台期。只报「次日留存 40%」没有意义，因为不知道第 30 日会掉到 5% 还是 25%。平台期决定了产品的长期价值。

交易指标

交易指标是财务与业务共同关心的部分，口径必须与对账系统一致。

GMV 是最容易被滥用的指标。含未支付订单的 GMV 可以虚高 20% 以上；含退款不扣减的 GMV 在退货率高的品类会严重失真。报表里必须写明「GMV 口径：创建订单 / 支付订单 / 净额」。

退款率要区分「订单退款率」与「金额退款率」。一笔大额订单退款，订单退款率只涨一点，金额退款率可能涨很多。

履约时长要看分布，不能只看均值。均值 12 小时可能意味着 80% 的订单 2 小时发货、20% 的订单 3 天没动。

增长指标

增长指标回答「拉来的人值不值」，需要成本与收入两侧。

LTV 不是实测值，是模型输出。它依赖留存曲线、ARPU 与折扣率三个假设。把 LTV 写成「实测」是常见的夸张，正确写法是「按当前留存与 ARPU 估算」。

裂变系数 K 要拆成「邀请率 × 接受率」。K 下降时，先看是没人愿意邀请，还是邀请了没人接受，两者的解法完全不同。

实验指标

实验指标与业务指标不同：它需要对照、需要显著性、需要防多重比较。

分流单元的粒度决定了实验能回答什么问题。按请求分流适合无状态策略，按用户分流适合有累积效应的策略（例如推荐、会员）。按设备分流在跨端产品里会造成同一用户被分到两组。

实验开始后不要改分流规则。改规则等于换实验，之前的样本作废。要改就停掉重开，并记录原因。

样本量估算

样本量不足是实验最常见的失败原因。粗略估算可以用下面的公式：

每组样本量 n ≈ 16 × p × (1 − p) / Δ²

其中 p 是基线转化率，Δ 是希望检测到的最小绝对提升。系数 16 对应约 80% 功效、95% 置信度的双侧检验，适合快速估算。

举例：基线转化率 10%，希望检测到 1 个百分点的提升，则：

n ≈ 16 × 0.1 × 0.9 / 0.01² = 14400

每组约 1.44 万样本，两组接近 3 万。如果日活只有 5000，实验至少要跑 6 天，还要考虑周内波动，通常跑满 7 天。

这个公式是近似值，正式实验应该用统计工具按实际指标方差计算。它的价值在于：在实验开始前就能判断「这个实验根本跑不出来」，避免浪费两周。

提升越小，需要的样本量越大。检测 0.1 个百分点的提升，样本量是检测 1 个百分点的 100 倍。这就是为什么小流量产品做不了精细实验。

显著性怎么读

p 值小于 0.05 只说明「在零假设下，观察到这种差异的概率小于 5%」，不说明「新策略更好」，更不说明「提升幅度是真实的」。

读实验结果时按顺序检查：

1. 样本量是否达到计划值？中途查看过几次？
2. 主指标与护栏指标分别怎样？
3. 置信区间是否跨过 0？
4. 分群结果是否一致，还是只有某个小分群显著？
5. 实验期间有没有发布、活动、故障等外部干扰？

中途反复查看会抬高假阳性率。看了 5 次就停，实际显著性阈值应从 0.05 收紧到 0.01 左右。规范做法是事前定好样本量与停止规则。

「显著但幅度很小」的实验，要结合成本判断。转化率提升 0.2 个百分点，如果改动带来维护成本，可能不值得上线。

多重比较

同时看 10 个指标，至少有一个「显著」的概率接近 40%。这不是策略有效，是统计必然。

控制方法有三种：

• 事前指定一个主指标，其余只作参考。
• 分组校正：把指标按业务域分组，每组只取一个代表。
• 校正阈值：用 Bonferroni 或 Benjamini–Hochberg 调整 p 值。

最简单也最有效的是第一种：一个实验只承诺一个主指标。主指标不显著，就认为实验失败，不管其他指标多好看。

护栏指标不参与多重比较校正，因为它们的目的是「发现变差」，宁可误报也不可漏报。

口径变更流程

口径不是永恒的。业务变化、数据源变化、统计方法变化都会导致口径调整。变更需要流程，否则历史数据无法比较。

口径文档至少包含：指标名、分子、分母、窗口、去重规则、数据源、负责人、生效日期、历史版本。缺一项，半年后就没人说得清这个数字是怎么来的。

归因口径

增长指标里的「带来了多少」几乎都涉及归因。归因不是事实，是规则。

同一个渠道，用首次触点算可能 ROI 很高，用末次触点算可能为负。渠道团队与财务团队为此吵架，多半是模型没写清楚，而不是数据错了。

归因窗口也要固定。7 天窗口与 30 天窗口下，同一个渠道的贡献能差一倍。窗口一旦定下，历史对比必须使用同一窗口。

自然流量与付费流量的边界同样需要规则。用户先看广告、三天后搜索品牌词下单，这单算付费还是自然？规则要事前写，不能月底按结果调整。

指标字典模板

一个可用的指标字典条目至少包含下面这些字段：

「排除项」是最容易被漏掉的一栏。测试订单、刷单、风控拦截如果不排除，小体量业务的支付成功率会剧烈波动。

指标字典应该和数据仓库的模型定义放在一起，最好能从字典直接生成 SQL 或语义层配置。手写 SQL 与文档各维护一份，迟早分叉。

报表与监控的一致性

同一个指标，报表里一个数，监控里另一个数，是最消耗信任的问题。

常见原因有三种：

• 时间归属不同。 报表按事件时间，监控按写入时间，延迟数据落在不同天。
• 过滤条件不同。 报表排除了测试账号，监控没排除。
• 聚合粒度不同。 报表按支付单去重，监控按回调次数计数。

解决方式不是「以哪个为准」，而是让两者共用同一份指标定义与同一张中间表。监控可以加窗口、加阈值，但不应该重新定义分子分母。

对账类指标尤其如此。财务对账的差异率、支付成功率、退款率，应该来自同一套明细，只是聚合方式不同。

实验复盘记录

一个实验结束后，无论成败，都应该留下一份可检索的记录：

复盘记录的价值在于「下次遇到类似问题能查到」。没有记录，同一个假设会被不同团队反复实验，浪费流量。

记录里要写「没做成什么」，而不只是「做成了什么」。失败的实验同样有信息量，尤其是「样本量不足」和「护栏指标变差」这两类。

常见口径错误

• 分子分母不同源。 分子来自埋点，分母来自订单库，两边用户 ID 对不上。
• 时间窗口不对齐。 分子按支付时间，分母按下单时间，跨天订单被算两次。
• 去重键选错。 用设备 ID 去重，同一用户换机后被算成两个新用户。
• 把预估写成实测。 LTV、增量收入、归因收益都是模型输出，不能标「实测」。
• 只报均值。 履约时长、客单价、响应时间都要看分布。
• 实验中途改规则。 分流、埋点、指标定义任一变化，都应视为新实验。
• 忽略外部干扰。 大促、故障、竞品事件都会污染实验，需要在报告中说明。
• 口径散落在代码里。 没有文档，只有 SQL；换个人就重写一遍，数字对不上。

这些错误的共同点是：单个数字看起来都合理，放在一起就矛盾。评审指标时，先问「分子是什么、分母是什么、窗口多长」，比看数字本身更有用。