今天跟我司新来的产品经理提数据需求，聊着聊着他就开始膨胀了，鼓吹自己多么懂数据。
我就呵呵了，心想，估计他连接下来这5个问题都搞不明白。
UV、DAU、DLU、ARPU……对于产品经理而言，做产品时，五花八门的数据指标信手拈来，似乎可以分分钟搞定“数据化运营”
如果你真的这样想，那一定是对“数据化运营”有误解。下面这5个问题，可检验你对数据的理解程度。
一、产品中的“用户”是如何定义的？
“用户”是产品的基础资源，那么，关于用户，你需要清楚地知道哪些内容呢？
你的产品中有哪些类型的用户？(分类方式你可以自己指定，如按照付费用户、免费用户、游客来分类)
上述各类用户在使用你的产品时，是否必须登录？
“用户数”是按什么信息统计得到的？(按帐号、绑定手机号、设备ID？未登录的用户又是怎样统计的？)
产品中的“用户数”是否存在“水分”？(如一个人注册多个帐号的情况)
你的产品中又有多少自然人？
现在，你有没有感觉到，“用户”实际上并不是产品中的一个简单的概念？
对于“用户”在现实世界中的定义非常明确——通过电脑、手机等设备使用产品的活生生的人(或称自然人)。而在数据中，“用户”的定义就成了一个既重要又严肃的问题。
在大多数场景中，用户通常是通过某个数据维度来标识的，例如：
产品帐号：适用于大多数需要注册登录的产品(如微信、支付宝)，用户在产品上完成注册会生成一个帐号，以一个帐号代表一个用户。
第三方认证帐号：也称快捷登录帐号。与产品帐号类似，只不过帐号不由我们自己的产品维护，而是由可信的第三方平台提供。如产品允许用户使用自己的微信、QQ、微博、支付宝等进行登录，登录时会指引用户转向微信等平台授权。以每个第三方平台反馈的标识代表一个用户。
手机号：对于只能通过手机号注册或者必须绑定手机号的产品可以手机号定义用户，即一个手机号代表一个用户。
设备号：用于手机App，用可以标识手机设备唯一性的编号(如IMEI)定义用户，一个设备号代表一个用户。
IP地址：即联网的电脑或移动设备的网络协议地址，多用于不需要注册和登录的网站对独立用户的判定(这时也称用户为独立IP)，用一个IP地址代表一个用户。
身份证号：对于收集用户身份证号合理合法的产品可以用身份证号定义用户，但这只针对中国居民的用户群体，一个身份证号代表一个用户。
你的产品是怎样定义用户的呢？
实际上，以上对用户的定义方式各有其局限性，且精确度各不相同。然而，它们处理起来相对容易且高效，因此在产品中被普遍用作用户的数据定义。
当然，正如每个人可能会有多个手机号一样，一个用户也可能会在同一款产品中注册多个帐号。如果我们需要了解产品用户究竟覆盖了多少自然人，应当怎样做呢？
——这里留给你来思考。
二、DAU中的“活跃”究竟是什么含义？
从上一个问题推进一步，我们再来看看DAU中的“活跃”又是什么含义。
在你的产品中，用户要在一天内完成哪些操作，才能算作“活跃”呢？莫非，只要一天当中登录一次，就算活跃？
实际上，除非你的产品交互非常简单，否则将活跃等同于登录是很有水分的——它可以被用来做宣传，但产品经理绝不应如此认知，否则无异于自我欺骗。
况且，将日活跃定义为日登录，还会面临一个陷阱：如果一个用户连续多天从未下线(也意味着她/他在这些天内从未有过“登录”的操作)，那这个用户还算不算活跃用户呢？
不同的产品，用户“活跃”的含义也往往是不同的，比如：
像微信、QQ这样的社交产品，要求用户在一天内要有一定数量的主动交互行为才算作活跃用户，主动交互如发消息、发朋友圈、点赞、支付、建群等；
而对于一款在线音乐或在线视频产品而言，活跃用户至少应被认为是主动打开并播放了音乐或视频的用户；
如果是功能综合性较高的产品(如支付宝)，则用户活跃的途径会更加多元化；
当然，正如我们刚刚提到的，如果一款产品的交互非常单一(比如只提供查询天气预报、股市行情等信息的工具产品)，把“活跃用户”等同于“登录用户”或“打开用户”，也无可非议。
那么，你的产品是怎样定义用户“活跃”的呢？
三、数据产品经理就是数据分析师+产品经理吗？
也许你遇到过这样的场景，当有人向你提“数据产品经理”这个概念时，你会问“你是指的数据分析师吗？”或者“这个是不是产品运营里的一个角色？”。
而你的团队中可能也确实存在数据分析师、数据挖掘工程师这样的专职角色。
简单地理解：
一方面，数据产品经理(DPM)之于数据分析师(DA)，相当于基础产品经理之于开发工程师；另一方面，如果DPM是数据产品的缔造者，那么DA很可能是这款数据产品的用户群体之一。
对于国内几家知名互联网企业而言，DPM属于产品类岗位，而DA属于研发类岗位。由于DPM需要一定的专业技能，所以DA转为DPM的情况也很常见。
DPM与DA有一部分重合技能，但前者注重于对数据方案和产品整体的把握，而后者注重于数据的挖掘、分析、提炼的专业探究。
在互联网大大小小企业纷纷进行大数据战略布局的当下，数据也被以产品化的形态运作，这就有了DPM以及专注于数据的其他各种角色。
下表在定位和职责上对比了DPM与DA：
所以说，数据产品经理≠数据分析师+产品经理，但是数据分析师和基础产品经理在进行一定的修炼后，可以承担数据产品经理的工作。
讨论到这里，我们还可以引出一个问题：既然数据产品经理可以由基础产品经理或数据分析师转过来，那直接让团队中原有的成员兼任数据产品经理不就可以了吗？——这种思想其实无益于产品的发展壮大。
关于数据产品经理的必要性，我在《DPM认知修炼4：为什么需要数据产品经理》一文中总结了4点：
以数据驱动产品的专职角色
打造和经营专业的数据产品
产品团队与数据团队的纽带
填补数据工作的职责盲区
四、数据库 vs 数据仓库
从字面上看，数据仓库(Data Warehouse，简称DW)和数据库(Database，简称DB)都是用来集中存放数据的场所，而DW似乎又能比DB容纳更多的数据。
——这样顾名思义并没有问题，只不过无法帮助我们进一步理解二者的异同。
实际上，二者在数据应用中的作用差异非常大，不能相互代替：
面向的业务场景不同：DW面向数据分析处理，而DB则面向事务处理。例如一款社交App，它会使用DB来存取用户的帐号信息、设置参数、关系链等信息，为服务器提供用户身份验证、设置解析、好友互动等业务逻辑的数据事务处理；而用户在App中表现的各种行为数据，则会通过数据产品存储到DW中，以支撑日后对用户行为数据分析的需求。
优化的操作不同：由于面向业务场景的不同，DW需要集中系统资源优化数据的获取，以应对大量数据被频繁调取、分析和处理的需要；DB则需要为数据的访问、存储、删除、更新进行全方位优化，以满足频繁的数据更新和事务处理对速度和效率的要求。
数据的组织方式不同：DW中通常以时间的分区来组织数据，如按小时分区、按天分区、按周分区；而DB通常以数据的索引和实体的关系组织数据。这主要也是为了契合不同的业务场景——数据分析通常要以一个时间粒度为单位进行统计和分析，而事务处理则需要遵循ACID原则(不明白？看下文)并维护DB中各数据实体的关系。
数据冗余性不同：如果你学习过DB相关的知识，那么一定对关系数据模型的范式(如第一范式、第二范式、第三范式、BC范式)不陌生，范式的作用就是在保证数据关系的前提下尽量减少数据的冗余，这也是DB实践中对数据的低冗余要求。
而DW不但没有强调数据的关系性，反而接受高冗余的数据，以丰富数据的维度，从而提升数据分析的效率。
此外，数据冗余性的差异也约束了DB往往只保留最新、最有效的数据，而DW则要保留历史上所有的数据。
例如：用户资料中的职业和收入水平会随时间的推移改变，当用户更改自己的职业和收入水平后，DB只需保留更改后的信息、抛弃更改前的信息；而DW则要完整保留用户每一次变更前后的信息，并记录变更的时间点。
对于数据产品而言，数据接入层和数据处理层会更频繁地与DW打交道，并且DW通常也是数据接入层和数据处理层的数据通讯渠道；而处于数据应用层的产品与用户产品相似，通常使用DB来维持产品的数据存取和事务处理。
注：ACID原则即DB管理系统中的事务所要遵循的四个特性：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。原子性是指一个事务是不可再分的，必须作为一个整体完整执行。
一致性是指无论事务执行结果如何，执行前后的数据约束规则应保持一致，不能被打破。隔离性是指两个及以上的事务并发执行时不能相互影响。持久性是指事务一旦执行完成，其对数据的影响就要在DB中生效，不能撤销。
五、数据规模不够大，无法用来迭代产品？
如果你在运营产品的过程中经常接触AARRR模型、用户画像、A/B Test等“大数据”的概念，或许会认为：
“我们看到的数据整合自全体用户，统计和分析的是产品的宏观现象”
“只有形成规模的数据，才有利用的价值；只有大多数用户表现出来的特征，才能通过数据观察到”
——实际上，这是对数据的一种误解
通读《产品经理数据修炼30问》一书，我们知道：数据其实是用户行为的客观产物，不仅能够支撑产品运营中对宏观问题的解决，同样可以用来捕捉用户的情感，感知细小的用户需求。
——这就是所谓的“小数据”思路。
通过这种思路将产品中的细节做到位，用户就会感到“用着爽”。
——这往往会成为产品在众多竞品中鹤立鸡群的法宝。
请看下文的案例：
相信你对下面这种注册/登录交互不陌生：
▲ 图1 手机号快捷登录交互(优化前)
用户只需要填入手机号接收验证码、填入验证码这样两步即可完成登录。
另一方面，如果填入的手机号是首次登录，这个过程还会帮用户完成注册——这样一来，无论是新用户还是老用户，在产品登录上的体验是一致的。
然而，看似流行且方便的交互，我们依然要怀疑一下：用户真的没有困扰吗？用户真的能够顺利地完成注册和登录吗？
于是我们提取了登录模块的数据，并按新用户与老用户分别统计，得到下表：
▲ 表1 登录模块相关数据(优化前)
注：若最终登录的手机号为首次登录，则认定为新用户，否则认定为老用户；登录注销是指登录成功后，在同一会话超时前又主动注销了登录，表现为更换帐号的倾向。
上表的数据能给我们什么启发呢？
首先，新用户在第一步页面的平均停留时长比老用户多90.7%，也许是新用户操作不熟练的缘故，但是从第二步页面的平均停留时长看，操作不熟练似乎并没有使新用户比老用户多花费多少时间。
因此，怀疑第一步的页面存在困扰新用户的因素。
其次，新用户的登录注销率是老用户的近三倍！这个似乎有些夸张——是什么原因让新用户登录后不久又主动注销了登录？是要更换登录帐号吗？
针对第一个问题，招募新用户开展可用性测试后，锁定了主要原因：
第一步页面引导用户使用手机号登录，没有任何注册说明，而新用户习惯性认为登录前要先注册。于是他们试图在页面中寻找注册入口，直到找遍整个页面无果后，才抱着试试看的心态在登录引导中填写了手机号，这才发现原来产品不需要额外注册。
注：实际上，在寻找注册入口无果后，选择试试看的用户约只占受挫新用户的一半，还有一半会选择放弃使用产品，这会为产品拉新带来不小的损失。
至于第二个问题，我们将新用户登录注销的数据提取出来进一步分析，看看这些新用户在注销登录后又做了什么，得到下图所示的结果：
▲ 图2 局部数据再分解：新用户登录注销后的操作
注意到：注销登录的“新用户”转而用旧帐号再次登录的比例明显高于其他情形，说明这部分用户实际上应当是老用户，只是登录时验证了新的手机号，导致被认作新用户。
他们为什么要这样做呢？
通过用户回访了解到：这些用户拥有至少两个常用手机号(得益于双卡双待手机)，他们使用其中一个手机号完成首次注册；经过较长时间后重新登录，由于忘记之前登录的是哪个手机号，于是概率性地尝试用另外一个手机号登录；登录后才发现不是他们原本的帐号，这就有了注销登录、再次以老用户身份登录的操作。
结合上述研究，登录与注册页面调整如下：
▲ 图3 手机号快捷登录交互(优化后)
在第一步中对新用户注册进行引导；在第二步中明示用户当前验证的手机是否首次登录，若不是用户想要登录的帐号，可返回第一步页面重新填写手机号。
调整后的版本发布一段时间后，再次提取相关数据，可以看到情况发生了明显改善。
▲ 表2 登录模块相关数据(优化后)
在上述案例中，我们多次通过数据对用户个体行为进行捕捉和分析，这是小数据思维的一种体现。
对于产品经理而言，小数据思维与大数据思维同等重要，甚至在用户需求和痛点挖掘上，运用小数据洞察会更具优势。
小结
怎么样？这5个问题你还回答得顺利吗？
实际上，这些都是做产品所必备的基础素养。
也许你会问：
“数据那么深奥，我又不是专业的数据分析师，应当对数据了解到什么程度、掌握哪些技能、花费多长时间，才可以成为一名有着出色数据敏感力的产品经理呢？”