前言

早些年刚入行数据产品时，市面上没有相关书籍供阅读，在众多数据分析和数据工程化的书籍中，车品觉的书给我留下了深刻印象直到现在也反复翻阅。记得 2017 年在看他的《决战大数据》中有这么一句话：

“把分析的理念和框架变成数据产品，本质上是一个数据泛化的过程。这个过程非常重要，因为数据报告的需求会越来越多，如果没有泛化数据给使用数据的人，分析团队将永远被冗杂和重复的工作所困”

当时对数据产品的理解还比较浅薄，仅停留在功能层面，看到这句话其实并无太大感触只觉得是正常的官话而已，去年重新翻阅的时候才重新体会到这句话的真正含义：数据团队对于业务来说，到底是价值，还是成本？每个公司的数据团队已经有了足够多的人，做平台，数仓，工具，报表，提数，标签，看似尝试了足够多的事情，同时也做了一定的需求把控，优先级排序，价值提炼等等。但我们终究是被业务裹挟着在跑，业务的急速增长就同步裹挟着需求的增长，导致数据团队增长，这种组织新式肯定是不可持续的。那在陪着业务成长过程中，数据团队究竟可以沉淀出什么，一方面能提高数据团队的工作效率，一方面是产生出更多的价值。也就是书中所说的“如果没有泛化数据给使用数据的人，数据团队将永远被冗杂和重复的工作所困”。

从人工分析向人机协作的推进，最终实现机器分析，有了这样的明确目标以后，下面的工作就是要进行分析工作的产品化，也就是我在《数据产品经理实战 - 由 BI 到业务洞察》一文中产品化的第四阶段，BI 系统要实现数据监控到业务洞察的演进。本篇也算是填上《数据产品经理实战 - 由 BI 到业务洞察》结尾处埋的坑，接着 BI 产品化的第四个阶段业务洞察，谈谈 BI 的智能化演进方向。

业务洞察实践

业务“为什么涨、为什么降、原因是什么？”这是数据从业者经常面对的灵魂三问，为了找出数据发生异动的原因，业务人员会通过使用多维查询、excel 导出，hue 查数等数据产品锁定问题，再辅助人工分析查找问题原因。但这本身属于业务移动的常态分析却因为老板的一句话数据团队就需要耗尽很久，导致数据团队疲于奔命。

定义业务洞察

首先我们明确定义好业务洞察这个名词，对齐好如果我们做业务洞察这事儿的目标，我这里下的定义是认为业务洞察包含了这四大类业务诉求：

• 业务描述：讲清楚业务发生了什么，强调已经发生过的事情

• 业务诊断：对业务异动进行诊断，讲清楚为什么发生

• 业务决策：对于已经出现了这样的现状，需要做什么样的决策

• 业务预测：预测未来将要发生什么，强调未发生过的事情

分析工作的产品化要做的就是把上述这四个方向的业务诉求抽象出来，使用数据分析模型和标准化流程对数据能力进行泛化，进行产品化的包装供给业务使用。

业务描述

业务描述：讲清楚业务发生了什么，强调已经发生过的事情

要对业务已经发生过的事情进行描述，在不考虑数据口径单纯从工具上来说，市面上的各种 BI，excel 都已非常成熟，各种透视，图表天花乱坠，每个业务没个几千张报表都不好意思说自己有个 BI。所以业务描述这一块重点要解决易用性的问题，从众多报表的观察视角进行收敛，减少用户的阅读成本，半年前写的文章《数据产品经理实战 - 由 BI 到业务洞察》一文中产品化的第四阶段，有提到过这么几句：

想看数据的人潜意识里是要成“体”的数据的，只是沟通过程中变成了一个一个“点”的需求，因为“点”简单容易讲明白，也便于我们去实现。就和我们读书和学习某项技能一样，书里总是一个个点的技能教我们，随着“点”技能的增多，知识点串联起来就形成了体系化的技能树，我们就有了解决复杂问题的能力。所以“体”的数据才是真的意义上的用户诉求，核心报表的 OLAP 多维分析，级联筛选，上卷下钻，都是在解决由“点”到“体”的问题。

之前单个的报表都是在解决“点”的问题，多张报表是可以形成“体”，但是层次解构和易读性特别差，所以需要将报表中的“点”的指标抽离出来按照逻辑结构进行层次划分，形成指标逻辑树，解决“体”的问题

大量的报表最终都是为了描述清楚业务，但业务模型的异动问题肯定有一个核心的内部结构，这个内部结构就是指标体系，将指标体系赋予业务描述的产品价值就形成了指标逻辑树，逻辑树是表达指标(问题)内部结构的最佳方法，适用于业务多数指标的问题描述与诊断。

对于查看数据的人来说，一共有两种查看逻辑：

1、横向，对于自己核心关注的业务流程，按照业务流程一层一层的往下拆，对于重点关注的原子指标不断的下钻拆分，拆解出更多的派生指标进行查看。

2、纵向，对于某单个指标按时间周期查看其同比，环比，近 7 天，15 天，30 天的数据情况

