大家好，我是你们的可乐

很多同学都很好奇数据分析师的一天是如何度过的，通常做什么任务，需要满足什么需求。

让我们一起满足这个好奇心。

看看数据分析师的日常生活！

文本

早上十点多，到了办公室，匆匆吃早饭，早餐就是路边买的豆浆和油条，再加上一个肉包子，没错，就是那种爆汁的。

然后我打开电脑，第一件事就是查看昨晚下班后未查看的消息。

果然，对应的产品经理小钟又给我发来消息，说因为某个产品功能上线了，需要查数据，需要我设计一些指标来评估这个功能的好坏，并把这些指标做成报表来监控这个功能的走势。

接到这个需求之后，我看了一下这个功能的设计。然后根据自己对业务的理解，粗略的规划了一些可能需要看的指标，并把这些指标整理成了思维导图。每个指标我都写下了为什么这样设计，主要是为了评估用户在什么方向寻找内容。

我自己思考了一下之后，为了能够让自己的想法跟产品经理的想法一致，我找到了小钟。

一个闲适的午后，我泡了一杯中年人必备的枸杞水，和她谈了谈心。我主要想知道小钟对于这个功能主要关注的是什么，然后需要看哪些指标和维度。常见的维度有设备、城市、版本、新老用户、年龄、性别等。谈心之后，我终于知道了小钟想要什么数据指标，然后我大致告诉她什么时候可以完成。

互联网的生存法则就是，进度对齐很重要，不然后面就会被无情的催促和叫喊。

对齐进度之后，就需要做报告了。怎么做报告呢？当然是从数据追踪开始，也就是数据上报。

做数据上报需要找开发人员，一般来说数据上报分为客户端数据上报和后端数据上报，开发人员的diss比较出名，所以要和他们搞好关系。

为了提高沟通效率，我把需要上报的数据都记在了腾讯的文档里，全部按照上报规范来上报，然后把这份文档发给了关系不错的开发人员小黄。

开发人员说：“你上次不是提过这个需求吗？怎么这么快又提了？”我解释了我的无奈，说这是小钟的要求，我也没办法。开发人员看完文档后，就来找我，我们又聊了起来，抱怨产品经理只会提需求。

同时，我们也检查了文件的一些细节，包括每个跟踪点需要上报的信息、位置，以及上报时间、上报参数等，发现了上报可能存在的问题。

聊完这些，终于到了吃午饭的时间。午饭是免费的，品种也很多，有北方的面条，有西方的餐食，有各种蔬菜的粥，还有水果。于是我赶紧加快脚步，去食堂提前排队。不然，要是碰到那些好吃的柜台，就得排一个小时的队，才能吃上十分钟。

我最喜欢泰式鸡蛋豆腐和萝卜虾炒鸡蛋。

豆腐软糯，微甜，入口即化，配上白米饭，简直美味极了。

萝卜干虾仁炒鸡蛋，萝卜干的甜味搭配虾仁的鲜美，鸡蛋的香味在鼻尖飘来，世间何时能找到如此美味，唯有现在才是最美味

吃饭的时候，看小说是必不可少的，有时候听同事聊钱、房子、女孩子，中午大概是最开心的时候了。

吃完午饭，慢慢散步回家。谁说男生不需要管理身材？散步不仅有助于消化，还能防止中年过早出现油腻肚子。

太可悲了。你浑身都胖。首先你的肚子会胖。你很快就会失去你的腰带。

散步结束后，我开始感到困倦，幸好人性化的公司允许12点到2点休息，吃完饭散步后，才1点，还有一个小时的休息时间。

我买了午睡椅，趴在桌子上睡觉太累了，脊椎也受不了，只有午睡椅才能让我睡得好。我越来越觉得，很多道理我们都懂，但是很多人做不好，比如午睡。如果说有什么好习惯需要坚持，那就是午睡。

午睡时间不长，一般只睡半个小时，剩下的半个小时可以刷手机，看看今天有哪位明星生孩子，午休时间就当个看客，哈哈

我从学生时代就发现，如果我不睡午觉，我就会花一下午的时间去钓鱼。

现在工作之余，我越来越感受到午睡的神奇，午睡过后，精神焕发，数据分析思路也整合起来，数据分析问题迎刃而解。

