做数据的酿酒师——使用正确的数据

Data matures like wine, applications like fish.
——James Governor

偶然间看到这则关于数据与产品的解读，让笔者眼前一亮，对其的理解应该是见仁见智，笔者更倾向于这样诠释：成熟的数据像是美酒，并且愈久愈醇，也更有价值，但也许打开的时候才会发现由于数据存储不当而不小心变成了醋。而APP像是鱼，小鱼未来可期，需要悉心呵护才能成长；成鱼生机勃勃，但是年龄越大，往往会到达它的成长极限；鱼群需要繁衍新生命来延续，APP也需要更新迭代才能达到良性循环。

作为一个专注于女性生理健康领域的公司，Glow拥有4款针对女性不同生理阶段的APP产品，从第一次月经到第一次拥有小Baby，女性往往有太多对“第一次”的无所适从，Glow的产品在女性最重要的生理阶段，帮助女性记录相关生理数据来熟悉自己和宝宝的身体状况。

同样，Glow也把数据作为产品决策的主要驱动力。用户借助在Glow APP上记录的数据来调整生活、饮食等节奏来达到期望的需求，而Glow也致力于通过用户行为数据调优自身产品，从而给予用户更好的体验，也让产品自身处于更健康的状态。

酿酒，从原材料准备，酿造方法选择，环境控制等等，一直到最终酿出成品，每一步都至关重要，而数据的准备工作也是如此。作为分析师，如何确保数据准确，精准输出结论，为正确的决策做指导，是一项很重要的课题。本文将结合实际业务中遇到的问题，梳理数据分析前期准备中几个关键的流程，分享酿造“数据”美酒过程中一些常见的陷阱。

1. 了解数据目的，保持有效沟通

明确数据需求方目的，是最简单也是最关键的第一步，数据分析师应该在充分了解业务背景、数据目标的前提下，再开始接下来的工作。

比如，产品新上了一个针对优化用户体验，促进用户留存的迭代，在上线一段时间后产品经理希望能看看这次迭代的效果，是不是有优化的空间。而有的分析师由于惯性思维，吭哧吭哧查询整理数据，从用户付费转化的角度各种分析得出结论，又由于新迭代上线后付费转化没有“提升”又开始进一步找原因，花费大量时间，却一直忽略了新迭代更关注的用户留存情况。

就好比业务方想要葡萄酒，而分析师却提供了一份精致的梅子酒一般，最终业务方苦等数据结论，到了DDL发现还要再等一个周期，分析师也花费大量时间与精力却发现要从头再来。这种情况往往由于业务方给的数据需求较模糊，而数据分析师又没有正确理解业务目的，所浪费的时间成本是很可惜的，也影响了产品健康的迭代进度。

2. 明确分析思路，选用合理指标

在清楚业务需求的前提下，确定需要参考哪些指标，成为接下来的课题。作为数据分析师应该明确：分析师应该是对产品数据最了解的人，因此永远要主导判断业务方需求的数据合理性和可用性。

有时候，业务方的需求看似很明确。还是之前的案例，产品新上了一个针对优化用户体验，促进用户留存的迭代，在上线一段时间之后产品经理给到需求：“我们新上的迭代目的是提高用户留存，想知道前3天的日活到了什么水平？和迭代上线前3天比有没有提升？” 有的分析师一听，太喜欢这种精准的需求了，于是二话不说，严格按照产品的需求拿到数据，出现了pic1的趋势，赶紧把结果告诉产品经理，并且说：“这次迭代效果不好，平均DAU反而下降了13%！”

而实际呢，如果看pic2的日活趋势就会发现，DAU存在一个周期规律 —— 通常周初处于高位，而周末处于低谷。之前提供的数据结论中，“前3天”包含周末，而“上线前3天”则是处于周初最好的水平，两个时间区间内的数据本身就无法直接进行比较，而由于这类比较而引出的结论，是完全无用的。

再进一步想，用日活真的就足够了么？日活作为一个绝对值，就算优化效果不错，也往往不会在短期内看到很明显的变化，其本身也容易受到前一段时间的用户增长、留存的影响。是不是可以考虑更合适的指标，比如留存率、回归率、功能参与度等来衡量呢？如果新的优化有针对特定人群，那么用户组成，比如国家、新老用户、身体状态等是不是又需要加入筛选才能保证不被其他因素打扰，更精准的体现这次优化的结果呢？