那我们按照这个思路进行产品化探索，一是要能满足汇总指标的多维度拆解，直到拆不下去为止，能看到最细粒度的派生指标，二是能进行每个派生指标的深度分析，跟着时间周期的变化要展示出来。

对于想查看每个指标的的时间深度情况，可以点击具体的指标卡进行时间周期查看。

在没有该产品之前，以往业务侧看到的是各个环节的数据点报表，在指标逻辑树中，业务同学看到的是随业务流程变化以及单个指标多维下钻的全景图，只要数据模型对应的大宽表以及关联逻辑做的好，我们就可以直接拆解到具体的执行层，整个链路上哪一个节点（执行层）出现的数据异常和波动异常一目了然，清晰可见。

当然对技术敏感的同学见到这个肯定会想到技术能力的支持是系统的关键，没错。这里有两个点，一是对于 OLAP 引擎要足够给力，比如像头条就养了几千台 ClickHouse 来做所有数据应用的分析，CK 的运维成本不低，具体的架构选型和运维取舍由技术侧来定，产品侧做好试用场景的确认，保证研发投进去的资源拳拳到肉；二是数据模型要设计好，数据质量要足够高，各个指标之间的关联关系要设计好，好的模型设计会极大减轻 OLAP 引擎的计算压力，如果指标下钻时间太长，经常报错，业务用不了几天就丢弃了。

业务诊断

业务诊断：对业务异动进行诊断，讲清楚为什么发生

有了指标逻辑树我们可以看到整个业务的全貌，下一步就需要找到关键指标的波动原因，对单一指标进行细分维度拆分，锁定细分维度对整体的影响，将波动分析问题转化为构成分析问题，这就是业务诊断的核心。

首先指标的异动来源于两个方面，一是维度影响，单指标多维度分析；二是指标影响，多指标相关性分析，回顾下我们在数据分析报告里是怎么解读指标异动的，举例子：

今天 GMV 大涨 20%，因为母婴品类 GMV 整体上涨 20%，这是单指标多维度分析；今天 GMV 大涨 20%，因为整体订单量涨幅 11%，这是多指标相关性分析。

对于 GMV 大涨 20%这个异动来说，我相信不会有分析师会按照“整体订单量涨幅 11%”这个作为分析结论，因为它没有分析到具体执行层，跟着维度下钻是要落地到具体的执行层的。我们常见的分析报告均已单指标多维度分析为主，所以这里我们重点讨论单指标多维度分析。

当然这里额外提一点我之前的想法，为了能让指标的拆解更加落地到执行层，我曾经尝试给核心指标再多增加一层维度。回想一下数据分析的报告原因可以分类哪几类？一是流量端，本身自己导流的产品出现的流量异动，二是政策端，国家以及监管各类大环境下的政策背景所引发的异动，三是营销端，通过人工干预和运营工具所引发的异动。如果这个假设成立的话，是否可以按照这个思路进行产品设计？我是这么设想过，但流量端，政策端，营销端的数据没法通过数据库直接拆解量化出来，比较难以实现，后续还需要持续探索。

好了回到我们业务诊断的产品设计上，下图是单指标诊断分析的示意图：

通过上面的图可以看出，单个指标的异动波动均可以拆解至下钻叶子节点上，在上述的例子中：

指标 A：基期（左边的图）的数据是 100 万，同比数据（右边的图）上涨 20 万，至 120 万

指标 a：基期（左边的图）的数据是 25 万，同比数据（右边的图）下降 25 万

指标 b：基期（左边的图）的数据是 25 万，同比数据（右边的图）上涨 45 万，至 70 万

那么在叶子节点 a 和 b 一起发生异动的时候对整体目标的影响为-25+45=20，一级总指标 A 上涨 20 万。然后计算各叶子节点对总指标的影响度大小，指标 a=|0-25|/20=1.25，指标 b=|70-25|/20=2.25，影响度 2.25>1.25。

对于上述的异动分析过程配合基尼系数就可以得到诊断分析报告：“因为指标 2 的大范围波动（同比上升 45），与指标 1 的小范围波动（同比下降 25 万），导致一级总指标 A 整体当日进行 20 万的增长”

即通过影响度计算的方式进行排序，波动值最大的最为靠前为主因。我这里举的例子比较极端，叶子节点 a 和 b 的影响程度是超过 100%的，实际业务中这类情况一般不会出现，（当然如果真的出现了轮不到数据分析来定位，老板和业务后台早就炸了）。所以从实际情况出发，这里的影响度也可以称之为贡献度，贡献度 x100%以后成为贡献率，贡献率（%）=某因素贡献量（增量或增长程度）/总贡献量（总增量或增长程度）×100%，贡献率可以通过简单算法直接计算出来，形成自动化诊断报告。

业务决策

业务决策：对于已经出现了这样的现状，需要做什么样的决策

泛化管理层的执行动作。回想一下打开 BI 看数的工作流程，首先一进 BI 看到业务的现状（业务描述），发现数据异动并找到了原因（业务诊断），接下来根据发现的原因要做决策（业务决策）。那我们尝试对业务线管理者的下一步工作进行泛化，一般来说，管理层的执行动作有“关联分析”和“运营干预”两类工作