下午是一天中主要的工作时间，起床后大致规划了一下下午要做的事情，工作之后才发现规划的重要性，不然下午可能就什么都没做了就过去了。

有人说，很多人也看到他整天努力工作，却发现最后重要的事情并没有完成。

有些人说一天中要做太多的事情，以至于没有时间做自己的事情。

有人说每个需求方都在催我，我不知道应该先满足谁的需求，我经常被业务方催。

其中大部分是由于缺乏规划造成的。

因此下午的重点是：和产品人小莫聊最新的产品规划，对某一个数据指标的下滑做专题分析

聊天八卦很容易，谈规划却不容易，找数据支撑行进的方向更是难上加难。

为什么我们需要谈论这些产品？

你会发现，数据分析在企业的价值很多时候是被动的数据收集，是基于产品需求的，数据收集到之后，你能做的最多就是帮忙分析一下。

其实对产品的商业端来说，你是有价值，但是价值非常有限，最多只是一个提供良好支持的人。

这就是你想要的数据分析吗？

不，当我们每个人想从事这个行业的时候，除了希望工作前景好、收入高之外，还希望自己的角色能在企业中发挥重要作用。

然而，如果你只提供被动支持，包括报告、统计和分析

数据分析的真正价值难以把握

你距离成为高水平的数据分析专家还很远，而且这个距离很难靠经验弥补

我和产品小伙平时就是在下面这个环境见面聊天讨论方向，下面的环境很舒服很好，不容易吵架。

站在这里往下看，微信总部的每一栋建筑都可以看到，再往下走，还能看到校园里很多微信吉祥物。

周末经常有人来这里打卡，练习各种拍照构图技巧，情侣约会的好去处哈哈哈哈

门口有花草，平时可以靠在门口的椅子上，看看眼前的花草，看看天空，释放一下经常被撕裂的压力，这大概就是互联网人最需要的吧。

所以，我常常和朋友开玩笑说，每天上班就像去公园一样。

我们主要讨论：比如下一步产品优化的目标是什么，是增加用户量还是提升用户体验

比如，增加哪些新的特性，完善哪些旧特性，完善的决策方向是什么，数据分析能不能提供什么帮助。

目前的产品功能发现了哪些问题和痛点？这些痛点能否通过数据进行量化和分析？这或许就是数据分析的价值所在。

很多时候人们说某种体验不好，大多都是从情绪化的角度去思考和操作，我们数据分析师最重要的能力就是把这种情绪化的东西抽象成可以用数据量化的东西。

量化是数据分析的本质，也是价值的体现

洞察是数据分析的灵魂，也是量化的提升

那么，该如何量化呢？

量化来自于产品并归于产品。

比如如何更方便的发送微信表情？

当微信成为社交帝国的王者时，在满足用户需求方面的问题也暴露出来。

即使是伟大的产品经理，也不可能了解用户所有的痛点，并将其转化为产品需求，从而迭代新的产品模块，不断为用户创造价值。

因此数据分析师需要通过数据发现用户背后的痛点，并量化这些痛点，并提供优化迭代的建议。

随着今日头条的崛起，抖音的数据驱动模式也大行其道

当越来越多的人对头条的产品优化和推荐效果感到惊讶时

当拼多多电商受到巨大冲击时，淘宝却陷入危机

当拼多多背后的数据决定了各种玩法的迭代

数据科学诞生了，那么数据科学的本质是什么？

我认为无法逃避量化和预测

以我们的小表情优化为例（以下数据均为脱敏数据，并非真实数据）：

量化使用效率：

近15%的人在发送表情符号时需要滑动4次以上，效率不高。

迭代提议量化：

从使用习惯来看，90%的人一周只发9个或更少的表情，能不能把常用的9个表情固定下来，让用户自己选择呢？

通过上面的量化，我们可以帮助产品清晰的发现，目前小表情的使用难度，同时我们用数字来量化它的难度有多大，给我们一个直观的感受。

有多难？你每发一个表情，15%的人都要刷4次，人们等你的表情，等到花都枯萎了。

如何优化？我们发现大部分用户发送的表情符号少于9个，因此使用常用表情符号就可以满足需求。

因此，以下迭代应运而生

这样的迭代改变是否合理？

从用户、需求、场景、价值角度

用户有发送小表情的需求，常见的使用场景是聊天，期望需求是能更快的找到想要的表情，对用户的价值是能更好更快的沟通，提高沟通的效率和乐趣。

