前面的一系列文章,笔者顺着数据全链路的方向,介绍了从埋点到数仓建设到指标相关的基础知识,还有常用的波动分析 和 AB-Test等工作内容
但是,这些工作内容,每个数据分析师都会接触吗?答案是否定的
那么,今天,我们就来聊聊,数据分析师的具体工作和核心价值吧
借鉴范畴论的思想,我们把业务和数据分析师抽象为 实体+关系 的度量,那么
实体:数据分析师是谁
关系:数据分析师与业务的关系
相信很多公司或者部门,都把数据分析师挂在技术团队下,把数据分析师当成一个技术人员。
这没问题,因为数据分析要掌握很多的知识点,职责也比较宽泛。
比如埋点规范设计,数仓整体建设,指标体系搭建,指标波动分析,AB-Test检验,运营活动分析,产品功能分析,算法效果分析等等。
这里面的工作内容,有些需要技术上的积累,有些则需要数学相关的专业知识。
但是不能忘记,这些技术也好,知识也罢,我们还是要有一个比较明确的定位
我们不能把自己当成一个纯“技术人员”,我们最核心的价值,还是在于解决业务问题,指导业务发展的能力
就像数据分析这四个字一样,数据是基石,分析才是核心
理解业务,高于业务,反哺业务,这才是数据分析师
每个公司,以及每个不同岗位的数据分析师,可能都在做不同的活儿
较小的公司或者较前期的公司,凡是数据相关的事情,应该都在数据分析师们手里
指标建设,波动分析,产品功能分析,用户分析,商业分析 ... ...
这种能接触到数据闭环的情况,非常有利于每个分析师的成长
因为这种情况下,你会接触到不同种类的数据,见识到不同的分析方法,了解到不同的行业玩儿法,这些,都是后续沉淀自己的方法论的基础
但是切忌,一定要不断沉淀梳理总结,否则,只会陷入业务中,越做越乱
当公司规模较大了,数据分析师可能就有两个不同的部门:业务部门+中台部门
中台比较偏数据全链路的体系化建设,比如:设计埋点规范,建立元数据体系,建设数据仓库,监控业务的报表等等
也就是说,中台的数据分析师们,基本都是不断推进整体业务在数据上的体系化建设,并在业务大方向上给出一定的建议和监控
相比中台部门,业务部门的数据分析师,则更偏重某个具体业务,比如:某个产品的功能,某个内容的质量,某个策略的效果等等
由于是业务一线部门,更贴近业务的的实际发展,相比中台分析师,业务部门的分析师对于业务了解得更深入,所以更多的是去解决当前业务中的问题,推动业务的优化,跟进后续的迭代和落地
当然,实际情况还是和公司强相关,不一定都是如此。
这种不确定性,其实和数据分析师的工作内容一样:我们都想要干着分析的活儿,推动业务的发展,但是很多时候,我们却成为了 跑数工程师。
当然,跑数工程师并不可怕,可怕的是,一直是跑数工程师。
在入门的时候,大家应该都做过sql boy,因为这会儿对业务还不熟悉,能力沉淀不够,项目经验不多。所以,在初级阶段,我们都做过sql boy,表哥表姐,这是比较正常的,因为这个阶段,我们还不了解业务,只能为了解业务的同学提供数据上的帮助
当有了一定的能力沉淀,和业务积累,我们逐渐接触到具体业务的分析,对一些波动归因,问题描述统计,产品功能迭代,提出自己的思考和见解,给出一些结论和建议,并推动后续迭代的落地,助力业务发展
再往上,我们需要梳理总结出自己的分析方法论,针对不同的业务领域,去深耕沉淀,理解业务,理解行业,成为某个行业或者领域的专业人士,从更高更宏观的角度来反哺业务,为决策业务发展方向提供指导
这三个阶段,也是笔者理解的数据分析师的层次划分
业务就像一艘船,我们逐渐从打扫卫生的船员,变成了划桨的船员,再升级成大副,最后当上船长。但是无论是哪种船员,无论是哪种阶段,我们都在这艘船上,以自己的能力,保证在正确航向上,船航行得更好
这也就是数据分析师与业务的关系
数据分析师就是在理解业务后,以高于业务的角度,发现问题,找到方向,助力业务更好的发展和增长的这样一群人
无论python再厉害,算法再NB,最终都不能脱离业务。毕竟技术是一个过程和方法,我们的目的还是要解决具体的业务问题
总结下,数据分析师需要做的事情:用数学逻辑串联业务,讲一个情景优化的故事
大道至简的去告诉业务,现在业务的状态如何,有什么问题,这个问题该如何解决,未来该如何做,做了之后预计有什么效果
以上,就是本期内容,有任何问题欢迎后台留言~