本文主要面向读者为互联网行业相关从业人员，期望对企业数据平台有所了解的人群；因篇幅有限，文中所述的主题及相关概念点到为止。

一、什么是数据平台？

数据平台字面的意思是“数据+平台”：

• 数据：源于业务又作用于业务；
• 平台：基于数据也服务于数据。

整体看数据平台是由「数据流程」和「业务流程」两大运转主体共同构成的解决方案，两大主体相辅相成、互相依赖、密不可分。

• 从数据流程的视角看：不同业务类型企业的解决方案大同小异，目标都是为了保证数据整体的完整性、准确性、时效性；
• 从业务流程的视角看：不同业务类型企业的解决方案各有不同，本文中业务类型偏电商类。

二、数据的技术视角

数据从生产到应用的整体流程是任何一个数据从业者都绕不开的主题，即便是非数据领域的产品和运营同学，同样也应该对业务中数据的流向有个初步的认识。要展开描述，我们必须从数据的技术视角思考两个问题：

1. 需要解决的问题是什么？
2. 如何保证数据流中不同阶段的最优解？

1. 需要解决的问题是什么？

• 数据供给：提供便捷的数据生产方案，以数据产生为起点，规范数据整个主体的供给，为夯实数据平台的基础提供保障；
• 数据产出：保证数据在产出层面的普遍适用性。该阶段包括分析报表，自动化分析工具，查询入口等的建设；
• 过程管理：保证数据的完整性、准确性、时效性，实现数据从产生到应用全流程的高效管理。

2. 数据流的不同阶段如何保证最优解？

「立足现状，具体问题具体分析」，不同企业所处的业务发展阶段不同，所面对的问题会不一样。同样，业务本身特性及企业对数据建设的资源倾斜程度不同，也会直接影响数据全流程处理的差异。最重要的还是立足于现状，站在更高的战略视角去思考整体的解决方案。下面从技术视角以“数据流”为骨架展开讲解数据产生至应用各环节中我们分别需要做什么：

 2.1 数据产生

数据产生，这个阶段是最适合向业务方宣灌数据生产应用流程的阶段，因为该阶段的优劣将会直接影响之后的各环节。该阶段的关键字是「规范输入」，需要给数据上游的业务方提供可行的数据埋点规范（业务团队自身业务库除外）：

• 数据接入流程：需要对业务数据的接入流程做全面了解，重点从数据认知层面规避“不合理的输入”；
• 数据上报地址及API应用方法：确定API应用规范，保证数据上报位置准确，上报信息不被丢弃；
• 埋点规范及内容 ：在遵循数据接入埋点规范的前提下，保证各业务中具有差异性部分数据的完整性，通常会基于事件模型中的“who when how where what”几个关键要素设计埋点；
• 数据测试方法：数据测试方法也会依据埋点形式的不同而不同，一般分为前端和后端数据测试。前端常见测试抓包工具如“Fiddler”，后端通常将数据上报至测试服务器，捞取日志观察其完整性、实时性。

2.2 数据采集

数据采集，这个阶段是一个既主动又被动的环节。我们偶尔会收到xx业务方的疑问“为什么业务上线了，没有看到数据”，排查后才发现是因为模块日志并没有被采集。那该环节关键字便是「让日志被正确的采集」

• 针对现有业务：数据部门会提供给业务方不同场景下的模块日志采集方案清单，业务方只需按照现有清单选择模块上报，数据部门会自动收集；
• 针对新业务：数据部门会提供模块日志注册系统，形成良性注册机制，让数据部门提前感知，自动化收集模块数据。

 2.3 数据处理

数据处理、清洗是数据输入到仓库的前置阶段，该阶段关键字是「清洗规则」，目的是建立符合业务需要的数据清洗方案。比如什么格式的数据该被过滤；比如在广告投放中，用户符合哪种规则算是作弊用户；比如在用户行为数据中，符合哪种特征的行为算是爬虫用户等等。

2.4 数据仓库