很多数据的因果逻辑错综复杂，分析师需要根据自己的思考判断，再和需求方进行沟通，确认一致的统计口径，或许需求方需要的只是葡萄酒，也有自己的初步观点，但最终要选取什么种类的葡萄，才能酿造出最符合需求的葡萄酒，则需要分析师来指导对方。如何确认需要统计的指标，则依赖分析师根据产品数据的实际情况、过往工作经验和合理的逻辑判断才能综合得出结论，在此暂不赘述。

3. 清楚数据来源，确保数据准确

由于Glow拥有自己的数据库，作为数据分析师不仅有整理分析数据的职责，也承担了部分数据库/仪表盘的维护工作。因此，基本上所有的数据来源，分析师都需要有所了解。在拿到了对应的数据之后，也需要能敏锐地观察到数据的异常点，从而判断是否数据处理有失，或者数据来源和认知有误，并进一步进行调查，必要的情况下配合开发人员尽可能地将数据差异处理。

比如产品想要知道使用我们Baby产品的活跃用户中，只有一个宝宝的用户比例，从而用来优化用户体验流程。确认了需要统计的指标后，分析师需要开始思考：

• 应该怎么拿到数据？
• 是不是符合定义？
• 会不会存在偏差?
• ...

清楚数据结构的分析师会知道，和该数据近似的数据点有两个：1、在用户第一次注册时，针对部分状态下的用户有一个选填项询问目前用户创建的是第几个宝宝，默认为一个；2、用户可以在我们的APP内创建多个宝宝，用来记录宝宝的行为，我们可以知道用户创建的宝宝个数。

这两个数据点，针对产品的目的来说，都不准确。第一个由于是选填项，并且存在默认值1的概念，在没有其他记录辅助判断的情况下，“第一个宝宝”的比例将明显偏高；第二个由于用户创建宝宝的时机，仅满足用户使用产品时宝宝在app适用年龄范围内，通常用户不会需要创建过去的、已经长大的宝宝信息，也会让“第N孩子”的分布向小偏移。

在这种情况下，分析师应该做的不是为图省事，向产品输出有失偏颇的数据，而是及时与产品部门沟通，说清楚数据不准确的原因，讨论是更换数据指标来判断问题，还是用同样的数据指标，但是换个角度来诠释数据。

假设忽略以上导致差异的情况，最终决定采用第一个数据点来统计用户的分布，则需要进行下一步对于数据结果的验证。我们简单的将用户回答问题的情况分布整理出来，出现了pic3的分布结果：

根据数据库文档的说明，该字段的index对应着以下几种情况：

0 - first
1 - second
2 - third
3 - fourth
4 - more than four

不难发现，查询到的数据结果不管是和之前的认知还是文档说明都存在一定出入：1、理论上第一个宝宝的比例应该占大多数，而结果里第二个宝宝的比例却最大；2、文档说明里只存在0-4的index，而最终的结论出现了0-5的记录。

为什么会造成这种差异？此时一般需要分析师能根据现象联想到可能存在问题的原因，或者根据以往的经验，来辅助确认。在这个案例下，我们联想到不同平台（iOS/Android）由于历史代码存在不统一性，或许会导致差异，于是下一步我们细分到平台来看数据，得到pic4的结果：

此时的结果将原因很明确的展示了出来：看起来Android是按照文档的说明进行的index标记，而iOS则是按照实际的第N个宝宝来进行的标记，而二者的分布比例在各自的情况下是符合我们的初步认知的。

在这种情况下，数据分析师需要做的，首先是和相关开发负责人确认自己根据数据推测到的逻辑是否符合代码的实现，接下来将确认好的结论提供给产品方。另一方面，为了日后的工作能少走弯路，分析师可以和开发一起判断是更改文档说明还是在代码里将编号与文档统一，当然，一般情况下，不推荐、开发也不会建议实施后者的方案。额外的，根据对该数据的使用频率与重要性，分析师可以将此分类的方法的代码也同步到自己的文档中，或者创建方便下次查询的view，为其他分析师工作交接做准备。这些操作就像是酿酒过程中，发现了原材料的不适用性，是替换原材料还是优化酿造方式，需要根据实际情况做判断，但最终的目的，是能酿造出真正的酒，而不是醋。

4. 结语

数据分析入门容易，但精通难。仅仅是真正展开分析前的环节，就藏有无数个陷阱，文中提到的几种情况，也不过是冰山一角。因此，每一步看似简单的流程里，都需要分析师能时刻保持理性，带着逻辑和批判思维来看待拥有的数据，和他人进行沟通。而当你拥有了这样看待数据的习惯，相信不仅对于数据，而且在为人处世、制定战略上，都可以抱有更公正客观的态度。