微信扫一扫
分享到朋友圈

用这个方法,就能做好面向老板的数据分析

作者:待字闺中 来源:待字闺中 公众号
分享到:

10-20

数据分析的痛点

越来越多的产品决策依据数据分析的结果,而数据分析的效率却真真是各个团队的痛。


一起来聊聊数据分析的一些想法。

不知道大家经历过这样的事情没有:老板或者运营部门突然要看看某个数据,可能是一个频率,也可以是一个转化率。但因为之前没有这个需求,现在看不了。然后紧急开发,一周以后才能够看到。可是,这时候老板是否还需要这个数据,已经不确定了。

01

BI工具之痒

这个小的案例,其实就是一个数据分析的案例。数据分析,或者叫做BI,是一个很宽泛的概念。这个问题在实际过程中比较难以解决,例如,有的表格需要做成固定的,需要定期的查看,所有就有了报表系统;有的分析就是一次性的,得到结论之后就不再使用了,所以这里需要一个强大的BI工具。这个BI的工具的主要任务是尽可能方便将统计的需求转变为报表。


这个BI工具我们在之前的文章里,有过探讨《》不过因为种种原因,目前这套工具还没有开源,给自己挖了一个大坑,这个工具大家可以先用metastore之类的工具代替一下。这篇文章想说说数据分析的另一个重要的点:数据。我开篇提到的小例子,其本质是没有数据造成的——巧妇难为无米之炊。数据这块相比较BI工具这块,更有挑战:


  • 数据的准备往往是滞后的

  • 业务数据库表结构的设计,往往很难支持统计的分析


下面详细说说这两个难点怎么解决,说说我们在实践中采取的方案。


02

一个方案,要解决一大类问题

数据准备的滞后性一直存在,尤其是业务数据中没有,需要网站上埋点的数据。这种滞后性,一定程度是产品迭代,公司发展的敌人。这个问题,更重要的是埋点数据的解决,我们解决埋点数据的方法也经历了几波的迭代,从开始的逐个埋点写代码,准确性可以保证,但基本没有通用性。所有的需求,都要特定的埋点。随着需求的增多,我们渐渐抽象出来一套模式,这套模式是基于需求层面的抽象。如下:

曝光 --> 点击 --> 业务动作1 --> 业务动作2

这个抽象非常的有用,基本上我们要看的就是如下的需求:


  • 曝光的数量

  • 点击的数量

  • 业务动作1的数量

  • 业务动作2的数量

  • 点击率

  • 点击到业务动作1的转化率

  • ...


所以,我们有了一个方法,来解决这大类的分析需求。方案如下:

  • 将页面划分为不同的功能模块,这个划分不要在前端做hard code,更好的做法是在Gateway层(我我们假设大家都采用了微服务的架构,其他的业务架构类似,只是叫法不同),通过接口划分。例如前端要展示商品(我们假设是电商的网站)的详情,或者列表。无论在哪个子页面,在Gateway层,都是不同的接口。在详情、或者列表返回的时候,都额外添加字段:module。不同的module可以根据不同的功能赋予可读的名字。为了方便作分析,我们要区分每一次请求展示(在用户层面,实际是用户行为的一次会话),我们又新增字段:groupUuid,用来标识后续的一些行为,实在这一次详情、或者列表展示的基础上完成的。

  • 基于上面的设计,前端的工作就可以通用化。例如我们使用Vue作为前端的框架,在进行前端渲染的时候,我们直接将module、groupUuid渲染到dom元素,同时将商品dataId也渲染到dom元素,这个dataId和groupUuid在整个分析pipeline中起到了链接枢纽的作用。

  • 用户在浏览页面的时候,前端统一监控,只要出现在可见区域的商品,则发送埋点事件,参数为前面dom元素已经渲染过的参数。

  • 点击事件(这个时间要单独写)也要带上dom上渲染的参数:groupUuid,module和dataId。

  • 点击之后,展开详情页或者预览也,都属于详情页。这时候需要将groupUuid,module和dataId三个参数作为URL参数带到详情的页面,此时,在这页面做的任何业务动作,都把groupUuid,module和dataId作为上下文传入到业务后台,这就保证了业务后台和数据埋点的统一关联。

  • 基本上,在这个详情页做一些跳出的操作。都认为会话结束。


看起来也不简单,也没有解决全部的问题。但这个可以解决我们上面抽象出来的模式的问题。这里有一个经验,埋点方案,不要希望某一个方案能解决一切的问题,而是某一个方法,解决某个大类的问题,然后再来一个方法。


上面是常见的一类需求,还有一类是页面上各个控件的点击的频率以及对比,这个设计师们比较需要,用来改进产品的交互体验。这里也有一个和上面类似的思路,把每个控件进行编号(编号由设计师输出),然后前端统一处理。


03

分离统计表和业务表

这个问题我想大家都是认同的,但问题在于,分离的时机是什么?项目伊始就是做么?不然。因为这个时候统计的需求是频繁变化的、模式上是不稳定的。基本上这个阶段,分析仍旧是基于业务数据库的。接下来,业务逐渐画圆,最小闭环逐渐运行稳健。此时,另外一个特征是统计表的结构已经逐渐清晰。就可以开始着手ETL的开发。


以上提到的工具,纯开源的还没有遇到特别好的。基本都要根据自己团队的需求,定制开发。


04

彻底解决数据分析问题的方法

数据分析不是天马行空的想象,是基于对业务的深入了解。首先,明确我们要解决什么问题是最重要的,其次,这个问题该如何验证,怎么保证我们的方法就是可以得到结论,并且作为决策依据的。这一切,我觉得都是建立在对业务全局、系统、有序的理解上。之前有一篇文章做了讨论《》。


业务应用架构比较繁琐,但也不乏有趣值得深入的点。欢迎大家一起讨论。


阅读1247
举报0
关注待字闺中微信号:gh_81abae3e5d59

用微信扫描二维码即可关注
声明

1、头条易读遵循行业规范,任何转载的稿件都会明确标注作者和来源;
2、本文内容来自“待字闺中”微信公众号,文章版权归待字闺中公众号所有。

评论
更多

文章来自于公众号:

邮箱qunxueyuan#163.com(将#换成@)
微信编辑器
免责声明
www.weixinyidu.com免责声明    商务合作1758059460
版权声明:本站收录微信公众号和微信文章内容全部来自于网络,仅供个人学习、研究或者欣赏使用。版权归原作者所有。禁止一切商业用途。其中内容并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。如果您发现头条易读网站上有侵犯您的知识产权的内容,请与我们联系,我们会及时修改或删除。
本站声明:本站与腾讯微信、微信公众平台无任何关联,非腾讯微信官方网站。
粤ICP备16075700号-1