「07」月薪20000与月薪5000的数据分析师，到底差在哪里？

前面的一系列文章，笔者顺着数据全链路的方向，介绍了从埋点到数仓建设到指标相关的基础知识，还有常用的波动分析 和 AB-Test等工作内容

但是，这些工作内容，每个数据分析师都会接触吗？答案是否定的

那么，今天，我们就来聊聊，数据分析师的具体工作和核心价值吧

借鉴范畴论的思想，我们把业务和数据分析师抽象为 实体+关系 的度量，那么

实体：数据分析师是谁

关系：数据分析师与业务的关系

数据分析师是谁

相信很多公司或者部门，都把数据分析师挂在技术团队下，把数据分析师当成一个技术人员。

这没问题，因为数据分析要掌握很多的知识点，职责也比较宽泛。

比如埋点规范设计，数仓整体建设，指标体系搭建，指标波动分析，AB-Test检验，运营活动分析，产品功能分析，算法效果分析等等。

这里面的工作内容，有些需要技术上的积累，有些则需要数学相关的专业知识。

但是不能忘记，这些技术也好，知识也罢，我们还是要有一个比较明确的定位

我们不能把自己当成一个纯“技术人员”，我们最核心的价值，还是在于解决业务问题，指导业务发展的能力

就像数据分析这四个字一样，数据是基石，分析才是核心

理解业务，高于业务，反哺业务，这才是数据分析师

数据分析师与业务的关系

每个公司，以及每个不同岗位的数据分析师，可能都在做不同的活儿

较小的公司或者较前期的公司，凡是数据相关的事情，应该都在数据分析师们手里

指标建设，波动分析，产品功能分析，用户分析，商业分析 ... ...

这种能接触到数据闭环的情况，非常有利于每个分析师的成长

因为这种情况下，你会接触到不同种类的数据，见识到不同的分析方法，了解到不同的行业玩儿法，这些，都是后续沉淀自己的方法论的基础

但是切忌，一定要不断沉淀梳理总结，否则，只会陷入业务中，越做越乱

当公司规模较大了，数据分析师可能就有两个不同的部门：业务部门+中台部门

中台比较偏数据全链路的体系化建设，比如：设计埋点规范，建立元数据体系，建设数据仓库，监控业务的报表等等

也就是说，中台的数据分析师们，基本都是不断推进整体业务在数据上的体系化建设，并在业务大方向上给出一定的建议和监控

相比中台部门，业务部门的数据分析师，则更偏重某个具体业务，比如：某个产品的功能，某个内容的质量，某个策略的效果等等

由于是业务一线部门，更贴近业务的的实际发展，相比中台分析师，业务部门的分析师对于业务了解得更深入，所以更多的是去解决当前业务中的问题，推动业务的优化，跟进后续的迭代和落地

当然，实际情况还是和公司强相关，不一定都是如此。

这种不确定性，其实和数据分析师的工作内容一样：我们都想要干着分析的活儿，推动业务的发展，但是很多时候，我们却成为了 跑数工程师。

当然，跑数工程师并不可怕，可怕的是，一直是跑数工程师。

在入门的时候，大家应该都做过sql boy，因为这会儿对业务还不熟悉，能力沉淀不够，项目经验不多。所以，在初级阶段，我们都做过sql boy，表哥表姐，这是比较正常的，因为这个阶段，我们还不了解业务，只能为了解业务的同学提供数据上的帮助

当有了一定的能力沉淀，和业务积累，我们逐渐接触到具体业务的分析，对一些波动归因，问题描述统计，产品功能迭代，提出自己的思考和见解，给出一些结论和建议，并推动后续迭代的落地，助力业务发展

再往上，我们需要梳理总结出自己的分析方法论，针对不同的业务领域，去深耕沉淀，理解业务，理解行业，成为某个行业或者领域的专业人士，从更高更宏观的角度来反哺业务，为决策业务发展方向提供指导

这三个阶段，也是笔者理解的数据分析师的层次划分

业务就像一艘船，我们逐渐从打扫卫生的船员，变成了划桨的船员，再升级成大副，最后当上船长。但是无论是哪种船员，无论是哪种阶段，我们都在这艘船上，以自己的能力，保证在正确航向上，船航行得更好

这也就是数据分析师与业务的关系

数据分析师就是在理解业务后，以高于业务的角度，发现问题，找到方向，助力业务更好的发展和增长的这样一群人

无论python再厉害，算法再NB，最终都不能脱离业务。毕竟技术是一个过程和方法，我们的目的还是要解决具体的业务问题

总结下，数据分析师需要做的事情：用数学逻辑串联业务，讲一个情景优化的故事

大道至简的去告诉业务，现在业务的状态如何，有什么问题，这个问题该如何解决，未来该如何做，做了之后预计有什么效果

以上，就是本期内容，有任何问题欢迎后台留言～