业务链路升级中如何做数据洞察？

数据洞察是业务中台赋能业务的有力工具，对业务产出数据洞察能力，也是我们一个非常大的命题。

概述

关于数据相关的词条很多，虽然有不同的定义，但是本质上是相辅相成，通常结合使用才能拿到结果。类比词条诸如：数据分析，数据挖掘，数据洞察。

以下为wiki上的定义：

数据分析：是一种统计学常用方法，其主要特点是多维性和描述性。有些几何方法有助于揭示不同数据之间存在的关系，并绘制出统计信息图，更简洁地解释这些数据中包含的主要信息；
数据挖掘：是一个跨学科的计算机科学分支。它是用人工智能、机器学习、统计学和数据库的交叉方法在相对较大型的数据集中发现模式的计算过程；
数据洞察：这一项目前没有wiki词条，基于普遍认知，是基于数据分析和数据挖掘，结合业务场景后，围绕业务链路定义统一口径，进而更好地分析问题，并且能够进一步做策略改进。

三个分析手段本质上都是对数据进行加工获取信息，但是目标不尽相同，以下是我个人的理解。

数据分析更侧重，基于人的理解动线，结合人对业务和数据的理解，产出分析结果，这里更加强调人的分析；
数据挖掘同理数据分析，只不过角色从人变为了机器；
数据洞察是在数据分析和挖掘的基础上，引入了业务场景的概念，梳理出围绕业务场景结果的影响因素和链路，目标是对抽象问题进行归因、拆分以及更好更快地形成改进方向。这个也是我们业务开发同学最有优势的地方。

核心要素

我们发现，数据洞察的理解，实际上可以分为几个核心要素，下面逐一来简要说明：

数据
干净有效的数据才是我们要的数据，否则会误导后续的结论。e.g. 登录链路因为是业务安全水位保证的第一环节，经常有来刷的流量，如何避免因为灰黑产的流量，影响后续的判断，这个也是重中之重。

业务场景
业务场景是区分数据洞察和其他数据分析方式的核心区别，也可能是业务同学区分bi分析的最大价值点。任何分析策略都脱离不开对业务场景的理解，而不是单纯的理解数据。定义“一次完整业务链路行为”是核心，围绕着一次行为链路，才能就链路分析有用的策略。

口径
口径是什么？我理解口径是在合理的数据维度和好的目标的基础上对业务场景的理解，口径上也会结合对业务场景的理解和对业务目标的理解，数据维度可能是多种多样的。

还是以登录举例，正常的理解，一个用户在一个设备上登录是正常情况，但是手淘会出现多账号登录同设备，这个也是常态数据特征，那究竟在定义登录成功率的时候，是使用设备维度（认为同一个设备只要有一个用户登录成功即算设备成功）还是使用用户维度（只看用户维度数据，不结合设备定义指标），也是需要考量的。

数据建设

数据的清洗是保证数据有效的手段
我们获得的各种打点框架和不同的数据源，可能维度和信息量都是不统一的，比如有的数据源有设备信息但是没有用户信息，有的数据源有用户信息但是设备信息不完整，甚至同一个时间字段格式也是不统一的。

这个时候就需要先对数据进行加工了，剔除脏数据，补充遗漏点位，加工出干净的单维度信息，并且保证各数据源数据加工出的数据维度和格式统一，比如标准的设备id或者用户id及时间等。

数据建设是补充也是演进
数据质量问题，不只要从数据的清洗看，也要从数据产生的点来看。如果数据有缺失或者不统一，数据清洗又搞不定，就需要进行开发了，比如数据库增加字段，打点框架增加打点逻辑。

数据建设是一个长期的过程，不止是为了补充现在要分析的内容，也是要形成一套标准的交付产物。更进一步，日常做需求和项目的时候，打点数据质量也是要考虑的，毕竟做需求上线不是结果，拿到业务目标才是结果。

业务场景

业务场景的定义
业务场景是在整个业务洞察中最特殊的一个环节。这个环节定义的好坏，直接影响了问题拆分结果的有效性。

不同的业务场景具备各自的特殊性，需要结合业务特性来分析。按照目前我的经验来看，业务场景的定义也是有一些核心方法的。

业务场景中，最终产物是谁？

还是以登录举例，登录的最终目标肯定是为了下发登录态，否则也没有人回来“玩一玩”登录，那围绕下发登录态的链路，就是我们想要的业务链路。

其他的业务也同理，比如订单的话，是围绕库存来跑；

业务场景中，你需要分析的维度是多深？

这个也比较好理解，以上述例子继续说，要看登录业务链路的话，需要拆分多种登录方式不同的链路来看？还是说看一个总的登录链路就够了。

