网站开发分为几个方向,网页设计站,网站建设费怎么做分录,阿里云虚拟主机 wordpress简介#xff1a;关于数据相关的词条很多#xff0c;虽然有不同的定义#xff0c;但是本质上是相辅相成#xff0c;通常结合使用才能拿到结果。类比词条诸如 数据分析#xff0c;数据挖掘#xff0c; 数据洞察。本文将聊聊我们在业务链路升级中做的数据洞察。 作者 | 金铎…简介关于数据相关的词条很多虽然有不同的定义但是本质上是相辅相成通常结合使用才能拿到结果。类比词条诸如 数据分析数据挖掘 数据洞察。本文将聊聊我们在业务链路升级中做的数据洞察。 作者 | 金铎 来源 | 阿里技术公众号
一 概述
关于数据相关的词条很多虽然有不同的定义但是本质上是相辅相成通常结合使用才能拿到结果。
类比词条诸如 数据分析数据挖掘 数据洞察。
以下为wiki上的定义
数据分析是一种统计学常用方法其主要特点是多维性和描述性。有些几何方法有助于揭示不同的数据之间存在的关系并绘制出统计信息图以更简洁的解释这些数据中包含的主要信息数据挖掘是一个跨学科的计算机科学分支。它是用人工智能、机器学习、统计学和数据库的交叉方法在相对较大型的数据集中发现模式的计算过程数据洞察这一项目前没有wiki词条基于普遍认知是基于数据分析和数据挖掘结合业务场景后围绕业务链路定义统一口径进而更好的分析问题并且能够进一步做策略改进。
三者分析手段本质上都是对数据进行加工获取信息但是目标不尽相同以下是我个人的理解。
数据分析更侧重基于人的理解动线结合人对业务和数据的理解产出分析结果。这里更加强调人的分析数据挖掘同理数据分析只不过角色从人变为了机器数据洞察是在数据分析和挖掘的基础上引入了业务场景的概念梳理出围绕业务场景结果的影响因素和链路目标是对抽象问题进行归因、拆分以及更好更快的形成改进方向。这个也是我们业务开发同学最有优势的地方。
二 核心要素
我们发现数据洞察的理解实际上是可以分为几个核心要素。 这里我们逐一来简要说明。
1 数据
干净有效的数据才是我们要的数据否则会误导后续的结论。e.g. 登录链路因为是业务安全水位保证的第一环节经常有来刷的流量如何避免因为灰黑产的流量影响后续的判断这个也是重中之重
2 业务场景
业务场景是区分数据洞察和其他数据分析方式的核心区别也可能是业务同学区分bi分析的最大的价值点。任何分析策略都脱离不开对业务场景的理解而不是单纯的理解数据。
定义“一次完整业务链路行为”是核心围绕着一次行为链路才能就链路分析有用的策略。
3 口径
口径是什么我理解口径是在合理的数据维度和好的目标的基础上对业务场景的理解口径上也会结合对业务场景的理解和对业务目标的理解。数据维度可能是多种多种的。
还是以登录举例正常的理解一个用户在一个设备上登录是正常情况但是手淘会出现多账号登录同设备这个也是常态数据特征那究竟在定义登录成功率的时候是使用设备维度认为同一个设备只要有一个用户登录成功即算设备成功还是使用用户维度只看用户维度数据不结合设备定义指标也是需要考量的。
三 数据建设
1 数据的清洗是保证数据有效的手段
我们获得的各种打点框架和不同的数据源可能维度和信息量都是不统一的比如有的数据源有设备信息但是没有用户信息有的数据源有用户信息但是设备信息不完整甚至同一个时间字段格式也是不统一的。
这个时候就需要先对数据进行加工了剔除脏数据补充遗漏点位加工出干净的单维度信息并且保证各数据源数据加工出的数据维度和格式统一比如标准的设备id或者用户id及时间等。
2 数据建设是补充也是演进
数据质量问题不止要从数据的清晰看也数据产生的点来看。如果数据有缺失或者不统一数据清洗又搞不定就需要进行开发了比如数据库增加字段打点框架增加打点逻辑。
数据建设是一个长期的过程不止是为了补充现在要分析的内容也是要形成一套标准的交付产物。更进一步日常做需求和项目的时候打点数据质量也是要考虑的毕竟做需求上线不是结果拿到业务目标才是结果。
四 业务场景
1 业务场景的定义
业务场景是在整个业务洞察中最特殊的一个环节。这个环节定义的好坏直接影响了问题拆分结果的有效性。
不同的业务场景具备各自的特殊性需要结合业务特性来分析。
按照目前我的经验来看业务场景的定义也是有一些核心方法的。
业务场景中最终产物是谁
还是以登录举例登录的最终目标肯定是为了下发登录态否则也没有人回来“玩一玩”登录那围绕下发登录态的链路就是我们想要的业务链路
其他的业务也同理比如订单的话是围绕库存来跑
业务场景中你需要分析的维度是多深
这个也比较好理解以上诉例子继续说要看登录的业务链路的话需要拆分多种登录方式不同的链路来看还是说看一个总的登录链路就够了。
这个维度就只能看分析问题的层次了一般在洞察初期当然是维度越细越好但是越分析往后维度会逐渐上升因为随着对业务的洞察会发现有些维度虽然深了更完整但是是分析不出问题的也就是“过度分析”了。
业务场景中你要定义“一次完整业务行为”。
数据洞察区分于其他分析方式最大的优势是在于结合了业务来分析业务本身那直击业务结果的一定是完整的业务链路。
这个点不举例不太好说明举个例子登录过程。
大家有想过打点会是什么样么和一次完整业务行为会有啥差异么。
正常打点是下面这种样子的。 表1
这两条离散的打点就是一次完整登录行为但是是基于rpc请求维度的表达。
2 结合业务场景定义的数据结构演进
打点数据描述了一个阶段性的结果。上面例子描述的就是用户在2021-12-1 11:20:54发起了一次账密登录请求但是因为环境不安全安全挑战要求核实身份比如发短信核实用户操作了核身操作在2021-12-1 11:21:20发起了免登下发了登录态。
这个就是一次登录行为。业务洞察的核心也是围绕这个点进行。
假如我们的分析维度是总的登录维度或者分登录方式的登录维度分析这个两条数据的打点其实就不适合我们我们仅需要登录方式最终结果时间以及设备id就够了。 表2
或核身没有通过 表3
但是我们也会发现这个数据描述的行为并不完整比如表2并不能描述登录过程经过了核身这个特性。
这个时候我们就需要数据结构进行下一个阶段的演进。
我们引入了statustag来描述路径。
statustag格式0^0^12|0^1^abcde.
前后经过|分割为两种格式第一个格式为bitmap表示0版本第二个格式为字符串表示1版本格式字符串为经过的未加到bitmap的节点埋点毕竟不是强要求总有需求上线后没有加bitmap。
这个tag描述经过的路径为经过bx1100结果经过了一版本的4和8的节点和二版本的abcde节点。
有了这个tag就可以描述更多的信息。
3 业务场景数据的可视化表达
单纯的数据并不容易洞察也不是长期运营治理的合理方式。这个时候我们就需要可视化来搞事情。
可视化的内容包含我们想要表达的内容比如漏斗比如曲线。
目前可视化表达常见的是漏斗和报表。
漏斗举例图1
做漏斗很麻烦需要一个点一个点手动定义。但是漏斗对初期理解链路分析问题益处非常大。
这个时候我们需要的是可以通过结构化的数据源来快速生成可视化漏斗。
我们可以通过生成数据的时候就指定约定来快速生成结构化数据。
基于状态机约定打点
引入状态机变化记录打点日志结合结构化的画图能力定向输出约定日志动态画图
状态机的核心要素
1.statusTag记录路径信息 2.status和old_status记录节点上下游信息 3.depth记录节点深度
最终产出的一次登录行为登录数据”-最终可以产出如下的一次登录行为样例数据数据非真实用户数据 五 口径
口径是基于数据和业务场景的产出结果。口径也是最重要的点口径代表了我们基于数据和业务场景对业务结果的理解比如登录的口径在财年初定义登录成功率从9x%提升到9y%这个提升空间也是根据数据来计算的。
1 口径不要经常变动
口径一旦定义下来就不要经常变动。因为一般定义口径是最难也是最耗时的定义口径的时候一般我们已经完成了对目标的拆解机会的洞察和最终的测算。
2 口径并不一定是单一口径
除了上诉特性外口径也会有单口径和多口径一般都会同时存在比如登录过程在一个总的口径基础上哪怕是一次登录行为我们也会拆分多个业务阶段。
还是以登录举例我们把用户从进入页面开始到发起登录行为定义为意愿口径从登录行为开始到登录结果定义为成功率口径。这两块要解决的问题是不同的揉到一起会导致问题变得复杂不利于分析。
多口径也有一个好处我们可以做阶段性的工作在不同的阶段处理多口径中其中一部分的链路升级。
3 口径维度定义
口径维度定义需要结合场和业务的特性哪怕是同一个业务链路可能在不同场中不同人群定义也是不同的。
这块不好说明举个例子。
我们C端口径定义上是设备维度因为C端用户天然存在薅羊毛行为我们会认为一个设备的登录成功对于C端就是有益处的。
但是同样是登录链路B端定义上就是用户维度的因为B端商家的个体价值都很大而且不太存在类似C端薅羊毛的行为用户维度能让我们更好的看到用户行为以便做体验上的优化。
六 小结
在数据洞察方面我们也还在学习和实践的路上并在这条路上已经取到了一定的结果但是未来空间还是很大。这条路对于业务开发是一个有优势的路而且业务平台作为业务场景的丰富度上也是独具优势我们可以在数据洞察做的事情上更加自由。欢迎大家来一起讨论也欢迎大家来一起探索。
数据洞察是业务中台赋能业务的有力工具对业务产出数据洞察能力也是我们一个非常大的命题。
原文链接 本文为阿里云原创内容未经允许不得转载。
