1.1 数据产品的关注点

截至本书编写时，提到数据产品，大家最直观的认知是与数据相关的产品就可以叫“数据产品”了。但在互联网的世界中，各种产品都或多或少同数据有关，特别是那些偏向中台和后台的、不直接面向终端用户的产品。比如，运营平台、营销平台，以及更加通用化的配置平台、管理平台等。

其中一部分平台产品，甚至已经涵盖了一些基本的数据分析功能。比如，在运营平台中，可以看到新增用户数和活跃用户数。同时随着业务规模的扩大，这些平台也逐步加入了“大数据平台”的行列——需要应对海量数据，需要考虑数据存储和计算性能之类的问题。

难道这些平台就是“数据产品”了吗？大家心目中典型的“数据产品”应当具备以下功能：支持对各种数据的自由处理，最终做成各种美观的图表或数据报告，还可以在业务出现问题的时候及时提醒相关方采取措施等。与这种概念相比，上文中提到的平台似乎还差了一点儿。

因此，这种理解只能算作对数据产品的大致认知，至少还没有偏离“数据”这个核心。但这个定义并不确切，因为这个定义完全不能告诉我们数据产品要做什么、为什么要做和会有什么困难等关键信息，同时还可能给那些刚刚开始接触数据产品的朋友造成误解。

对于数据产品，笔者给出了一个相对合适的定义：数据产品，是为了提高数据应用效率而产生的产品，包括平台型产品、系统功能模块、移动端App等多种具体形态。

这个定义中有两个词需要解释：“数据应用”和“效率”。

先说“效率”，因为这可能是“数据产品”和“与数据相关的产品”之间的最大差别。效率等同于数据应用过程中的ROI（Return on Investment，投资回报率）。常见的数据应用效率问题，包括如何减少人力投入、如何缩短数据处理的时间周期、如何降低出错概率、如何确保准确性、如何提高及时性、如何提高数据的精细度等。这部分内容很重要，笔者在后续章节中还会对其进行展开和细化。

其次是“数据应用”，这个概念相对容易理解。简单来说，数据应用就是使用数据的过程。从数据处理的角度来讲，其内容包括数据的采集、存储、计算、可视化、消息触达等；从数据治理的角度来讲，其内容包括集成、治理、质量保证等；从应用目的的角度来讲，其内容包括统计、监控、分析、洞察，以及基于数据的决策等。这些都属于数据应用的具体场景。

那么这两个词拼起来，为何就能定义“数据产品”了呢？

举个简单的例子，在没有数据产品之前，做一份数据分析报告，需要一位分析师手工完成从数据提取、计算、可视化，到分析、总结、报告撰写的整个流程，耗时3个工作日。而有了数据产品之后，提取、计算和可视化的过程，可以依据事先配置的任务自动完成，甚至还可以标注出需要特别关注的关键信息点，整个流程不超过10分钟。因此，在数据产品的帮助下，一位分析师做一份数据分析报告的时间周期，从3个工作日缩短为0.5个工作日。这个过程就被称为数据应用效率的提升，是数据产品存在的意义和价值。

上文中提到的那些产品，虽然也会考虑到效率问题，但并不会将数据应用的效率作为最核心的考虑因素。它们关注的核心点，可能是执行运营策略的便利性（效率）、改变活动策略的便利性（效率）、改变系统配置的便利性（效率）等。

当然，在数据产品搭建的初期，“有数可用”确实是首要的目标。比如，采用在运营平台中植入一部分数据分析的功能模块的实现方案。但当数据产品作为相对独立的产品形态出现时，就不能仅限于此了，需要时刻关注在数据应用的全链路中哪个环节是效率的“重灾区”，并针对这个环节进行重点优化，提升数据应用的整体效率。