当前位置: 首页 > 科技观察

说说我们在业务链接升级中做的数据洞察

时间:2023-03-20 20:48:42 科技观察

1概述数据相关的名词有很多。虽然有不同的定义,但它们在本质上是互补的,通常一起使用才能得到结果。数据分析、数据挖掘、数据洞察等类比术语。以下是wiki上的定义Dataanalysis:是一种常用的统计方法,主要特点是多维和描述性。一些几何方法有助于揭示不同数据之间的关系,绘制统计信息图更简洁地说明这些数据所包含的主要信息;数据挖掘:是计算机科学的一个跨学科分支。它是使用人工智能、机器学习、统计和数据库的交叉方法在相对大的数据集中发现模式的计算过程;数据洞察:该项目目前没有wiki入口,基于常识,基于数据分析和数据挖掘,结合业务场景,围绕业务环节定义统一的口径,从而更好的分析问题,进一步改进策略。三种分析方法本质上都是对数据进行处理以获取信息,但目的不同。以下是我个人的理解。数据分析更侧重,基于人对流程的理解,结合人对业务和数据的理解,产生分析结果。这里更强调人的分析;数据挖掘和数据分析一样,只是角色从人变成了机器;数据洞察是在数据分析和挖掘的基础上,引入业务场景的概念,梳理出影响业务场景结果的因素和环节,目标是更好更快地对抽象问题进行归因、拆分,形成改进方向。这也是我们商科发展的学生最有优势的地方。两大核心要素我们发现对数据洞察力的理解其实可以分为几个核心要素。在这里,我们简要解释每一个。1数据干净有效的数据才是我们想要的数据,否则会误导后续的结论。例如因为登录环节是保证业务安全水位的第一环节,所以经常会有传入流量。如何避免灰黑流量影响后续判断也是重中之重;2业务场景业务场景有差异化数据洞察与其他数据分析方法的核心区别,也可能是商科学生区分BI分析的最大价值点。任何分析策略都离不开对业务场景的理解,而不是单纯的对数据的理解。定义“一个完整的业务链接行为”是核心,只有围绕一个行为链接,才能分析出对该链接有用的策略。3口径什么是口径?我理解calibre是基于合理的数据维度和良好的目标对业务场景的理解。口径也会结合对业务场景的理解和对业务目标的理解。数据维度可能有很多种。还是以登录为例。正常理解一个用户在一台设备上登录是正常的,但是在手机淘宝上会出现多个账号登录同一台设备的情况。这也是一个正常的数据特征。然后在定义登录成功率的时候,是使用deviceDimension(认为只要是同一个设备的一个用户登录成功,就说明该设备成功)还是使用userdimension(只看用户维度数据,不结合device)定义指标),也需要加以考虑。三数据建设1、数据清洗是保证数据有效的手段。我们所获得的各种管理框架和不同的数据来源可能具有不一致的维度和信息量。例如,某些数据源有设备信息但没有用户信息。部分数据源有用户信息,但设备信息不完整;即使是同一个时间字段,格式也不统一。这时需要先对数据进行处理,去除脏数据,补充缺失点,处理干净的单维信息,保证各个数据源数据处理的数据维度和格式统一,比如标准设备id或用户id和时间等。2数据构建是数据质量问题的补充和演进,不仅从数据的清晰度,而且从数据生成的角度。如果数据缺失或者不一致,数据清洗不确定,需要开发,比如在数据库中添加字段,在dot框架中添加逻辑。数据建设是一个长期的过程,不仅要补充现在要分析的内容,还要形成一套标准的可交付成果。此外,在日常处理需求和项目时,还必须考虑数据管理的质量。毕竟线上提需求不是结果,拿到业务目标才是结果。四大业务场景1业务场景的定义业务场景是整个业务洞察中最特殊的环节。该环节定义的好坏直接影响问题拆分结果的有效性。不同的业务场景有其特殊性,需要结合业务特点进行分析。根据我目前的经验,业务场景的定义也有一些核心方法。在业务场景中,最终产品是谁?让我们以登录为例。登录的最终目的一定是传递登录状态。不然谁也不会回来“玩转”登录了。其他业务也是如此,例如围绕库存运行的订单;在业务场景中,你需要分析的维度有多深;这样也比较好理解,继续上面的例子,去看看登录业务链接,是否需要拆分多个不同登录方式的链接?还是只看一个通用的登录链接就足够了?这个维度只能看分析问题的层次。一般在洞察初期,维度当然是越详细越好。比较完整,但是分析上没有问题,就是“过度分析”。在业务场景中,需要定义“一个完整的业务行为”。数据洞察不同于其他分析方法。最大的好处就是结合业务来分析业务本身。直接影响业务结果的一定是完整的业务环节。这一点不举例子不好解释。例如,登录过程。你有没有想过管理会是什么样子,和完整的企业运作有什么区别?正常的点看起来像这样。rpcIdloginType结果时间deviceIdtraceid1passwordNEED_IV_CHECK2021-12-111:20:54123traceid2mloginTokenSU??CCESS2021-12-111:21:20123rpc请求维度的表达式。2结合业务场景定义的数据结构演进,虚线数据描述的是阶段性结果。上述例子描述了用户在2021-12-111:20:54发起账号密码登录请求,但是由于环境不安全,安全挑战需要身份验证(比如发送短信),用户进行身份验证操作,于2021-12-111:21:20,发起免费登录并下发登录状态。这是登录行为。商业洞察力的核心也围绕着这一点展开。如果我们的分析维度是总登录维度或者登录方式登录维度分析,这两个数据的管理其实并不适合我们。我们只需要登录方式、最终结果、时间和设备id。rpcIdloginTypefinal_resulttimedeviceIdtraceid1passwordSUCCESS2021-12-111:21:20123表2或者核心体没有通过rpcIdloginTypefinal_resulttimedeviceIdtraceid1passwordNEED_IV_CHECK2021-12-111:21:20但是我们的123表3会发现这个数据所描述的行为并不完整。例如,表2无法描述登录过程已通过内核的特征。这时候就需要数据结构进化到下一阶段了。我们引入statustag来描述路径。状态标签格式:0^0^12|0^1^abcde。before和after|分为两种格式,第一种格式是位图,表示版本0;第二种格式是string,表示版本1格式,string是没有加bitmap的passed节点(买点毕竟不是强求,总有需要上线的,没加bitmap).这个标签描述了通过bx1100结果的路径,通过第一个版本的4和8节点,以及第二个版本的abcde节点。有了这个标签,可以描述更多的信息。3业务场景数据的可视化表达简单的数据不易理解,也不是长期运营和治理的合理方式。这时候就需要可视化来做事了。可视化的内容包括我们要表达的东西,比如漏斗,比如曲线。目前,最常见的视觉表达是漏斗和报告。漏斗示例图1制作漏斗非常麻烦,需要手动逐点定义。但是漏斗对于初步理解链接和分析问题是非常有帮助的。这个时候我们需要的是通过结构化的数据源快速生成一个可视化的漏斗。我们可以通过在生成数据时指定约定来快速生成结构化数据。基于状态机+协议管理1.引入状态机变化记录来管理日志;二、结合结构化绘图能力,定向输出协议日志,动态绘图状态机的核心要素1、statusTag记录路径信息;2.status和old_status记录Node上下游信息;3、depth记录节点的深度;一次性登录行为登录数据五口径的最终输出是基于数据和业务场景的输出结果。口径也是最重要的一点。口径代表了我们基于数据和业务场景对业务结果的理解。比如在会计年初就定义了登录口径,登录成功率从9x%提升到9y%。这个提升空间也是根据数据来计算的。1、不要频繁更换口径。一旦定义了口径,就不要经常更改它。因为通常定义口径是最困难和最耗时的。在定义口径的时候,我们大致完成了对目标的拆解、对机会的洞察、最后的计算。2口径不一定是单一口径除了以上特点外,口径还有单口径和多口径之分,一般同时存在,比如登录流程。分为多个业务阶段。仍然以登录为例,我们将用户从进入页面到发起登录行为定义为意愿口径,将用户从登录行为到登录结果定义为成功率口径。这两部分要解决的问题是不同的,如果放在一起,问题会变得复杂,不利于分析。多口径还有一个优势,我们可以做阶段性的工作,分阶段处理部分多口径的链路升级。3口径维度定义口径维度的定义需要结合领域和业务的特点。即使是同一个业务环节,在不同的领域、不同的人群中也可能有不同的定义。这块不好解释,举个例子。按照我们C口直径的定义,就是器件尺寸。因为C端用户天生就有羊毛行为,我们会认为一个设备登录成功对C端是有利的。但它也是一个登录链接。在B端的定义中,是用户维度,因为B端商户的个体价值非常大,没有太多类似C端的行为。用户维度使我们能够更好地了解用户行为以优化体验。六小结在数据洞察方面,我们还在学习和实践的道路上,并且在这条路上取得了一定的成绩,但是未来还有很大的空间。这条路是业务发展的优势之路,而业务平台在业务场景的丰富性方面也有着得天独厚的优势。我们可以更自由地利用数据洞察力做事。欢迎大家一起探讨,欢迎大家一起探讨。数据洞察是业务平台赋能业务的利器,能够对业务产生数据洞察,对我们来说也是一个非常大的命题。业务运行快,业务平台靠谱。弹性计算基础知识弹性计算就是把计算能力变成普惠性的公共资源,让不同规模的用户随时以实惠的价格享受到高可用、高性能、高效率的基础IT计算服务,所以你可以说,弹性是云计算的核心能力。本课程重点介绍了弹性的重要性、弹性的定义、阿里云如何做弹性等内容,点击阅读原文查看详情。