你需要采集的三类量化数据

美国管理学大师爱德华兹·戴明曾写道：“无法测量的东西也就无法提升。”显然 他是对的。再进一步讲，如果你辛苦了一年去提升某个产品的某些客户的使用周期，

但到头来你无法量化业绩，你凭什么能晋升呢？如果你意识到无法晋升，在没有任何 拿得出手的业绩的情况下你又凭什么能找到一份新的工作呢？

如果想在未来证明你的业绩，你需要事先准备一根基准线。因此你必须尽早确立 指标并在产品开发过程中不断更新。确立基本指标并不困难，比如说工程团队的执行 能力就是一个基本指标。

执行力可以通过考察产品能否在你要求的日期内发布来衡量。你的发布时间通常 取决于待修复的Bug 数量。很多 Bug 跟踪系统能够生成发现 / 修复率和 Bug 数量趋势 图。因此综合发现/ 修复率和 Bug 数量你可以预测“零 Bug”到达日期。要了解更多 有关如何生成该指标数据以及它为什么这么重要的内容，请参考4.3 节。

零Bug 到达日期是一个优秀的反映开发进度的指标：它几乎没有获取成本（大部 分Bug 跟踪系统都能免费提供该数据），它可靠且可重复，它能实时更新，它能为团 队指明方向。在后面这个例子中，如果你让团队分心去实现你的一些“卓越的想法”，

你的发现/ 修复率就会下降，发布就会延期。因此要想尽快发布产品你就应放弃那些

“卓越的想法”。

产品发布后你可能需要更换指标，因为你新引入了一个重要的数据源：客户及其 行为数据。你需要借助基于它们的指标数据来向投资方或管理层汇报，形成产品发展 策略，并指导你的团队。下面列举了三类发布后需要跟踪的关键指标：目标进度、经

a “适应性函数”也叫“评价函数”，是遗传算法中判断群体中个体优劣程度的指标。——译者注

营绩效和系统性能。

6.2.1  目标进度

目标指标会告诉你目标的完成进度。在谷歌一个重要的目标指标是“7 天活跃用 户数”。它是指近7 天使用产品的独立用户数。这个指标比那些廉价的网站分析套装 中经典的“日均独立用户数”要靠谱得多，它反映了产品当前的状态，你可以拿它同 上周、上上周进行对比。它还比日均用户数更为合理，因为你很少会做一个预期人们 会每天使用的产品。

如果你确实在做一个预期人们会每天使用的产品，那么比较单天活跃用户数和 7 天活跃用户数之间的差额也是很有意义的。举个例子，我曾经负责面向 Microsoft Outlook 的 Google 插件，产品全名为面向 Microsoft Outlook 的 Google Apps 同步插件 TM。我们预期除非这个软件没做好，否则使用 Outlook 的客户应该会每天检查他们的 邮件。因此我们密切关注7 天活跃用户数与单天活跃用户数之比。如果你提供的是一 个像“照片打印”这类用户不会频繁使用的服务，你可以更关注“30 天活跃用户数”

一些。

你还可以跟踪如利润、注册量、下载量或安装量等目标指标。

这个时候你可能想，“目标这个我都懂，不就是满足SMART 原则嘛！”什么是 SMART 原则？不久前一些“业内砖家”提出目标应该具体、可量化、可到达、合理 以及具备时效性。这个框架看起来不错但不够具体，我更喜欢精确增量表达法（Great Delta Convention，第 10 章有详述）。没有人会看不懂使用精确增量表达法来描述的目 标，而且这样的描述基本符合SMART 的定义（除了缺少了“合理”这点）。

6.2.2  经营绩效

经营绩效指标会告诉你产品的问题在哪里以及如何提升用户体验。这些指标通常 是用比率表示，比如从点击购买按钮到付款成功的转化率。和目标指标一样，选择合 适的经营绩效指标至关重要。比如说你想做一个优秀的社交产品，监控好友数量是没 有用的，不同类型的用户有不同的好友数。你应该去监控用户参与度，这样你才能回 答“用户会花费时间在网站上吗”、“用户会发信息吗”这类问题。反映这些行为的相 关指标可能包括7 天活跃用户平均 7 天发帖量、7 天活跃用户平均停留时间等。

埃里克·莱斯在他的《精益创业》一书中并不推崇那些总是在增长的指标。他称 它们为虚荣指标，因为即使新用户的流失率高达90%，你也可以昂首挺胸指着一路上 涨的图表向大家宣布：“我们太了不起了，我们的产品正在成长！”莱斯的观点很客观。

这也是为什么你要关注转化率、参与度等指标的原因。几乎所有的网站数据分析套装 中都会直接提供转化率相关的指标，它们还会告诉你哪组用户使用过哪些特性以及点 击过哪些按钮。

另一个避免“虚荣”指标的方法是衡量应用中改动带来的影响。最好能让改动前 和改动后两个版本横向而不是纵向对比测试，因为纵向的分析常常会被其他因素影响 以至于你可以轻松地宣称：“看，我们的产品用户仍在增长！”Google 分析提供了极其 强大的A/B 对比工具，不过这只是很多有用的工具中的一种。大多数主流网站都有一 套支持灰度发布特性的测试框架，它能确保新的特性或者体验达到预期的效果。因此 只要有一丝可能你都应该尝试在项目一开始就构建一套实验性的框架（参考第7 章关 于实验性发布的其他好处的讨论）。

6.2.3  系统性能

系统性能指标能说明你产品的实时健康度。这类指标包括99.9% 平均延迟、每 秒请求数、并发用户数、每秒下单数以及其他基于时间的指标。如果这些指标大幅下 降，那么一定有什么地方出了问题，你也许需要下线一些程序。

你还可以天马行空地从统计过程控制（SPC，Statistical Process Control）的视角来 考察你的指标。爱德华兹·戴明是最早推广使用 SPC 来精确测量一个指标的正常下降 范围的人之一。他在20 世纪 20 年代从沃尔特·休哈特那里学到了这个东西。戴明假 设你的系统存在一定的波动，伴随着波动存在一个可以接受的系统变化范围。在这个 范围内的波动被认为是正常变化或I 型误差。

系统还会有一些持续一小段时间的不良的尖峰波动，戴明称它为异常变化或II 型 误差。一次错误的推送或者一个丢失了虚拟IP（VIP）的服务器可能会引发这样的尖 峰波动。

你可以忽略正常误差或正常波动，即误差或波动落在平均值的正负标准误差区间 内。标准误差是指你的数据的平均值的标准偏差。如果单个数据点落在平均值的正负 标准误差区间之外，你就得呼叫技术主管了。