数据分析是产品经理的一项基本技能，然而每次想好好学习下，资源不是7天精通Excel就是20天进阶SQL，甚至于Python必知必会……工欲善其事必先利其器，确实没错，但工具需要思维来指挥。而数据指标的定义，是培养数据思维要闯的第一道关。作为一只数据小白，分享一点定义数据指标的心得，有问题老铁们请斧正。
1、激活，如何定义一个激活？
下载、安装并打开APP的用户数？我们暂且这么定义。根据定义，下载没安装或者安装没打开的用户，都不计入激活。只有完成所有步骤的用户才算。但是问题来了，一个用户下载、安装并打开APP时，根本没登录，他只是一个游客。激活的定义变成：下载、安装并打开APP的游客数。
如果我们把这个定义交给开发，开发可能会问，拿什么标识一个游客？设备号。每台移动设备都有一个唯一的识别号码，也叫IMEI(International Mobile Equipment Identity)。所以，激活的定义又变成：下载、安装并打开APP的设备数，以设备号为唯一标识。
有人可能会问，我更新APP后打开，或者卸载重新安装APP再打开，算一个新的激活么？这就涉及到统计口径的问题，一般来讲，覆盖安装与卸载安装后的打开，都不计入激活。
2、新增用户数，多维度区分
如果把新增用户定义为新注册的User_ID，简单粗暴，但市场的同事首先不答应。
市场推广APP有多种渠道类型，比如各大安卓应用市场、AppStore、信息流、SEO、流量互换等，每个类型下的渠道，以Channel_ID来标识。
渠道有区分，APP自身也有区分。最省事的区分是Android包和iOS包，显然未考虑扩展性。如果市场制作马甲包（APP小号）、独立H5页，推向市场，需要以Product_ID来区分产品（APP、H5）。
另外一个维度是版本。每个版本发布时，市场可能会带一波量，需要观察版本新增用户的推广成本、转化、ARPU值等。我们可以通过Version_ID来区分版本。
以上，通过Channel_ID、Product_ID、Version_ID的区分和筛选，市场部的同事就可以知道，每个渠道下的每个产品的每个版本的新增用户情况。
维度区分清晰了，除了在一定程度上，提高市场推广效率外，甚至能预防数据异常的发生。笔者所在公司是做公积金查询的，查询数/新增用户数，是一项重要的指标。有天突然查询数/新增用户数断崖式下跌，一开始，大家都以为是查询成功率下降导致查询数（分子）下降，拼命分析影响成功率的因素，却始终无解。
后来才发现，是新增用户数（分母）的暴增导致了比率的下跌。新增用户数暴增，查询数成功率正常，查询数却没有增加，什么鬼？其实这是个伪暴增。新增用户的统计口径，纳入了错误的Product_ID，而ID对应的产品刚好正在大力推广……
如果能在数据指标定义时，清晰地划分出可能的维度，类似耗费时间与沟通成本的数据异常问题就不会发生。
3、活跃，谁的活跃？
定义活跃，不能粗暴地只定义一个用户日活指标，可以先从转化的角度进行用户层级的划分。
笔者所在的公司，是通过公积金数据做授信，帮助银行筛选优质贷款客户，用户在APP上的关键行为是查询公积金、申请贷款。因此转化漏斗是：激活-注册-查询公积金-申请贷款，对应指标是：APP日活（游客+用户）、用户日活、公积金导入用户日活和贷款申请用户日活。
APP日活，以APP的一次打开为一个活跃，以设备号为标识，当日的重复打开不计入活跃。剩下的3种日活，以相应用户群体的一次登录请求为一个活跃，以User_ID为标识，当日的重复请求不计入活跃。
跟踪以上指标，能得到比单纯的用户日活指标更丰富的信息。
另外，活跃也不一定以日为单位。从行为频率上来看，查询公积金可能是1次/月，申请贷款可能是1次/日。那么，公积金导入用户，月活可能更适合作为活跃指标；而对于申请贷款的用户，则日活更适合。
4、留存/流失，两兄弟？
在和同事讨论7日留存率的定义时，出现了分歧。有人认为7日留存率指的是，新用户在第2-7日的活跃数/新用户数；而不同意见表示是新用户在第7日的活跃数/新用户数。老铁们也可以发表下自己的意见，你们支持哪种，理由呢？
留存率是APP推广初期尤其要重视的指标。留存率低的产品，等于一个巨大的漏斗，市场砸钱买来的流量，在产生收益前，就都统统漏掉。真真是黄金万两，砸不出一个声响。
至于选择次日留存率、7日留存率还是30日留存率作为唯一关键指标，多少留存率为目标，要根据产品特性与市场环境作具体分析。
从定义上看，流失和留存貌似是两兄弟。有7日留存率，就有7日流失率，两者的分子加起来等于首日的新用户。但新用户在第7日未活跃，就定义为流失用户，未免太过草率。由于回流用户的存在，定义流失用户的周期一般比留存用户的长。比如，定义90日内未活跃的用户为流失用户，更为合适。
5、定义数据指标的目的性
最后强调一点，定义数据指标不能无的放矢。
如果是为了解决一个问题，那我们先明确问题，分析可能的原因，再去定义指标。
如果是为了验证设计方案的优劣，那我们先明确设计方案的目标，围绕目标去对比上线前后的数据，或者做A/B Test。
如果是为了预测，那我们先摸索现有的数据规律，找到规律的自变量，再进行推演。
如果是为了预警，那我们先制定数据基线以及浮动范围，并根据实际情况的变化灵活调整。
