数据分析-思维分析逻辑day04

一、问题定义和拆解

举个例子

很多人的困惑

小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 * ，先跑一个核心数据
对数据有一点感觉的基础上，再把问题的拆解模块构思一次，哪些点不好做，有个预期

SQL提数和分析

因为提数的最终目的就是为了分析，所以这两部是一起的，看似简单，但是往往比较花时间
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万以上才可以看初步数据

5、实际工作中的问题

严格模式下，所有的专题报告落地项（除了明显的bug修复和明显的用户体验），都要靠AB测试展开
然而，分析师经常会遇到这总问题：
case：2个月前产品上线了短视频功能，两个月后，大盘略涨（之前是略跌趋势），短视频和非短视频的数据也增加明显，现在短视频业务方希望分析师能量化出：大盘的上涨主要是短视频带来的
有些分析师的思路：用同一批用户，在使用短视频前后的数据对比（违背了AB测试的同一时间，可考虑相关性分析勉强验证）
针对这种问题：只能靠AB测试去解决，在上线短视频功能前就应该AB，否则后面怎么都说不清

AB测试注意事项

数据分析师需要注意什么

AB两个组是否真的相同（只有一个变量）—研发负责搭建，但分析师要知道大概原理
策略是否生效—研发说进行了AB测试，但分析师要去抽样看
AB测试评估指标体系—要在AB测试之前，就与研发沟通好看哪些综合性指标
多观察几天数据—往往前几天数据可能有点问题，一般3天后数据才可正式使用（第4~10天数据）
AB测试的存档规划—所有的AB都要文档化，方便后续找到增长点。采用4w2h方法管理AB测试：具体内容、为何测试、测试时间、测试负责人、预期效果、实际效果

AB测试案例