所以，在聊天场景下，我们的迭代能够满足用户快速查找和发送表情的需求，给用户带来的价值就是更好地满足了他们沟通和表达的需求。

在听了这个小表情的优化案例之后，产品小伙也感受到了数据确实能发现很多他们在产品迭代改版中无法发现的问题。

同时他也跟我讲了一些其他现有的产品问题，比如老板比较关注的一些问题，看看数据能不能帮助驱动分析、辅助决策、发挥洞察力、落实归因。

我听得越多，越发现在庞大的规模背后，产品经理确实有更深刻的思考，因为你做的每一个改变，都影响着数十亿的用户。

慢慢尝试，寻求创新，才是微信表情包现在需要思考的。

跟产品人莫哥聊天之后发现，产品经理的思维维度跟我们有很大的不同。

我觉得很多数据分析师觉得产品经理没有数据，经常跟他们讲用数据来驱动业务增长、用户增长，但是产品经理不太懂。

我为此很苦恼。

为什么？他们就不能更理解我一点吗？

这其实是数据和产品之间长期存在的矛盾。

为什么？

这是因为产品经理是站在产品的角度去思考的，我听得最多的一句话就是产品经理跟我说别的公司也是这么做的，我觉得很有道理，所以我也去试试。

产品日常的工作就是体验产品、提出想法、设计产品、产品诞生。

然而数据分析师的日常工作就是提取数据、分析数据、再分析、分析建模、再建模、做分析报告、报告、再报告。

一个整天跟产品打交道，一个整天跟数据打交道

毫无疑问，他们的观点存在差异。

有人说，产品经理的伟大之处在于能站在产品的角度，科学的完成一个产品的设计。

有人说，产品经理的专业性就在于不依赖数据，能够精准的揣摩用户的想法和行为。

然而面对如此大规模的产品，即便是最强大的产品也难免会出现意外损坏的情况。

《互联网思维》提到，用户至上。

产品经理本身也是一个用户，当你有十万、一千、一千万个用户的时候，你也许能够通过自身超强的敏感度感知到用户的需求，并完美迭代产品的设计。

但是，微信这样的产品，已经不再是之前的微信了。

从别人的角度思考也很重要。

为了更理解产品经理的思维，我曾经想过把自己归零，在公园，在岗位，在食堂，在路上，我都是产品经理。

我会尝试从产品经理的角度思考

比如下楼的时候，我会思考为什么这个楼梯要这样设计，为什么灯光要这样设计，它的优点和缺点是什么，它的痛点是什么

当我来到食堂的时候，我就在想排队取餐是不是一个巨大的痛点，如何优化点餐流程。

同时我也看了很多关于产品方向的书籍

我发誓，我追求一个女孩从来没有这么认真过。

这里介绍一下我的微信读书架

说实话，这类书我只看过两本，一本是苏杰的《人人都是产品经理》，主要讲了产品创立的整个流程，以及在这个过程中产品经理应该做什么。

我看完之后只有一个感受：每个人都有自己的问题。

还有一本书是《让你的产品、理念、行为像病毒一样具有感染力》，主要讲了让你的产品具有感染力的六大原则，值得一看。

其实我们经常会发现，一些小程序、一些玩法，在微信朋友圈等自媒体渠道上能够火起来。

它是什么，它的特点是什么，为什么这么受欢迎，读完这本书，你会发现沟通的本质

引爆沟通，六大原则解疑答惑

用户增长，支撑战略的六大原则

下午四点，老板通知我们在群里讨论一下最近写的OKR，每次都要按照老板的要求调整，没办法，因为我们的OKR半年就调整一次。

什么是 OKR？

O：下半年的目标是什么？

KR：主要结果是什么？

OKR很好的帮助我们理清了我们要做什么，用什么方法、什么事情去达到什么基本的结果。

OKR 比较人性化，因为是半年做一次，我遇到过三个月做一次 KPI 的公司，说实话三个月做不成什么，很多事情可能都做不成。

但半年之内，基本可以保证你的项目能有一个基本的结果。

您必须认为每个请求都是合理的。

老板是湖南人，普通话流利，说话速度快，但表达准确，反应迅速，汇报时总能抓住要点。

老板大概是数据分析师里面最帅的一个，他也是帅哥里面最厉害的数据分析师。