数据仓库面向应用而生，该阶段的关键字是「分层、建模」。为了保证数据的普遍适用性及拓展性，会对仓库进行分层，通常分为：源数据层、数据仓库层、数据集市层、数据应用层。常见数据仓库模型为“星型模型”，星型模型就是一种典型的维度模型。我们在进行维度建模的时候会建一张事实表，这个事实表就是星型模型的中心，然后会有一堆维度表，这些维度表就是向外发散的星星。

 2.5 数据计算

数据计算是数据变活的过程，主要分为离线和实时计算，该阶段的关键字是「准确、稳定」。会按照不同业务单元的需要，设计数据指标，并按照不同场景中的业务逻辑确定统计规则，最终由系统实现例行计算。数据本身并不具备任何价值，但一旦我们将它变为衡量事情的标准、将它变为洞察业务的眼睛，它就有了不可估量的力量。

  2.6 数据应用

数据的应用是数据最终产生价值的部分，该阶段的关键字是「完善、洞察」。基于数据流前面的流程处理，该环节最终会提供给应用方业务报表、数据访问、自动化工具、统计模型等应用；以下描述了数据平台和数据应用方在应用阶段需要长期持续关注的问题：

• 数据平台：是否能提供完善的业务分析指标体系，是否能提供完善的精细化运营工具；
• 数据应用方：现有数据是否足够支撑业务分析，是否能依据现有数据发现更多的业务问题，是否能洞察潜在的商业机会。

2.7 元数据管理

元数据管理贯穿整个数据流程始终，是一个较为宽泛的概念，元数据治理的好坏将直接决定了整个数据平台的品质。元数据管理主要分为三部分：技术元数据、业务元数据、过程元数据。

• 技术元数据：如日志文件的路径/格式、仓库表结构、数据表血缘关系等；
• 业务元数据：如指标归属业务单元、业务描述、计算逻辑、业务类型等；
• 过程元数据：如表更新规则（增量/全量）、更新频率、更新时间、量级等依据以上，我们可以从技术视角总结出数据平台需要哪些东西，下图是参考示例：

三、数据的业务视角

基于立场的不同，导致了从业务视角与从技术视角看到的表现层内容会不一样，但究其本质是相通的。无论数据在应用层面以何种方案最终呈现，最终都是为了解决问题而存在；参考「黄金圈法则」我们同样也需要从数据的业务视角去思考三个问题：

1. 为什么需要数据团队解决？
2. 需要解决的问题是什么？
3. 该通过什么方式解决？

1. 为什么需要数据团队解决？(why)

「闻道有先后，术业有专攻」与「有所为而有所不为」，业务技术团队的定位是服务于业务一线，数据团队的定位是提供专业性的数据解决方案，二者分工上的差异性决定了解决问题的最佳路径。如下列举了需要数据团队解决几类问题：

1. 数据类型：数据产生场景复杂、数据类型多（行为、交易、用户、商品..），数据结构复杂（结构化/非结构化/半结构化数据）；
2. 数据量级：存储量级大，传统关系型数据库不能解决；
3. 数据处理：清洗规则多，计算任务流程长，计算血缘关系复杂等；
4. 数据应用：行为分析，多维交叉分析，实时多维分析，丰富的可视化等。

2. 需要解决的问题是什么？(how)

（1）我的业务是什么

不同业务单元依据自身业务属性，需要数据团队解决的数据问题也不一样。如市场团队关注应用市场投放相关的数据，客户端团队关注设备/应用版本/用户转化相关的属性数据，运营团队关注活动相关数据，风控团队关注风控相关数据等。

（2）我该如何衡量它们

团队属性的不同，也决定了量化到数据指标的衡量标注不同。各业务团队拥有自己的关键唯一指标和对应拆解/下钻的指标体系。

（3）如何让数据驱动业务

市场团队通过衡量不同渠道来源用户的质量，评估渠道ROI，优化投放策略；客户端团队通过观察不同产品方案的转化效果，改进注册及其他核心行为发生的主流程设计；运营团队通过用户细分，评估不同用户群在活动对的转化效果，进行精细化运营等。