1、关联分析，对指定数据进行进一步分析，消息推送。对管理层来说，业务诊断已经将该指标所有维度的异动数据全部挖了出来，但业务中经常会存在没有数据关联，但有逻辑关联的数据，比如异常订单的明细，ID 明细等等。

2、运营干预，将满足特定条件的数据（标签）推送至数据消费系统（业务系统，运营系统，CRM 等），进行运营触达。当管理层看到相关的异动数据，进行人为的抑制和拉高。比如大促的订单未达到预期，系统将推送特定名单给到运营系统，进行优惠券下发，刺激订单的上涨。

那在上述过程中，如果进行产品化我们需要引出决策事件的概念，如果 A+那么 B，A+B 我们称之为决策事件。BI 工具常见的数据监控和预警功能就是最基本的业务决策，如果今天金额同比下降 10%（A），那么就进行邮件，钉钉，企微消息推送（B），再比如大促的订单未达到预期（在晚上 18:00 未达到 2000w 单），那么系统将推送特定名单给到运营系统，进行优惠券下发（对 100W 历史用户 id 进行数据推送，进行优惠券与短信 push 的触达），这就是我们可以泛化出来的业务决策。每个业务决策后台会对应一组数据的调度任务，这些调度任务是这个功能模块设计的核心，需要我们和数据开发同学好好梳理落地。

泛化管理层执行动作后，进行产品化，这里我们重点要做的功能是配置决策事件，按照基本的产品设计原则，有配置就有列表，有配置就有执行，所以基本会有三个模块配置页，列表页，执行调度页，这里和小爱同学的智能场景是一模一样的，可以直接参考小爱的智能场景产品逻辑进行设计，没有难度：

坦率的说业务决策这个功能有很大的局限性，在实际工作中真正可以产品化决策场景是十分有限的，就是推数据，发消息，更进一步的动作就要涉及到运营系统的数据交互，一方面运营系统是否允许 BI 能进行流程自动化对接，另一方面如果能自动化触达进行触点发送，BI 系统是否能进行风险兜底，这些都是需要考虑的问题。我目前建议，考虑到 BI 系统自身定位和边界，如果要上业务决策模块，数据推过去就可以了，不进行系统功能层面的对接。

业务预测

业务预测：预测未来将要发生什么，强调未发生过的事情

业务洞察最后一个产品化工作就是业务预测了，这里反而是产品力最弱的一部分。实际工作中，无论是基于各类线性模型和树模型最终输出的业务预测值，更多的也只是参考意义，对实际运营和决策工作并无太大价值。所以我们把业务预测当做业务描述的一个信息补充，具体的产品设计可以在业务描述中将未来一段时间的业务预测值直接展示出来，做好视觉区分，预测值是通过回归算法或者业务规则数据产品自己和业务沟通来定。

结语

数据产品经理这几个字，最重要的是什么？

想起曾经对 BI 平台的深度用户一起聊过，发现用 BI 平台最多的反而是做报表的人不是看报表的，这点出乎意料之外，带着这个认知和越来越多的用户和产品经理交流过，大家都得出一个结论，就是现在 BI 工具在公司内的定位现在逐步尴尬了起来，对于做数据报表的人而言，数据的入库清洗管理，指标的统计核算，到丰富的数据可视化组件，以及最终灵活的自定义创建报表功能。功能很多很全，普通用户就是懒得用，或者抱怨没法满足奇奇怪怪的个性要求；作为看数据报表的人而言，产品的上手门槛高，又是交互式拖拉拽，又是自助订阅，业务侧的产品，运营，推广人员的需求需求只是辅助他业务决策工作的一部分，固定有人写 sql 捞数据可能更加及时与准确，不一定非要使用这些功能。

作为使用 BI 平台最多的数据分析人员，大部分分析员都戏称自己为“表哥”“表弟”，他们每个人每天都要做很多报表，被业务裹挟着在跑，同时做出来的报表也能被人看的也不多。作为兄弟组的数据产品经理，我很能理解他们，大多人都不怕辛苦，怕的就是做出来的东西没人看。

我们的确可能见过很多高大上的平台，自助式机器学平台，实时计算平台，BI 增强分析平台等等，所有的功能是否真的为业务带来的价值，能帮到别人提高分析效率，很多为了“技术驱动”而作的产品，倾尽部门最终实现的是技术的自我表达，但最终无法回归到产品价值上。

回到数据产品这四个字本身，重点究竟是数据，还是产品，我的回答是我们首先是一个产品经理，然后再是一个数据产品经理。所以业务洞察设计之初，一方面是想将数据分析能力泛化下沉至业务侧，释放更多的初阶数据分析能力，减少数分的工具人标签，做好“数据”，另一方面也是想尝试用自己对用户的理解去改善 BI 工具使用的问题，能更好产出业务价值，做好“产品”。

本文也是参考了业内些许材料，如果现阶段你也对 BI 平台的价值演进有探索的话，希望本文能为你带来帮助和启发。