转行做数据两年多，一直没有弄te一套体系化的复习巩固方案。现在借简书平台，记录下我在工作和学习中，有关数据库开发、数据分析和数据挖掘等方面的笔记。/致敬那浑浑噩噩的点点滴滴

日常工作

    1.日/周/月报；

    2.临时提数需求；

    3.常规工作的优化（需求变更和需求新增）。

日/周/月报

日报是每天都需要关注的，但在工作中往往得不到足够的重视（有的组甚至没有日报系统，比如我们组...）。日报体现在实体上，涵盖业务指标的变化，系统软硬件的监控，需求的完成进度和人员的任务分配等。而分析日报主要有三个目的：

    1.了解业务现状；

    2.培养数据敏感性；

    3.提供业务发展建议。

首先是了解业务现状，很多人会说：“每天数据就那样，没什么好看的。”实际上，若数据真就一直那样，那就说明公司的业务或系统出问题了，而这时如果你能够根据细节上的变化指出问题和风险点，就一定能够得到展现自己的机会。

然后是培养数据的敏感性，数据的敏感性都是慢慢培养出来的，没有人天生就对具体业务敏感。如果你可以每天关注数据的波动，潜移默化的便会培养一定的敏感性，比如之前基金的每日认购在 500~600 万之间，突然变成了 650 万，这个时候你能够发现便会并去寻找原因，这便是数据敏感性。

最后就能够根据数据波动寻找波动原因，久而久之你就会发现产品或运营在做出何种调整后数据会出现涨跌，系统资源为何会出现偏移。进而能够为业务发展提供更合理的建议，为系统的平稳运行增添又一道保障。

在日报的基础上，周/月报就可以看作是一个趋势了，因为很多需求的发版周期往往是一个月内。新版本的效果能够直接体现在周/月报中，同时长周期的数据会更加稳定、更具说服力，也更能够为接下来的业务提供更合理的发展建议。

数据敏感性和业务的发展建议都是从日报/周报/月报的分析总结中不断积累的，而对于大部分公司来说日/周/月报只是常规性的经营分析，罗列数字，很多时候失去了数据分析的本质意义。

所以一定要经常看三种报，培养自身的敏感性，从而找到获取业务增长的发力点。

临时提数需求

很多人都是在不断地满足临时提数需求，久而久之就成了别人口中的“大表哥”，“大表姐”。一定要想办法进行“自我”优化..

目前我将临时提数需求分为两种，一种是管理层的需求，另一种是业务执行人员需求。

对于高管层的临时提数需求，优先级肯定是最高。但此时一定不能立马去做，而是需要思考为何需要这个数据，通过这个数据能进行什么决策。举个例子，CEO 现在正在与外部公司商谈合作事宜，需要了解用户人均时长，如果你不知道这个背景前提，给出的数据往往有误，这时需要及时的与领导进行沟通。

而业务线的临时提数需求是非常繁多的，比如数据指标口径、数据增长计算，等等，这时就需要你根据自身的实际工作情况合理安排，学会合理地拒绝一些业务线可以自己解决的事情，不断提升自己的工作价值，不要一直陷在临时数据需求的泥潭。

得到的原则就是坚决不做提数机器，针对每一个业务单点问题，先追根溯源，建立该业务类的分析框架，由点及面彻底解决该类问题。同时在这个过程中不断利用互惠原理和社交技巧，只给业务方做最核心的需求，其他衍生需求由业务方自己完成。

常规工作的技巧

第一个技巧关于报告的处理，如果每一天都需要花费很多时间去分析，不如交给机器处理，比如通过 Python 搭建日报分析框架、通过操作系统的定时任务和ETL工具定时发送分析日报邮件等，减轻工作压力。

第二个技巧就是因为每天会有大量的业务需求需要数据支撑，这时便需要保持一颗清醒的头脑，能够将需求进行合理的优先级排期。（简单来说就是能不做就不做，不做的就忘掉嘿嘿嘿）

第三个技巧就是遇到自己不能解决的问题时，及时与自己的领导进行沟通，不要低头盲目做事，很多时候他们会看得更高，难题往往可以迎刃而解。

专题分析

在工作中，各个业务方都会不定期的提出一些比较专业的分析任务，我们称之为专题分析。

    1.需求解读；

    2.建立逻辑树；

    3.SQL 提数及分析；

    4.撰写报告的三个建议。

大部分人对第 3 步比较熟悉，但对 1、2、4 步掌握都不够好。

需求解读

一定要花至少 20% 的时间分配在沟通需求上，一定要当面沟通（或许吧哈哈），并且这个过程贯穿整个分析过程。过程大都是：原始需求->了解需求->渗透本质需求。

要持续沟通直至发现需求本质，避免需求武断和需求模糊。

建立逻辑树

比如一次营销活动，可以这样建立逻辑树

        活动前    流量效果

                        流量波动原因拆解；

        活动中    dau\mau提升

                        新客户流入

                        老客户唤醒

                        活动期间连续访问情况和活动效果对比；

        活动后    新用户沉淀

                        换回老用户后续活跃度

                        活动复盘。

建立逻辑树的目的是让思路更加简洁清晰，比如针对上述活动运营分析，涵盖了活动前、中、后，同时活动前又包括了流量和收入。以流量为例，流量包括活动前每天的流量效果，因为活动前往往会做一些预热，所以会出现流量波动。

同时在活动中，也涉及流量和收入，比如 DAU/MAU 是否提升，拉新情况，老用户唤醒情况，活动中连续访问情况，上线频次分布，等等。同时还需要注意各类活动的横向对比情况，进而可以对业务提出优化建议，而不只停留在简单的数字上。

而活动后的流量涉及拉新用户的沉淀效果如何？不活跃的老用户在活动中的表现，后续活跃度如何？以及汇总数据和复盘数据分析。

面对需求一定要建立合理的逻辑树，有了逻辑树才能知道具体需要分析的点是哪些。

SQL 提数及分析

这...相信表哥表姐们应该都达到这种程度了：只要能用语言逻辑清晰的描述出来的（清不清晰也无所谓了...），需求解读和逻辑树一通过，都能给你整出来。（三段论论、组成部分，项分布、深层挖掘）

撰写报告的三个建议

    1.报告一定是 90% 的图加 10% 的文，以图为主，文字为辅，图表标题点明结论。

    2.结论前置，如果报告最终要呈现给领导的，那么在邮件中一定要把结论先写出来，然后报告以附件形式发送，同时在正文中也要把结论前置，节省大家时间。

    3.报告的逻辑性一定要非常强，同时演讲的过程中也需要有故事感，站在领导的角度去想他要听什么？