小A同学每天都有大量的临时提数需求或者杂事，没有时间去做真正的专题分析。
感觉自己的能力提升不了，工作越来越没意思，做事不认真，老师出错，最近跟同事领导关系变差，年底考核，领导给小A的绩效不太好，回去之后年终奖少了很多，感觉事业感情不顺利，失眠、有点抑郁
小A有很多问题：能力提升不了、做事不认真、跟领导关系变差、跟女朋友吵架、失眠
然而真正的问题是：小A当前工作上有大量的临时提数，没有时间做专题分析。
问题的逻辑树拆解 方法论 找到本质问题二八定理思考：遇到n多问题，必然有一个主要问题，一旦这个问题解决了，其他问题也就迎刃而解，也就是一定有破局点的。
怎么找到这个主要问题：
先列出所有问题，头脑风暴根据最大概率法则，一项一项来试。如果你真的不会，那就请教你的leader技巧：一定要静下心来单独思考这件事，动笔画图。 问题的逻辑树拆解
MECE原则：不重复不遗漏
然而实施起来不容易：一是因为信息的不对称性，很难没有遗漏或者说：业务方想的你还真不一定都直到；二是因为开始做的时候，你真的很难去把我会不会重复，实际上重不重复对结果影响不大
对于一个陌生的问题，总是要试错的，这个是事物发展的规律
所以还是这样更加有实操性，实际工作中也就是这样：
1、先快速按照你的理解去做拆解，不要管重复遗漏，能够想到多少是多少2、拿着你的拆解去跟业务方的一个脑子灵活的人对，请教他——业务方再想3、修改第一步的思维导图，做完后请教你的leader——你的leader再想4、再改一次，汇报给业务方leader——问题不会很大，否则就不是否定你一个人了 具体案例 案例背景
某app前期的用户量一直在下跌，近期转型（新功能取代第一大功能），然而转型过了一段时间后，整体用户大跌，业务负责人压力很大，希望数据部分派人100%投入分析，然而数据方觉得大跌就是因为转型，没什么好分析的，于是两个部分就对上了，数据方觉得产品太烂，业务方也不给数据放需求，数据人员存在感不强，正在考虑是否跳槽，业务进一步下滑，业务方投诉数据部分，决策层在考虑找新的数据部负责人，然而不太好找，各方压力越来越大。
找到本质问题用户量大跌的排查——破局点数据方与业务方关系非常差数据方存在感不强找不到新的数据负责人
现在你一眼就能看到最主要的问题：1、是因为本身没有代入感，2是这里描述的相对简单
真实工作中，在各种复杂因素下，还真不一定很容易找到破局点，比如：你自己都觉得产品没啥戏了，再加上存在感不强，所以你就去找工作了
问题的逻辑树拆解 再感触在做专题分析的时候，一定要找到真正业务方关系的点，他们到底想要什么，就是他们可能说了很多点，但真正的破局点是什么，再对问题拆解，这样做的好处是：
能够让业务方清晰理解你的意思，如果你表达能力不是很好，就请画图有了具体框架后，业务方会提出具体的建议，这个过程的价值是巨大的
有些工作很多年的人，始终不知道如何去提升自己，这个时候请获得他人的反馈，每次反馈都是对你内心的冲击，也只有这样，你才能真的提升
二、数据获取和分析 前期准备一般来说，在正是写sql之前，要花1天时间去做以下几件事：
1）哪张表、那份日志
2）筛选条件
3）之前有什么坑
4）现在是否有坑：select * ，先跑一个核心数据
对数据有一点感觉的基础上，再把问题的拆解模块构思一次，哪些点不好做，有个预期
因为提数的最终目的就是为了分析，所以这两部是一起的，看似简单，但是往往比较花时间
1）各类其他事情打扰：专注
2）遇到坑：一定要文档详细记录下来
3）突然找到一个新的点，然后一直往下挖：
4）不会提数和分析，不知道如何看数据：看同事再模仿
渠道占比分析
如何分析—对比分析对比分析：所有数据之有对比才有意义，每年的双11都会与之前的双11进行消费额对比；实际工作中，最常见的对比对象就是大盘，比如新上线一个功能，怎么评估这个功能效果，除了看功能使用人数，更加要做的是这个功能的留存和大盘的留存的对比
举例：需要看自身APP跟竞品的重合用户，与自身APP的所有用户在客户端内的消费差异，从而针对这些重合用户，做只针对性运营，这个时候要用对比分析
时间序列二次拆解分析：一般看某指标时，都会时间周期拉长，看数据趋势，而数据都是波动的，所以都会进行拆解分析，寻找具体波动项
举例：新增用户留存分析，进行渠道维度拆解分析
落地项：该地区用户整体更加偏爱高价格产品，可进一步优化产品结构，产品偏高端产品，产品经理可进一步优化该产品特征
如何分析—机器学习基础代码非常容易，但确实能够帮助找到切入点：开通月数和点支付这两个变量非常重要
如何分析—总结实际上所有的分析都是基于用户的基础属性和行为属性，如果还是不会，那就从5W1H出发，每次分析的时候都以这个为模板来展开
who：用户基础属性where：渠道分析when：时间上特征what：使用了什么，哪些行为更加重要why：为什么要这么做，主动还是被动how：怎么做的，行为路径是什么 最后
提数和分析完成后，先不要急着写报告，把一些关键数据和初步结论同步给业务方核心人员，约个时间一起看下两个目的：
他们怎么理解这个数据，有无明显问题他们基于这些数据结论，准备怎么落地，需要他们提前想方案
在这个基础上，再撰写报告
三、报告撰写
撰写报告原则
主题一脉相承分叉：只有一个主题，每页ppt围绕该主题来分叉展开通俗简单易懂：数据分析的报告一定是简单的，大白话的，看产品经理日常怎么写报告的结论和闭环先行：没有明确结论和落地项的报告就是数据堆积。跟业务方多沟通数据结论，让他们给出落地项，不要自己闭门造车给建议。 报告的组成部分 1、标准化组成部分
背景：为何要做这份专题报告，即问题的识别分析结论：如果面向管理层的汇报，结论可以先行分析框架：即问题的拆解，往往这里不需要很细第一个关键点结论第一个关键点的支撑数据依次摆放第二个关键点结论第二个关键点的支撑数据依次摆放整体结论：这里把结论再汇总依次落地项：产品是怎么落地的，要非常具体，时间、人、预期效果 2、如何衡量专题报告的价值
只要最后有1~2个真的应用了，这份专题报告就非常有含金量
具体案例 结论和闭环先行这一页应该是这样：
基于什么数据发现什么结论基于这个结论的建议是基于这个建议的产品落地项是 四、AB测试 AB测试介绍 1、概念介绍
AB测试是为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客随机访问这些版本，收集各群组的用户体验数据和业务数据，最后分析评估出最好版本正式采用。
2、AB测试流程根据数据分析得到某建议项根据建议项，产品经理得到某落地项根据某落地项，研发设计人员进行开发设计（往往是先设计，在丢到AB测试平台里面跑数据）研发人员数据采集：自动采集数据分析师跟进AB效果，显著性在95%以上并维持一段时间，实验可结束整体节奏：灰度、5%、10%、20%、50%、100%
业界都是一套AB测试平台（自研或者购买），能够每天进行大量的AB
3、常见的两种AB测试类型—UI界面型
界面元素进行AB测试
4、常见的两种AB测试类型—算法策略型针对新用户的内容推荐
A策略：100%兴趣预选
B策略：80%兴趣预选+20%随即内容
当前对任何一款个性化内容APP，给用户的推荐都涉及到大量的算法策略型AB测试
一般而言：AB两个组样本都要在10万以上才可以看初步数据
严格模式下，所有的专题报告落地项（除了明显的bug修复和明显的用户体验），都要靠AB测试展开
然而，分析师经常会遇到这总问题：
case：2个月前产品上线了短视频功能，两个月后，大盘略涨（之前是略跌趋势），短视频和非短视频的数据也增加明显，现在短视频业务方希望分析师能量化出：大盘的上涨主要是短视频带来的
有些分析师的思路：用同一批用户，在使用短视频前后的数据对比（违背了AB测试的同一时间，可考虑相关性分析勉强验证）
针对这种问题：只能靠AB测试去解决，在上线短视频功能前就应该AB，否则后面怎么都说不清
AB两个组是否真的相同（只有一个变量）—研发负责搭建，但分析师要知道大概原理策略是否生效—研发说进行了AB测试，但分析师要去抽样看AB测试评估指标体系—要在AB测试之前，就与研发沟通好看哪些综合性指标多观察几天数据—往往前几天数据可能有点问题，一般3天后数据才可正式使用（第4~10天数据）AB测试的存档规划—所有的AB都要文档化，方便后续找到增长点。采用4w2h方法管理AB测试：具体内容、为何测试、测试时间、测试负责人、预期效果、实际效果 AB测试案例
