字数: 2k

阅读: 5mis

收获: 一个数据人的习惯

写给，工作1-3年的数据分析师同学

痛定要思痛，抱怨是不解决问题的，只会引发自己和周围人更多抱怨。

经哥其实一直不太赞同很多所谓的痛点，因为有些是自己把自己铆钉在一个角色里面，然后，烦躁的接受铆钉的角色。

与其在烦躁中烦躁，还不如在烦躁中思考，很多事情是可以跳出来看，办法总比问题多，该强势的时候强势，该改变自己的时候要学会空杯心态，真的发现改变的应该是流程和制度的时候就尝试努力推方案，如果从多维角度证明当前制度是对企业整体是块儿朽木雕琢不动，那么该换赛道换赛道。

个人价值定位(对外)和个人目标(对内)至少自己要明确，如果你在别人分配的角色里做事情，那就被死死铆钉在哪里，你的精气神儿就很快消耗殆尽，很可能成为一个四处散播负能量的人。

数据分析师的痛点

• 需求交付时间紧；
• 频繁接到相似需求；
• 业务方频繁调整需求；
• 分析结果交付后，业务方又不用了；
• 成为业务方的取数工具人，为业务同学做嫁衣，工作价值不被认可；
• ……

上面几种情况，是我们普遍会面临的问题。根据以往经验，我通常建议从下面几个方面，改进我们的工作流程。

《道》: 和业务方建立信任关系，主动收集业务反馈

相信大部分分析师都经历过被业务方吐槽：缺少业务的ownership，对业务成败不关心、不负责。所以在合作过程中，双发缺乏沟通和信任，导致我们的参与高不强，沦为业务方的取数工具人。

要和业务建立信任，姿态很重要——我们需要主动摆出「我和你一起背业务指标，是战友」的姿态来和业务方合作。那么如何有效的做出这样的合作姿态呢？

1、主动关注指标变化情况

主动关注指标变化，及时发现数据异常。虽然“技术含量”不复杂，但是很好的体现我们ownership——会给业务方一种“有人在背靠背的帮我们看住这摊生意”的安全感，是一件ROI非常高的一件事。

2、做需求时，多想想有什么用，主动收集反馈

有时候产品想问A数据，也许关心的其实是B问题，比如产品同学让你看下某业务场景下年轻用户的内容偏好，其实他想看的是，该场景下核心受众用户的偏好。而他提出“年轻用户的偏好”需求，是因为他猜测“该场景的核心受众是年轻人”而已。

做分析报告的时候，一定要想着自己这个报告到底是在回答什么问题，回答之后对产品决策有啥用，做完之后要主动找产品聊聊看这个报告实际上有没有用——这样的意识和沟通会帮助你逐渐和产品建立默契，彼此更清楚对方的“脑回路”，逐渐的，你们思考问题的方式会趋于一致，信任感会很强。

《道》：从被动到主动、从描述到洞见，体现分析价值

很多数据分析师会抱怨，自己变成了SQL boy或是 SQL girl。我们要知道，“取数”并不是业务提需的目的。分析的价值更多体现在通过数据来洞察业务。所以，我们在日常工作中要有意识地训练从被动到主动、从描述到洞见的思维。

数据描述和业务洞见的区别在哪？

比如说，抖音产品同学讲直播插入到短视频信息流中，从数据上看直播增加了一个强势的入口。

数据上看到是，直播间的用户消费次数和时长增加很明显，但同时短视频的消费也有一点下降。

但是，一直到这里，这些“结论”仍然只是对数据结果的描述，业务方（销售）并不知道这意味着什么、他们又能做些什么。

比如，如何告诉业务方这种策略好，还是不好，它是否有增量价值，短期的还是长期的。

业务洞见是指可以通过这些数据映射到具体的业务场景。基于以上问题，会涉及出验证问题的ABTest，数据上评估的核心指标，以及实验结果数据的评估，最后要以一种统一货币化的单位来衡量两边价值的增量和损耗。

业务洞见能力，可以帮助数据分析师走通“提出问题、验证问题、得出结论、提升业务”这条路，而不是被动地等待业务方给我们提出各种取数需求。

而且，如果你的业务洞见能力被业务方发现并认可，他们会主动减少提取数据的需求，让你的时间花在产出更多的事情上。

《术》: 做好知识沉淀，提高取数效率

数据分析师完整的工作链路包括：提出业务问题→业务问题抽象为数据问题→提取数据→处理数据→分析数据→输出数据结论→业务落地或反馈。但是通常情况下，取数环节会占据我们30%、甚至60%的时间精力，我们可以从下面几个方面定期复盘沉淀，提高取数环节的效率。

1、整体通用 SQL 代码

SQL 的语法相对固定，而且我们工作中涉及的主要业务指标通常不会太多。这就意味着 SQL 脚本在很大程度上是可以复用的。我们可以通过整理 SQL 代码，减少重复敲代码的时间来提高效率。

比如 建表语句的框架是完全复用，没必要每次手动敲一遍：

2、常用指标的 SQL 代码

常用的表可能包括日活表、用户画像表、点击日志、曝光日志等。一些常用到的表，表结构是固定的，常用的限制条件一般也不太会有太大出入。可以提前整理好SQL框架，然后在具体的业务场景下，再做修改。例如用户画像表：

3、建立常用指标中间表

一般数仓清洗的表是分业务、分场景的，但是数据分析的过程中经常需要把不同业务或者场景关联分析。比如dau指标异常，通常需要从不同维度拆分，比如用户注册时长、注册渠道、版本、用户画像（性别、年龄、地域等）。但是，日活明细表、用户渠道表、用户画像表等通常分属在不同的底表里，经常需要关联分析。类似情况，我们可以自己建立日活用户大宽表，包含我们常用的维度，避免每次分析时都重复关联这些数据。

又比如电商 App，用户浏览商品、加入购物车、提交订单、支付成功等行为也分散在不同的底表里，每次漏斗分析需要用到 4 张表甚至更多，我们也可以自己建立一张浏览商品到最后支付成功的漏斗表。

最后，定期复盘，无往不利

最后，定期复盘最近一段时间的改变，个人的核心竞争力是否建立起来了或者壁垒增加、技术能力是否有所收获、与业务直接的信任是否有所加深、个人对业务的影响力是否在扩大等。具体执行层面，可以：

• 定期总结工作中常用到的分析方法和思路。
• 个人目标与业务目标是否 match，发力方向是否有偏离？
• 自己的分析报告对他们是否有说服力和影响力？
• ……