2.1 为什么要做——师出有名
做事需要“师出有名”，“名正”才能“言顺”。这样既方便大家找到自己的工作方向，又方便大家在占用资源的时候找到适合的论证依据。企业内部的资源是有限的，而数据产品的出现，就是为了在资源有限的前提下，提高数据应用的效率，从而通过数据支撑产品管理、产品运营及其他方面的工作。
在搭建数据产品的过程中，在业务内部或者产品线内部存在这样一种情况：数据产品因为缺少必要的数据支撑而根本无法运转起来，或者它虽然在运转中，但是效率低下，投入了过多的人力、物力、财力，产出却极少，需要进行优化。
面对这样的情况，我们通常的思路是具体定位到业务运转对数据的诉求，或者业务运转对人力、物力、财力的使用情况，确定搭建数据产品或者优化低效环节的目标，之后再根据目标与现实情况的差距，规划具体的实现路径、识别工作难点。
本节将介绍两个方面的内容。首先，笔者将会详细梳理那些依赖数据应用的环节，通过设计数据产品，让这些环节顺利地运转起来；其次，笔者将会关注现有数据应用和业务自身的效率问题，通过价值评估，找到其中低效的环节，并找出问题的根源。
2.1.1 支撑数据应用
首先，我们要了解业务层面缺少数据支撑的情况。我们可以概念化地把这样的情况理解为数据产品的“从0到1”。
从第1章的内容中我们了解到，可以从数据应用的三大视角中找到11个常见的细分方向。在三大视角中，应用目的的视角是最贴近业务的；其次是数据处理的视角，可能会对业务和产品形态产生一定的影响；而数据呈现形式的视角则更偏向技术层面，对业务的影响是三大视角中最小的。
因此，下面笔者就从数据应用目的和数据处理的角度，找到数据产品需要解决的问题。
1.统计中的数据支持
人类的记忆力和计算能力本来就是十分有限的，在如今的大数据面前，更是“自愧不如”。因此，各种统计工作自然需要数据来支持，特别需要数据产品来支持，不可能由人类自己来完成。
当然，笔者在这里想要得出的也不是“计算机能够帮助人类完成前所未有的大规模计算，从而得到一些新的洞察”这样的结论。笔者想要表达的是在这个过程中究竟出了什么问题或者可能出现什么问题。
在日常工作中，类似的场景并不少见。大家可能经常会产生这样的想法：“如果能够看一下……这个数据，我就知道该怎么办了”，或者“基于现有的信息还无法得到一个有意义的结论，是不是应该再看一下……这个数据”，这就是笔者所说的统计的场景。
在这个过程中，常见的两个问题就是数据采集与统计口径的问题。在不同的团队中，这两个问题都有可能成为关键的问题，需要尽快解决。比较常见的情况是统计口径想清晰了，却发现需要的数据没有准备好，也就是问题出在了数据采集上。
1）数据采集的问题
采集是数据应用“逻辑”上的起点。那些常见的业务数据通常是没有问题的，因为这样的数据通常不需要额外设计专门的采集机制。比如，用户发布的UGC （User Generated Content，用户原创内容），或者用户交易时的订单金额等，在数据库中必然有相应的内容存储下来，否则业务无法正常运转。
因此如果说数据采集出现问题，更多指的是那些不会影响业务正常运转、却会影响数据应用过程的数据。比如，用户的各种浏览和点击行为。这些数据如果不在产生的时候就及时、完整地记录下来，就再也找不回来了。类似这种数据，就是数据采集中的一些“死角”，很可能等到真正要用的时候，才发现其中存在问题。这是数据采集容易出现问题的第一个原因。
另一个数据采集容易出现问题的原因，是数据采集是比较偏底层、偏技术的工作。很多技术手段的有限性决定了一些数据确实无法采集到，或者准确度无法达到理想的程度。
最后一个原因就是我们不够重视。数据采集本身就是一项烦琐的工作，既看上去没有上层的数据分析过程那么有趣，又无法像数据分析那样直接、明显地对业务产生影响，很容易被忽视。
对大多数做产品和运营的朋友来讲，从头开始搭建一款新产品的机会并不多见。如果大家刚好遇到了一个这样的机会，一定要抓住它，利用它锻炼自己设计产品的数据体系的能力。
在数据采集这件事上，面对一款新产品与面对一款从别人手里“交接”来的产品，需要解决的问题也是不同的。
如果大家有幸能从头开始设计一款产品，那么需要考虑“究竟需要采集什么数据”。因为在这个时候面对的是数据上的“一片空白”，大家需要从业务自身逻辑的角度，考虑需要采集哪些数据才能完成后续的数据分析工作。因此，这个问题回答得好不好，取决于大家对业务的理解有多深入、对运营过程的理解有多深入，甚至还包括对整个企业或团队的运作方式的理解有多深入。
如果大家接手的产品已经上线运转一段时间了，在企业中对这款产品已经建立了一些初步的数据收集机制，并且已经有一定的数据沉淀了。那么，这个时候需要尽快解决的问题就是“采集到的数据究竟是什么”。对这方面的理解，还会延续到考虑统计口径的阶段。
要解决好这些数据采集中的问题，就需要结合下文关于“理解业务”的内容——从业务的诉求出发，设计出符合业务分析和发展需要的数据采集方案；或者依据业务自身的逻辑和发展脉络，逐渐了解现有的采集方案能够支撑什么样的数据分析。
最后，只了解了还不够，这个过程的“实际产出”应当是一些对业务逻辑的抽象和设计，比如描绘干系人之间关系的E-R图、描述业务流程的流程图等常见的设计文档，或者更偏技术层面的数据埋点设计和数据结构设计等。关于这些文档和设计，笔者在后面的章节中还会详细介绍。
好消息是，一些第三方的数据服务平台已经为大家设计了自动化的数据采集方案。结合这些方案，对那些常见的基础数据，大家就不需要再费心采集了，因为这些方案会直接将常见的基础数据准备好。不过，这只能解决简单数据的采集问题，那些与业务自身特点高度相关的信息，或者那些因为比较敏感而不能交由第三方处理的数据，仍然有待大家去挖掘。
2）统计口径的问题
在将数据采集的问题处理妥当之后，按照“逻辑”，我们就应该开始考虑统计口径的问题了，这是进行深入分析的起点。
提到口径，大家最容易想到的就是各种常见统计指标，比如，DAU （Daily Active Users，每日活跃用户）代表每天活跃的用户数量，DNU（Daily New Users，每日新增用户）代表每天新增的用户数量。
在这些指标的背后，还有更具体的问题。比如，什么是“活跃”？什么是“新增”？用户下载了App，算不算“新增”？注册了账号，算不算“新增”？还有发布了第一个“状态”、添加了第一位好友、完成了第一笔交易……究竟什么才是“新增”？“活跃”也存在同样的问题，用户每天只打开了App算不算“活跃”？甚至用户都没有主动地打开App，只通过H5页面借助Deep Link（深度链接）“无意间”打开了App；再或者通过应用市场打开App，这些又怎样定义呢？
这些具体的定义并没有想象中那么简单，既与业务逻辑和产品形态有关，也与业务和产品的发展阶段有关，还可能是通过一些统计或者算法模型得出的结论。
比如，在某个UGC平台的发展初期，用户只要完成基本的注册流程，就被计入DNU了。但是到了用户原始积累阶段结束的时候，只有那些至少发布过一次UGC内容的用户，才能被计入DNU。（实际情况是，很多业务和产品从一开始就没有把注册流程“放在眼里”，直接定义“完成一次实际转化行为”的用户才是“新增用户”。当然，这样又引出了一个“转化”的概念需要定义。）
这些具体概念和指标的定义，在理解业务的过程中只是一个计算公式或一张流程图中的某个箭头。但是到了理解技术的层面，它们会变成针对业务的数据集市建模、可执行的数据查询语句等。在这个过程中有更加细节的问题需要处理，因此大家还需要对定义进一步细化。
比如，在有些计算引擎中，平均值函数AVERAGE的计算结果，并不等于求和函数SUM计算结果和计数函数COUNT计算结果的比值，通常的原因是没有明确处理所需字段取值为“NULL”（空值，即“没有数据”，属于缺失值的一种）的情况。
同时，统计口径的问题还与下文要讲解的关于“理解技术”的内容高度相关。因为在得到了统计口径的清晰定义后，就要进行“算数”了。这样大家就要开始考虑计算引擎的选择，并对计算过程进行优化（查询语句优化或者算法优化），以解决数据量、计算效率等与计算相关的问题。
2.监控与分析
通过数据采集和计算，大家得到了需要的数据，并且计算好了那些“轻而易举”就能想到的数据指标。接下来就会产生两类不同方向的数据使用的诉求，即数据监控与数据分析。
数据监控的根本目的很简单，就是保证业务或者产品不出问题。但是这又是一个很难的问题，因为想要定义什么是“正常”并不容易。
常见的监控场景比较容易想到。上文中提到的那些基本的统计指标，虽然有的每天才更新一次，但是都可以划分到数据监控的范畴。当然，这些指标也可以按照更短的时间周期更新，如过去一个小时内产生的交易、过去一个小时内活跃的用户等，甚至过去一分钟内的情况。
前面这些都是偏向业务层面的监控诉求，还有一部分是偏向技术层面的监控诉求，如监控系统的吞吐量、服务器的负载等。这些同样是支撑着互联网产品和业务“瞬息万变”的关键监控诉求。而且在技术层面，监控的时间周期会更短。
比如，对于各种网络请求会有一组指标来衡量响应的性能，包括TP50、TP90、TP99、TP999等。它们的含义也很容易理解，如TP99，就是处理99%的请求而产生的最小延迟。不过，这个99%代表的可不是概率，而是分位数。也就是把一段时间内所有请求延迟的数据按升序排列，其中在99%位置的那个延迟数据就是TP99的值了。
如果说数据监控是在“已知”的前提下来做保证，那么另一类诉求——数据分析就是在不断地探索认知的边界了。我们总是希望通过数据分析，获得一些我们此前不知道的、隐含在海量数据中的规律。数据分析应该是大家在日常工作中比较关注和熟悉的一项工作了，笔者在第1章中已做大体介绍，这里就不再赘述。
1）数据监控中的问题
在监控类的诉求中，比较难解决的问题当属阈值的设定，也就是上文中提到的如何定义“正常”的问题。不管是业务层面的DAU、DNU，还是技术层面的TP99和TP999，都涉及这个问题。
针对这个问题，我们可以采用的方法仍旧是加深对业务、行业和产品的理解。比如，DAU并不是一个孤立的指标，它的变化会受到许多其他指标的影响，如DNU就会影响到DAU的变化，用户的留存率也会影响到DAU。
在分析的过程中，我们可以在这些相关联的指标之间进行相互校验，这样就能确保一个指标的提升是在我们的可控范围内的，而不是一些“偶发因素”造成的。比如，当DAU突然增加的时候，我们就需要寻找原因。是DNU增加了？是用户的留存率提高了？是我们做了一些旨在拉高DAU的运营活动？或者是其他什么因素的变化导致的。这是正向分析的思路。
反向分析的思路则是，如果我们想知道DAU这个指标应当达到多少，可以通过一些相关指标的取值计算出来。方法是类似的，只是原来的自变量变成了因变量。除了这种基于指标之间的逻辑的计算方法，我们还可以在指标自身的基础上定义这个“正常”的阈值应当是多少，如采用均值、环比值等。
在阈值的问题解决之后，另一个问题就变得简单了，那就是一旦发现问题之后的通知方式，这也是数据范畴要解决的问题之一。如果阈值定义得不好，那么越高效的通知方式越有可能成为打扰用户的“罪魁祸首”。
常见的通知方式包括App内的PUSH消息，基于电信网络的短信和语音电话，结合第三方的微信公众号消息，以及能够承载更多信息量的电子邮件。
2）数据分析中的问题
数据分析中同样隐含着问题，不过数据分析工作本来就是一项饱含不确定性的工作，存在一些问题也是能够接受的。更何况，不断出现的问题将一次次的数据分析工作串联起来，帮助数据分析工作形成闭环。
因此，数据分析的起点，可以说是出现了问题而又无法简单地解决。要解决的这个问题，以及希望得到的答案，就变成了分析的目标。因此，分析目标的确定，就成为数据分析过程中可能出问题的第一个环节。
在关于数据分析的文章或者书籍当中，作者会反复强调分析目标的重要性。不过在实际工作中，有些问题确实无法在最开始就100%地明确下来，而是随着分析的不断推进而逐步明确的。针对这种情况，一项完整的数据分析任务可能被拆分成几个更小的阶段。其中一些阶段就在验证问题是否确实存在，或者在帮助大家逐渐明确所面临的、要解决的问题究竟是怎样的。这些阶段也可以称为数据分析过程中的“调研”阶段。
特别是当要分析的问题本身就比较复杂的时候，这些调研阶段是非常有必要的。什么样的问题是比较复杂的呢？在实际的运营过程中，我们经常会想要找到一些现象的原因。比如，用户为什么会产生奇怪的行为路径？为什么运营活动无法刺激用户产生更多的转化？对于这样的问题，我们通常会产生很多猜测，而且这些猜测之间是相互关联的——“如果……并且……那么是……导致的”。
面对这种问题，在实际落地的过程中，笔者会使用A/B Test的方式，先收集所有需要的数据，然后再使用这些数据逐个验证这些相互关联的猜测，最终得到关于这个问题的完整答案。（关于如何做A/B Test的问题，笔者会在第4章中进行更详细的介绍。）在这个过程中，前面的阶段都只能保证阶段性的目标是明确的，直到最后一个阶段的验证完成，整个分析工作要做的事情才明确下来。
可见，强调分析目标的重要性，只是要我们时刻关注它，特别是关注它的变化，关注它是否合理，以及是否真的有意义，而并非在最开始的时候就要把全部的信息确定下来。有时候，在最开始的时候根本不可能知道所有信息。
讲完了分析目标，就要讲分析方法论了。在写这段内容之前，笔者也认真地搜集过相关的资料，不过以讲解模型和框架的零散内容居多，并没有找到能够完整梳理下来的内容。于是，笔者根据自己在日常工作中使用的思路和方法，将数据分析常用的分析过程整理为五个基本步骤。同时，一些经典的模型和框架也确有其“历久弥新”的道理，所以对一些常用的管理和营销框架也进行了整理。关于这两部分内容笔者都会在第4章中进行详细介绍。
至此，关于在数据监控和数据分析的过程中可能遇到的、并且需要数据产品来支撑的问题，笔者整理出了一个概况。如果大家感兴趣，可以做深入的探讨。
3.洞察与决策
在数据越来越受到重视之后，我们能够很明显地感觉到，人们希望将更多的决策交由数据和计算机系统来完成。比如，“哪条广告带来的转化更高”“页面上的特定位置应当展示什么样的元素（广告）”这样的基本判断，以及“什么样的用户对我们的价值更大”“我们的市场费用应该如何分配”这种洞察。听上去，这些问题应该在监控和分析环节中就“完美地”解决了。但是，笔者在这里依然要把洞察与决策这两个重要环节单独拿出来进行讨论。
之所以在“完美地”完成了数据分析工作之后，笔者还需要单独把洞察和决策环节拿出来讲，是因为无论我们怎么努力，总还有一部分信息是无法通过数字化变成数据的。这也就意味着，我们通过数据对业务、产品和用户进行分析而得出的结论只是现实世界的一个很小的“子集”。（关于用户行为和业务抽象的问题，笔者放在第5章进行详细讨论。）如果我们只依赖于数据分析得到的结论来做决策，会忽略很多宝贵的经验和其他有价值的东西。这样，数据对我们的作用，就不再是“如虎添翼”，而是“一叶障目”。
1）数据洞察中的问题
笔者先从数据洞察讲起。在各种试图展示“数据对决策的辅助作用”的内容中，与洞察相关的案例都是很受欢迎的。洞察通常意味着，我们知道了一些“原来不知道”的东西，并且将它们应用到了业务和产品当中，从而可以更准确高效地对业务和产品进行优化。在这个过程中，与数据分析的不同点在于，我们要将数据分析的结果放到实际的业务场景中。
当我们把结果放到实际的业务场景当中时，很可能会发现一些有趣的现象。比如，我们的分析结论可能是一些早已知道的事情，甚至是不需要经过数据分析、直觉就已经告诉我们的事情，只不过我们通过数据分析把它们量化出来了，但这种量化的过程并不能改变事情原本的性质。
比如，对于自己手中的几款产品，或者在负责的几个渠道，我们心中明确地知道哪个好、哪个不好。即使通过数据分析把好的产品有多好、不好的产品有多不好量化出来了，依然改变不了这一事实。这就意味着，我们在这方面得不到任何数据分析的支撑，因为数据分析的结论并不能告诉我们应当如何改善现实的状况。因此，通过洞察我们需要在数据分析结论的基础上，发现更多具备可操作性的关键点，对这些关键点的调整将给业务和产品带来实际的改变。
可见，洞察不能是纯理论的，需要对业务和产品的迭代提供指导，并且是那些可以落地和确实有效的指导。当然，这其中的“可操作性”，有一部分是可以结合到数据分析当中的，也就是在数据分析的阶段就尽量保证结果具有“可操作性”。因此，在第4章介绍的通用的五步数据分析法中，笔者会特别强调“可操作性”。如果分析结论不具有可操作性，那就可以说一个单纯的兴趣驱使了数据加工过程，不会产生任何洞察，不会对业务和产品的优化提供有力的支撑。
同时，对于任何得到的洞察，我们在实际应用的同时，也要以相应的验证来保证这种洞察的持续有效性。在实际工作中，这会转变成一些自动化的、持续的数据分析和数据监控。当我们发现一些结论不再成立的时候，所谓的洞察也就失去了作用。
2）数据决策中的问题
在我们确信发现了一些此前不知道的优化点，并且这些优化点确实可以通过一些操作而达到之后，接下来就是选择的过程了。为什么还要选择？原因很简单，因为资源是有限的。虽然像金钱这种资源我们可以轻松地将其变为数字，加入数据分析的过程中，但是仍然有很多资源是我们无法用数据分析的过程来平衡的。比如，员工的注意力、兴趣、情绪，市场上的竞争对手和合作伙伴的态度，行业整体的发展态势和未来的发展方向等，这些都会对决策的执行效果产生很大影响，却没有太多直接有效的办法来对其进行精准的分析。
因此，“决策”这个真正影响到业务和产品发展的环节，与业务贴得更紧密，并且除了数据分析结论的支持，在数据无法支持的方面还要结合企业或团队的经营理念，以及个人在领域内的从业经验等。
在决策这个环节中，数据能够提供支持的就是解决“决策效率”的问题。虽然整个数据产品都旨在解决效率的问题，但是决策效率需要格外关心，它确实会直接地影响到业务和产品。
关于决策效率，可以分为两个方面。
一方面是在决策之前，需要获得数据的支持，也就是笔者在上文中反复讨论过的采集、统计、监控、分析的过程。决策者需要将这些结果数据作为决策的部分依据，再结合其他一些信息，最终做出决策。另一方面，决策之后还要对决策的结果进行持续的跟踪——持续跟踪决策产生的影响，及时反馈决策是否带来了预想的结果。
讲到这里，可能不少朋友会想到一个方法论——“快速试错”。没错！这就是一个快速试错的过程，能尽快让决策的结果反馈到决策者面前，为失败决策留出最宽裕的挽回空间，这几乎比任何事前的保证都能给决策者带来更大的勇气。特别是当决策的内容是创新的尝试时，我们根本无法提前给决策的结果做太多的保证，这时能及时看到结果就是最重要的。
至此，笔者与大家探讨了业务和产品层面亟待解决的数据应用问题，以及如何通过数据产品的支撑解决这些问题。不过，以上提到的这些数据应用问题，都属于“功能”问题，也就是应当通过数据产品提供怎样的产品功能，才能将业务和产品的工作流程补充完整。
如果各种工作流程在数据产品的帮助下，已经逐渐实现了闭环，那么接下来我们就需要对业务和产品进行进一步优化了。这时，我们就会脱离“功能”的层面，在各种已经搭建起来的“功能”之上，开始考虑“价值”的问题了。
2.1.2 “量入为出”的价值管理
在“功能整合”之上，“价值管理”是数据产品的另一个层次——我们不仅要让功能和流程更高效，还要让价值的创造更高效。
因此，接下来笔者要探讨的就是要利用数据产品来优化数据应用的效率。相对于数据的支撑应用，这就是数据产品的“从1到N”。
在现有的方案中，成本究竟花费在哪些方面？这里就用到了笔者在上文中提到的数据应用的三种常见投入和五种常见产出。在互联网行业中，由于互联网产品与数据的结合相当紧密，这些数据层面的投入和产出，也可以近似地等同于在搭建和运营互联网产品的过程中，需要考虑的投入和产出。
笔者在第1章中已经详细介绍过这方面的内容，因此在这里就不再赘述。需要强调的是，提高价值创造的效率，同样是搭建数据产品的重要目标之一。