我没有仔细核实，但我听同事说

毕竟大家都说鹿晗很帅，我现在已经不相信大众的看法了。

他不喜欢你说的太多，也不喜欢你周报写得太多，所以每次写东西的时候，我们既不能写太多，又要把重点说出来。

这对于报道能力来说是一个极大的考验。

我发现我上班的时候，老板大部分的时间都是在看手机，回复信息，看电脑回复信息。

当然，我不知道答复是有关业务的还是有关个人的事情。

当你的老板要求你回顾你的 OKR 时，他通常会在会议室里这样做，然后每个人一个接一个地进来讨论 OKR。

微信上很难预定会议室，总是有人在那里开会，要提前2天才能预定到房间。

没办法，房间那么少，毕竟在微信上我只看到GM有自己独立的办公室，很多助理GM都没有自己独立的办公室。

终于轮到我了，老板发信息给我：来XX会议室谈OKR

会议室不大，很安静，我和老板面对面坐着，桌子上放着一本笔记本，方便我做笔记。

老板讲话了。

老板说你的OKR没有围绕着一个业务的大目标去分解，然后把这个大目标分解成一个个小的O，然后围绕着每个O去写KR。

确实，我的 OKR 中的每个 O 都是有意义的，但不够直观，而且我不知道每个 O 对整体 O 的贡献如何。

在老板眼里，最直接的就是看我们设定的每一个O跟总体目标是如何对应的。

另外老板还建议每个OKR的O和KR尽量量化，这样更方便评估。

这个很难，你要知道很多数据分析工作是为了支撑业务的，很难量化结果的提升。

我想大家都有同感，虽然数据分析的愿景往往是改善XX指标，但结果往往很难，其实更多的工作是在改善XX指标的过程中完成的。

这个过程很难量化。

检查完OKR后，我默默地走出办公室，抬头看了看外面的风景，心里好失望。

所以，负责对接业务的数据分析师的 OKR 里的 O 是和业务紧密相关的，这也是为什么像上一篇文章提到的，会花很多时间来把产品跟业务方向对齐。

所有这些都是为了更好地为企业贡献可量化的价值。

我越来越发现 OKR 可以帮助我们清晰地理清半年内的计划和方向，避免我们不停地做一大堆杂活，然后在年底才发现我们所做的事情对业务没有任何价值。

价值为王，这是数据分析的本质。

刚回到座位就又接到临时通知，项目组成员需要回顾一下项目进度，基本上就是讲一下最近几天大家在项目上做了什么，遇到了什么问题，怎么解决的。

总是有很多本来应该协调进展的会议但却毫无用处。

这些会议太浪费时间了。一天的时间本来就不多，而白天又要开那么多会议。通常开完几个会议，上午和下午的时间就没了，只有晚上才能工作。

那么，为什么会有996呢？它并没有从根本上提高效率，只是增加了时间，有用吗？

你见过白天不上课、不做作业，但晚上却堆积如山的作业，而且成绩很好的学生吗？

这确实很难。为什么不在最有效率的时间段完成工作，然后将此类会议的频率或时间移到晚上呢？

我从来不理解人类的聪明才智。

开会、浪费时间、加班、效率低下、更多的会议，循环往复。

我工作的时间越长，我发现自己作为学生的时间管理得越差。

虽然那时你是一个人在学习，但现在却是一群人一起学习。

不过，我们可以按照自己的时间安排会议，不然真的会陷入被各种事情耽误，没时间真正静静地做事的困境。

项目对接沟通会已经开始。

会议中的角色分别是：产品同学小A，数据挖掘同学小B，小C，我，开发同学小D。

产品经理小A主要负责把控项目的整体进度，了解项目目前的进度，并且给我们每个人提供需求。

我的产品同学都是海外名校毕业的，在微信上认识了很多清华北大等海外名校的产品经理，感觉这里招产品同学很注重学历和背景。

毕竟鹅肠产品每年的报名人数和录取人数之比都是1000：1，即便是微信，也比这个数字要少。

当然有的还挺好看的，又漂亮又帅气，普通话说的也挺好，这里就没图了哈哈哈

在微信上跟越来越多的产品经理交流后，我发现这里的产品经理们都非常好，虽然他们不一定理解数据驱动产品的策略，但是他们会非常听取我们的想法。

