活跃用户的定义会改变数字
一句话总结
DAU、WAU、MAU 在确定下面三件事之前都不算数字：“做了什么的人算活跃”“是哪个时区的一天”“排除谁”。而产品团队每周看的数字（North Star），统计的不应是登录数，而应是客户获得价值的行为。
为什么需要它
一个小团队在融资会议的前一天截下了仪表板。MAU 比上个月涨了 20%。但这 20% 中相当大一部分是公司内部账户——开发、设计、销售每天都为了演示而登录。另一个团队把“活跃”的定义从“登录”改成“任意事件”的那一周，指标一下子跳了上去。因为仅仅是打开推送通知，也会记录一个事件。这两种情况下，计算都没有错。只是没有写下定义。
创业早期，要用这些数字决定招聘、融资和功能优先级。定义一变，趋势就会说谎，而相信这个趋势所做的决定，很难撤回。所以指标应当像代码一样先写下定义，并用该定义重新计算，确认得出相同的数字。
工作原理
要定义一个指标，至少要填满下面四栏。
| 栏 | 本实验的定义 | 经常出现疏漏的位置 |
|---|---|---|
| 什么 | session_start 至少 1 次 |
如果设为“任意事件”，打开通知、自动同步就会混进来 |
| 谁 | 排除 is_internal = 1 |
内部、测试账户每天登录，会把底线抬高 |
| 何时 | Asia/Seoul 日期，一周从星期一 00:00 开始 | 如果按 UTC 日期归组，上午 9 点之前的活动会被算到前一天 |
| 多少 | 人数（去重） | 如果统计事件数，一个人登录十次也会变成十个人 |
DAU、WAU、MAU。DAU 是当天活跃的人数，WAU、MAU 是包含基准日在内向前回溯 7 天、28 天内至少活跃过一次的人数。使用 28 天的原因，是日历上的一个月有 28–31 天，所以月度比较会受星期构成的影响——28 天的窗口，无论何时测量，每个星期几都恰好出现四次。本实验就这样定义，如果你的组织使用 30 天，只要把这个定义写下来就行。重要的不是用哪一种，而是不要变。
粘性（stickiness）。这是用来看“在一个月内至少来过一次的人中，工作日的一天有多少人来”的比率。本实验用截至基准日的 28 天内 DAU 的平均值，除以当天的 MAU。如果只用一天的 DAU 去除，数字会因那天是星期日还是星期一而上下起伏。
North Star。Amplitude 的 North Star Metric 文章把好的 North Star 的条件列为：与客户实际获得的价值相关，体现产品战略，是先于销售额变动的（leading）指标，并写明要避开像 DAU 或注册用户数这样的虚荣指标（vanity metric），以及像月销售额这样的滞后指标。如果是团队文档工具，与价值更接近的是“把文档与他人共享的人”，而不是“创建文档的人”——协作工具的价值，在第二个人进来时才产生。所以本实验把“每周共享用户（那一周至少做过一次 share_doc 的人）”作为 North Star 候选来计算。这并不意味着它就是正确答案。目的是先确定候选，再看在同一份数据中，它与其他活跃定义有什么不同的变动。
激活（activation）。先确定注册的人第一次尝到价值的那一刻，再测量注册之后一定时间内达到那一刻的比率。本实验是“从注册时刻起 7×24 小时内 create_doc”。如果按日历日期数 7 天，晚上 11 点注册的人就少得了一天——要按时刻来数。
在现场相遇的样子
- 发给投资人的 MAU 与内部仪表板上的 MAU 不一样。一个排除了内部账户，另一个没有。因为没有定义文档，没有人知道哪一个是对的。
- 这是一个韩国的服务，但分析工具的默认时区是 UTC，所以从午夜到上午 9 点的活动被算到前一天。星期几的模式看起来错开了一格。
- 大量发送推送通知的那一周，DAU 跳了起来。因为把“任意事件”算作了活跃。通知不是价值，而是成本。
下面的示例数字是用本实验材料计算出来的，并不是通用的基准值。同一天的 DAU，也会因为是否包含内部账户、统计哪种事件，而相差几十个百分点——要在实验中亲自比较。
下一项实验要做什么
你将用“Moanoteu”16 周的记录，把 DAU、WAU、MAU 和粘性做成函数，测量包含内部账户时，以及更改活跃的定义时，数字会晃动多少。最后计算每周共享用户和 7 天激活率，汇总成一份报告。评分器还会用其他种子生成的记录，重新运行你的函数，以确认你不是把数字背下来写进去的。