3. 通过什么方式解决？(what)

以下从业务视角拆解数据平台产品解决方案：

3.1 实时监控

• 实时看板：专注于关键核心指标的实时表现，如用户、商品、订单等。视具体情况会将关键指标维度下钻后进行实时监控
• 实时电视监控：依据平台数据源，适用于电视投屏，监控看板展现等
• 红包/促销监控：关于红包主题的实时监控，观察业务中的红包发放/红包使用等波动情况，判断业务健康度
• 用户监控：监控用户活跃/用户新增的表现，与推送服务、品牌投放、投放等的业务动作进行相关分析，判断效果是否符合预期，及时优化策略动作
• 其他

3.2 离线分析

• 核心看板：企业业务发展所处阶段的不同，所关注的核心指标也不同，核心看板着重关注公司战略层核心指标在核心维度上的趋势及构成表现
• 业务看板：业务看板服务于不同业务团队，亦可视作各业务单元的核心看板
• 流量分析：描述用户从哪里来，不同渠道用户的后续核心业务表现。同时也承载渠道数据管理的工作（如渠道分组/渠道关系维护等）
• 用户分析：用户构成、用户留存、用户转化、行为、生命周期等场景的分析
• 商品分析：商品构成、库存、售出、质量、商品生命周期等场景的分析
• 交易分析：主要用于交易主题的多维交叉分析，用户与商品在交易链路上的具体表现，如：曝光→浏览→咨询→下单→支付→售后等链路的分析
• 专题分析：搜索推荐分析、风控分析、竞对分析、垂类分析、运营位分析、垂类专区分析、活动分析等
• 其他

3.3 精细化运营工具

• 事件分析：基于事件模型的自动化分析工具，业务方可依据行为埋点查询到不同行为事件的用户表现
• 事件漏斗分析：基于事件模型的自动化漏斗分析工具，可自行设置业务转化漏斗，观测各精分业务流程中的转化效果，拆解转化问题
• 留存分析：按照留存模型，起始行为精分用户群体，依据精分用户群不同行为频次的表现，观测各层用户的留存
• 画像分群：按照不同主体拆分属性，通过属性组合，筛选目标分群，进行精细化运营（1.用户分群：以唯一用户ID为主体，组合用户的不同分类属性，筛选目标用户群，做差异化运营或用户分析；2.商品分群：以唯一商品ID为主体，组合商品的不同分类属性，筛选目标商品群，做精细化商品分析；3.订单分群：以唯一订单ID为主体，组合订单的不同分类属性，筛选目标订单群，做精细化交易分析）
• SQL查询工具：可视化SQL查询
• 其他

 3.4 智能预警及分析

• 实时异常分析：实时异常分析基于历史数据，获取当前时间点的可能数值范围，当实际值在该范围以外时，即认为数据异常。关键要求是及时和准确
• 智能分析：具体策略是对关键核心指标进行维度拆解，寻找出影响核心指标波动中不同维值的“贡献度”，最终定位问题
• 其他

3.5 其他解决方案

• 自动邮件：通过配置化的方案，实现数据报表的自动邮件推送。也可以在离线报表上设置开关，发送具体页面数据表到指定邮箱
• 数据分析：如：商品分析、交易分析、转化分析、DAU预测、订单预测等
• 数据挖掘：通过聚类、回归、关联规则等常见挖掘算法分析问题，发现机会
• 外部数据：竞对数据抓取及分析
• 其他

依据以上，我们可以从业务视角总结出数据平台产品矩阵，下图为参考示例：

四、最后

我们在实际工作中，技术视角和业务视角应该是交叉共存的。即在沿着技术视角去开展数据流链路上的工作时，也需要同时关注业务本身的情况，设计出更优雅的解决方案；同样在业务视角应用数据手段去推进工作时，也需要关注数据流中各阶段上潜在的问题与风险点。

道阻且长，溯洄从之。

作者：蒋坤伟，转转产品经理；个人公众号：黑夜月

本文由 @黑夜月 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自 Pexels，基于 CC0 协议