这个维度就只能看分析问题的层次了，一般在洞察初期，当然是维度越细越好，但是越分析往后，维度会逐渐上升，因为随着对业务的洞察，会发现有些维度虽然深了更完整，但是是分析不出问题的，也就是“过度分析”了。

业务场景中，你要定义“一次完整业务行为”

数据洞察区分于其他分析方式，最大的优势是在于结合了业务场景，那直击业务结果的，一定是完整的业务链路。

这个点不举例不太好说明，举个例子，登录过程。

正常打点是下面这种样子的：

表1

这两条离散的打点就是一次完整登录行为，但是是基于rpc请求维度的表达。
结合业务场景定义的数据结构演进
打点数据描述了一个阶段性的结果。上面例子描述的，就是用户在2021-12-1 11:20:54发起了一次账密登录请求，但是因为环境不安全，安全挑战要求核实身份（比如发短信核实），用户操作了核身操作，在2021-12-1 11:21:20发起了免登，下发了登录态。

这个就是一次登录行为。业务洞察的核心也是围绕这个点进行。

假如我们的分析维度，是总的登录维度或者分登录方式的登录维度分析，这个两条数据的打点其实就不适合我们，我们仅需要登录方式，最终结果，时间以及设备id就够了。

表2

或核身没有通过

表3

但是我们也会发现，这个数据描述的行为并不完整，比如表2并不能描述登录过程经过了核身这个特性。

这个时候，我们就需要数据结构进行下一个阶段的演进。

我们引入了statustag来描述路径。

statustag格式：0⁰12|0¹abcde.

前后经过|分割为两种格式，第一个格式为bitmap，表示0版本；第二个格式为字符串，表示1版本格式，字符串为经过的未加到bitmap的节点（埋点毕竟不是强要求，总有需求上线后，没有加bitmap）。

这个tag描述经过的路径为，经过bx1100结果，经过了一版本的4和8的节点，和二版本的abcde节点。

有了这个tag，就可以描述更多的信息。

业务场景数据的可视化表达
单纯的数据并不容易洞察，也不是长期运营治理的合理方式。这个时候我们就需要可视化来搞事情。

可视化的内容包含我们想要表达的内容，比如漏斗，比如曲线。

目前可视化表达常见的是漏斗和报表。

漏斗举例

图1
做漏斗很麻烦，需要一个点一个点手动定义。但是漏斗对初期理解链路，分析问题益处非常大。

这个时候我们需要的，是可以通过结构化的数据源，来快速生成可视化漏斗。

我们可以通过生成数据的时候就指定约定来快速生成结构化数据。

基于状态机+约定打点

引入状态机变化记录打点日志；
结合结构化的画图能力，定向输出约定日志，动态画图

状态机的核心要素

statusTag记录路径信息；
status和old_status记录节点上下游信息；
depth记录节点深度；

最终产出的一次登录行为登录数据

口径

口径是基于数据和业务场景的产出结果。口径也是最重要的点，口径代表了我们基于数据和业务场景对业务结果的理解，比如登录的口径，在财年初定义，登录成功率从9x%提升到9y%，这个提升空间，也是根据数据来计算的。

口径不要经常变动
口径一旦定义下来，就不要经常变动。因为一般定义口径是最难也是最耗时的，定义口径的时候，一般我们已经完成了对目标的拆解，机会的洞察和最终的测算。

口径并不一定是单一口径
除了上述特性外，口径也会有单口径和多口径，一般都会同时存在，比如登录过程，在一个总的口径基础上，哪怕是一次登录行为，我们也会拆分多个业务阶段。

还是以登录举例，我们把用户从进入页面开始，到发起登录行为，定义为意愿口径，从登录行为开始到登录结果，定义为成功率口径。这两块要解决的问题是不同的，揉到一起，会导致问题变得复杂，不利于分析。

多口径也有一个好处，我们可以做阶段性的工作，在不同的阶段，处理多口径中其中一部分的链路升级。

口径维度定义
口径维度定义需要结合场和业务的特性，哪怕是同一个业务链路，可能在不同场中，不同人群定义，也是不同的。

这块不好说明，举个例子。

我们C端口径定义上，是设备维度，因为C端用户，天然存在薅羊毛行为，我们会认为一个设备的登录成功，对于C端就是有益处的。

但是同样是登录链路，B端定义上，就是用户维度的，因为B端商家的个体价值都很大，而且不太存在类似C端薅羊毛的行为，用户维度能让我们更好的看到用户行为，以便做体验上的优化。

小结

在数据洞察方面，我们也还在学习和实践的路上，并在这条路上已经取到了一定的结果，但是未来空间还是很大。

这条路对于业务开发是一个有优势的路，而且业务平台在业务场景的丰富度上也是独具优势，我们可以在数据洞察做的事情上更加自由。

欢迎大家来一起讨论，也欢迎大家来一起探索。
业务链路升级中如何做数据洞察？