数据挖掘学生小B和小C主要负责实现某业务推荐的算法迭代，主要工作是通过挖掘用户的行为模式，推荐用户喜欢的内容。

数据挖掘的学生很勤奋，我经常需要今天制定策略，明天再帮他们配置实验指标，所以我这边的工作量也很紧张。

开发人员小D主要负责实现推荐算法的开发和上线，因为有些推荐算法需要开发人员的帮助才能部署上线。

开发人员非常好。他们基本上响应请求非常快，完成请求也非常快。与这样的同事一起工作非常有效率。

我最看不惯的是互联网行业里的一些老人，仗着工作时间长，可以坐很长时间来处理一个请求，对响应请求的积极性不高。

我的工作是帮助挖掘学生评估他们的策略并帮助产品学生编写相应评估指标的报告，以定期监控推荐迭代的效果。

互相指责的会议开始了。

战斗总是迟到，但从未缺席。

我们的项目将探索学生针对某一业务的排序算法的改进和迭代。

为了验证算法的有效性，我们利用内部ab测试平台进行小规模的流量实验，来评估哪种算法最好。

这个平台的搭建花费了很多人力，听说很多经验都是从学习来的。

不得不说他们的实验平台确实做的非常好，发表了不少专业的ab test实验文章。

上一篇文章我们提到了数据分析师负责配置实验的指标，我们的任务就是和数据挖掘工程师小B沟通需要哪些指标来评估算法的有效性，确定每个指标的计算口径，也就是这个指标怎么算。

我们在做这个项目的时候，矿业同学小B说，我们数据分析师配置的一些指标进度还没有完成，所以不能全面评估实验的效果。

这样会让产品同事感觉我的效率很慢，因为我的工作效率影响实验结果的整体评价。

然而我们的实验指标的诞生是一个漫长的过程。

每次实验的指标都要跟数据挖掘的同事、产品的同事确认，因为每个人看问题的角度不一样。你需要拿出一个能够符合业务方需求的指标，而且这个指标要可量化、科学、有长远性。

指标确定了就完了吗？

当然不是。你还是要跟他们确认一下这个指标是怎么算的，为什么这样算。不然实验指标配上去的时候，

有很多黑色的问号：这个指标不是我想要看到的，为什么要配置这个指标？

确定了指标范围之后，还需要编写SQL来实现这个指标。

蜀道难，难于上青天。

有些指标的计算需要关联多个表，而且指标口径非常复杂，所以要做很多层层限制，这样不仅写起来费时费力，而且很容易出错。

这个能快点写吗？

当然不是。

所以挖矿同学就怪我们配置太慢，导致没有测试指标可以评估。我只想说，这些指标计算和配置都是需要一定时间的，中间的计算细节你们也不懂。这件事情只有我们自己最清楚。

网络上，经常存在这样看似隐形的甩锅行为，很多人以为需求很简单，可以很快完成，殊不知要保证准确完成，背后还需要很多细节的确认，远没有想象的那么简单。

相互理解很重要，否则推卸责任只会导致争吵。

会上，矿业同学同步公布了一些实验指标的结果，看上去都提升了XX%

ab测试实验要严谨、科学。

至于他们所说的改进，我很快发现他们的实验根本不是 AA 实验。

什么是 AA 实验？

现在有A、B两个学生，我们让B使用BBK点读机，我们需要验证BBK点读机是否能够帮助学生提高学习成绩。

在验证之前，我们要确保这两名学生在使用这台阅读器之前的学习成绩应该是差不多的，学习努力程度等条件也差不多。

这种验证叫AA验证，就是验证两个人的学习成绩是否有差异。

因此可想而知aa检验的重要性，以及它如何直接影响ab实验的结果。

作为专业的数据挖掘工程师，他们没有做aa测试，而是把ab阶段的实验结果同步给了我们。

这简直是​​无稽之谈。

于是，我当场就直接表示这个结论不可信，并问他们为什么不做aa而是直接做ab？

他们给出的答复是，要赶进度，所以就直接放到网上了。

是的，因为比较着急，我们经常没有确认数据的科学性就直接报道。

直接的结果是必须重新完成实验，并且用户被污染，因此必须为实验选择新用户。

轮到产品了。

产品同事通常会告诉我们该项目的一般计划是什么。

例如，他们最关心和想要改进的核心指标是什么？