一.数分析师岗位

• 业务型： 业务型对分析师的业务理解能力要求高
• 数据研发型： 要求对技术熟悉，能够通过技术对数据进行分析
• 算法型： 要求数学功底好，课题研究能力强

二.常规工作

2.1 日、周、月报

• 日报：提供业务发展建议，寻找波动原因，做出何种调整
• 周报：短期趋势
• 月报：周期长，能为后续业务提供更合理的发展建议

2.2 临时数据

• 高管层：优先级高，但不能立马去做，要思考为何需要这个数据，能进行什么决策，确保数据准确
• 业务线：数据需求繁多，根据自身实际情况承接，学会合理拒绝业务线自己解决的事情，提升工作价值

​ **原则：**不做数据提数机器，针对业务单点问题追根溯源，建立业务类的分析框架，由点及面的解决该类问题，比如业务想看单独一个产品销量，取数给他了，但是又提出看些同比，或者趋势等数据，这样会导致工作效率低，能力得不到提升，要形成一个套业务分析框架，在他取数前确定好是否要取这个框架内的数据

2.3 常规工作优化

• 保持一个清醒的头脑，对需求进行合理安排
• 对做过的数据分析进行优化，可以用python进行自动化
• 及时和领导同事沟通

三.专题分析

实际工作中，各个业务方都会定期给分析师提出一些比较专业的分析任务，称为专题分析

1. 需求解读
2. 建立逻辑树
3. SQL提数及分析
4. 撰写报告的三个建议

3.1 需求解读

需要花20%的时间进行需求解读

3.2 建立逻辑树

3.3 SQL提数及分析

• 提数：

  ​ SQL三段论，所有想法验证的第一步

• 分析

​ 组成部分、数量比较、有何变化、各项分布、各项相关性、其他深层次挖掘

3.4 撰写报告的三个建议

1. 以图为主 报告一定是90%的图加10%的文，以图为主，图表标题说结论

2. 结论前置

3. 逻辑性一定要强，结构清晰，演讲过程中要有故事感，站在领导角度去想他要听什么

3.5 软技能

​ 做好数据分析除了自身专业技术过硬外，软技能的修炼非常重要，比如快速理解领导意图，有条理地表达，可以看些心理学，社交等书籍

四.日常工作

数据异常的排查、融入专项

做专项分析并负责KPI、埋点，指标体系等

4.1 数据异常排查

数据有较大波动，无非两个原因：

1. 目前数据本身有问题
2. 业务本身有问题

如果能够透过问题看本质，就可以成为在数据波动方面的专家

1、数据异常排查的前期准备:

• 业务理解
• 指标口径
• 当前数据产出过程

2、数据异常排查

第一步：判断是否异常四个关键点

• 亲自去看数据准确性，不能人云亦云
• 时间轴拉长，看是近期异常（3个月）还是历史异常
• 看和该指标关联的其他指标或其他核心指标是否也异常
• 找到一个关键人物（产品/数据），提前沟通。 经验往往能快速定位问题所在

第二步：最大概率法则原因归类

• 假期效应：开学季、暑假、四大节日、当地节日
• 热点事件：常规热点（世界杯）、突发热点（爆款IP）
• 活动影响：双11/618等
• 政策影响：互联网金融监管，快递实名
• 底层系统故障：数据传输、存储、清洗有无问题
• 统计口径：业务逻辑更改、指标计算方式更改等

第三步：闭环，当我们排查出问题原因后，一定要形成闭环，关于闭环有三个点

• 持续跟踪后期数据是否再次异常 如：当我们排查出原因后，产品做相应的改进，而问题仍然存在，说明排查问题出错
• 记录、沉淀、文档化，因为后续我们可能还会遇到相同问题，所以记录文档利人利己
• 邮件化，只有确认没有问题再发邮件给相关方，描述影响乏味和主要结论即可

4.2 专题分析

三个特征

• 有目标，紧贴项目KPI

• 有节奏，2-3周时间输出一份完整报告

• 有闭环，所有的报告都要说人话，做人事

五 .课后问题解答

问题一: 流量波动，数据突然涨了怎么分析–考察分析师的经验怎么样?

六.自身情况评估

无论是横向还是纵向上，数据分析师牵扯的业务很多

有些分析师自己也知道当前做的事情好像对能力提升意义不大，所以可能会出现两种现象：

• 在数据分析专业性上略自卑，觉得自己当前做的事情很杂，所以拼命学习充电，但好像落不了地，学得快忘得快
• 专业性上过于自信，因为很多东西都接触过，觉得自己什么都知道，然后想跳槽发现不是特别容易，但也不知道问题出在哪里

6.1 如何评估自己

• 产品理解能力

  各种数据的熟悉度，用户从哪里来，进来做了什么，反馈最多的问题，竞品数据如何。用数据说话，而不是大概

  比如一半的用户从微信渠道进来之后使用了什么产品，然后在使用产品的过程中有多少用户又因为什么问题走了，这就是产品理解能力

• 分析方法论

  如A/B测试，最大概率法则，二八定律，幸存者偏差等

• 可视化能力

  PPT和逻辑能力

• 演讲能力

  要去跟管理层汇报，个人表达能力，讲故事的能力等等

• 协作能力

  跟产品、业务、研发沟通时的软技能。注意在团队中经营好自己的位置，让其他人舒服

• 逻辑思维

  保证分析推导过程的全面性和理性价值性

• 技术

  sql能不能写出来，能不能搭建模型，调试模型，修正模型，实际上就是你没有真正实践过

6.2如何优化自己

6.2.1 产品理解能力

以产品理解为例，先以A当前公司业务的产品为切入点，熟悉最核心的数据，了解功能渗透率和关键路径，以这些数据为切入点去思考当前的产品有哪些问题，并与产品经理沟通如何优化，同事要去看竞品数据和行业数据，最重要的是深入了解而不是略懂

6.2.2 数据分析方法论

能快速从一个较全面、逻辑性、价值性的角度去分析

而不是单点无架构性，所有方法论都是通过不断提炼、总结、实践得出来的

这是评估一个分析师水平的重要标准

七.数据分析整体流程

7.1 Excel常规使用

• 对比分析（筛选和色阶功能）
• 时间序列拆解分析（透视图功能）
• 相关性分析（常见函数功能）
• 临界点分析 就是Magic number

7.2 SQL常见问题

常见现象：一旦关联表较多，内部逻辑稍微复杂，就怀疑自己的代码准确性

解决方案：

• 如果公司内有一个写SQL高手，在前期每次怀疑时，一定要把代码给对方看下，多请教，同事模仿其写代码的风格和逻辑，2个月后在评估自己水平
• 如果公司内SQL水平都差不多，只能靠自己了，全部运行一遍，然后看哪个数据跟当前已知数据最为接近，最为合理

7.3 Python

• 爬虫：爬虫在工作中价值很大，不如爬取一些竞品数据。比如，资讯类的文章，数据等等

• 文本挖掘：对评论数据研究价值很大，比如对App评论数据的分析，从而得知如何去做评论运营闭环

  比如：京东网易App的评论运营，其他App的热点评论

• UDF函数：hive自定义函数有时不能满足需求，此时就需要自己定义函数来实现需求，这是就可以用python写UDF

• 对于算法研发岗位：个性化推荐，底层运维，Web开发都是通过Python来实现

八.多元思维模型：数据分析需要具备的四大能力

8.1 背景

• 中观能力

  是真正的专业度，看你是否能发现其他数分析师在分析问题中的问题，这个专业度不单指你的技术，而是需要你长期总结和思考

• 微观能力

  微观能力指有效沟通力+快速发散收敛力，看你是否能从业务交流中发现问题，找到方向，要意识到这一点

• 宏观能力

  是洞见性的全局观，能够从社会事件和整个行业发展中找到业务的决策方向

  这是极难的能力，同事平台和天赋缺一不可

8.2 中观能力

指专业度，包括技术理解、逻辑性、价值点三个点

是反映分析师基本功怎样、套路熟不熟悉、思考到不到位的一种标准

8.2.1 技术理解

指对分析师用的技术理解到不到位，是否停留在理论阶段还是实践阶段，有很多同学看了很多数据分析的书籍，理论说起来无所不知，但在实践过程中还是遇到很多坑

两个解法：

第一对客户进行先分群，再用MAX-MIN进行标准化

第二以90%中位数替代MAX，消除头部影响，让数据变得不那么稀疏

8.2.2 逻辑性

指对整体思考的逻辑性是否欠缺

其实相关性是种基于向量的伴随关系，不代表直接的因果关系（但确实是因果关系中的一个可能性）也就是说留存和自媒体文章下发的占比是一种伴随关系，而不是因果关系，留存的影响因素非常多，不仅仅是一个两个指标就能很好提升留存

分析师的逻辑性是非常重要的，每一环节的推导必须要讲究严谨性，不能有侥幸心理

8.2.3 价值点

强调价值，你做出的分析价值在哪，如果你是决策者，敢不敢立马规划落地

建议：多沉淀、多总结、多反馈、多思考

8.3 微观能力

如何做：

首先要知道业务是怎么想的，怎么做的，然后从中发现问题或者切入点

具体来说就是有效的沟通能力和快速发展能力

• 有效沟通能力：值在于业务核心人员沟通时，要从谈话中快速捕捉到有用的信息

  • 技巧1 黄金思维圈法则

    在了解业务的情况下，反问业务方为何要做这件事，基本上，业务方都会有一个很具体的回答，往往都能在这里找到切入点

  • 技巧2 提前做准备在沟通

    在于业务沟通中，如果没有提前做一些业务知识和数据，整个过程就是业务在主导，无法发现问题

• 快速发散收敛能力：收敛能力基于沟通中的有效信息，快速提炼总结找到最好的分析切入点

  • 发散：指对某一个全新业务问题，跟业务沟通之后，分析师想法很多
  • 收敛：在众多想法中，快速找到当前做那个比较合适、合理，并且知道如何做的深入
  • 如何培养
    • 多和业务方沟通，特别是业务leader，看他们是如何理解思考业务的
    • 多看写心理、社交、经济、记忆、科普类书籍，对培养微观能力有好处
    • 刻意练习，慢慢养成习惯，一定要静下心来做事，相信一定能够把微观能力培养好

8.4 宏观能力

九. 电商数据分析 – 以京东app为例

9.1 如何看京东app

1. 引流（场） 首页作为最大的带量单位，分发效率怎么评估
2. 漏斗（货） 北极星指标交易额只是一个数字，更加重要的是理解这个数字转化的过程
3. 用户（人） 作为一款非常成熟的app，老用户相对比较稳定，但新用户获取应该怎么优化

9.2 整体数据分发效率

• CTR :CTR = 点击UV/曝光UV,反映用户点击欲望的指标
• 点击UV： 每天有多少用户点击进入到页面
• 曝光UV：每天有多少用户看到了页面
• 人均访问页面数: 总访问页面数（PV）/总访问UV
• 总访问页面数PV：点击所有页面的次数总和是多少
• 总访问UV：点击所有页面的人数总和是多少

在这个过程中，你需要找到负责的产品跟大盘的数据关系，一般是分为以下三种：

1. 该产品确实带来了大盘的提升
2. 该产品只是在抢大盘的流量，比如该产品模块的流量在涨，但是大盘再跌
3. 该产品部分在抢大盘流量，对大盘有部分提升，提升度是多少

9.3 漏斗分析

可通过看书，问老同事来提高漏斗分析的能力

9.4 新用户分析

拉新必然就要衡量拉新效果和拉新优化

京东市集活动拉新效果内容部数据我们获取不到，但作为一名分析师，可以去看整个app在拉新上可以优化的点

拉新如果做的好，比如老用户分析更容易出成绩

十. 互联网金融：芝麻信用分的建模过程是怎样的

10.1 背景

互联网金融的本质是风控，数据分析师在及金融行业基本上有两种角色：

• 数据建模师：要求对算法的理解较深，相对来说对行业经验要求不是很高
• 风控分析师：除了一定的模型理解能力，还需要大量的行业和法律法规经验

互联网金融与其他行业不太一样，互联网金融在产品对象上分toB和toC

• toB：对企业整体的信用进行评估做整体授信
• toC：对个人的信用评估

10.2 授信模型

数据模型运行周期

在产品初期，因为模型的变量太多，所以模型的迭代速度比较快，基本上每个月都要跑一次分数，这个时候会出现某个用户的分数提高，这些都比较正常，而这些都需要不断地调整权重和系数，慢慢优化才行，不过最重要的函数模型落地效果，如果坏账率比较高，再调参数

10.3 模型落地

十一.指标体系

13.1 指标体系的定义及选取原则

令人不悦的两种情况

1. 对于核心数据，如日活，只知道数据在变化，但不知道为何变化，特别是处于一个较大跌幅时，产品为了解释这种现象，就会向数据分析师要各种纬度的数据
2. 每隔一段时间，产品都会拉上数据、研发一起对埋点，总是觉得当前的字段不够用，底层日志越来越大，数仓修改的越来越多，取数越来越慢，错误越来越多

根本原因都是在于缺少指标体系的建设、宣贯以及实施

业务方不重视指标体系是感觉指标体系是基建活，离完成KPI太远，只有出现问题时才会临时重视

数据方不重视指标体系谁因为这是一个吃力不讨好的工作，做好了可以，做不好背锅

甚至有些分析师认为，指标体系只是一个思维导图而已

指标体系是 埋点、取数的前提，如果指标体系做不好会始终很乱

11.1.1指标体系是什么

指标体系是在业务的不同阶段，数据分析师牵头，与业务方协助，制定的一套能从各个维度反应业务状况的待实施框架

1. 在业务的前期、中期、后期，指标体系不一样
2. 一定是由分析师牵头与业务方协助，而不是闭门造车
3. 从各个维度去反映业务的核心状况，指标有很多维度
4. 最后就是一个大的实施框架，一定要实施，否则就是浪费大家时间

11.1.2原则

• 根本性

  对于核心数据一定要理解到位和准确，如果这里错了，后面基本不用看

• 可理解性

  所有指标要配上业务解释性，如日活的定义是什么，是产品的打开还是内容的点击还是后台进程运行

• 结构性

  能够充分对业务进行解读，如新增用户知识一个大数，还需要知道每个渠道的新增用户，每个渠道的新增转化率，每个渠道的新增用户价值等

11.2 建立指标体系的四个步骤

11.3总结

• 指标体系本质上是业务人员和分析师逻辑性怎么样，这个非常重要
• 不同业务阶段指标体系不一样，核心指标一定要正确
• 核心指标的拆解通用模式，都是先公式拆解，再按照业务模块、路径来分析指标体系的宣贯和存档工作必不可少

十二. 流量分析 如何分析数据波动

12.1 背景

​ 建立产品指标体系和报表之后，分析师和业务方最重要的事情就是每天看各种数据，而这个看数据的过程就是流量分析，这里的流量指广义的流量，并不一定单指日活，是指所有的流量，比如用户从哪儿来，经过什么过程，产生什么价值，如果流量波动了，为何波动

从流量分析的定义来看，可分为一下四部分：

• 渠道分析—从哪来
• 转化分析–经过什么过程
• 价值分析–产生什么价值
• 波动分析，包括日常的监控分析

12.2 渠道分析

12.2.1 常见过程

• 常见渠道和渠道分类
• 渠道推广的整个过程
• 渠道的关键指标及分析方法

关键指标指前期看有效用户数和次留，中期看7日、30日留存，后期看ROI，所有渠道的最终目的是商业变现，所以一定要计算每个渠道的ROI，及时把ROI小于1的渠道砍掉

分析方法包括结构分析，趋势分析，对比分析，作弊分析

• 结构分析：先按照一级渠道来拆解，再按照二级渠道来拆解
• 趋势分析：需要看每个渠道的变化趋势，包括量级和留存
• 对比分析：不同渠道间的趋势对比
• 作弊分析：包含用户行为分析和机器学习，这块可以用Python来完成

12.3 转化波动逻辑性分析

转化

1. 功能渗透率 = 功能用户数/大盘用户数（使用某功能用户在大盘的占比）
2. 功能的功能留存率：第一天使用该功能同时第二天也是用该功能的用户数/第一天使用该功能的用户数
3. 功能大盘留存率：第一天使用该功能同事第二天是大盘用户的用户数/第一天使用该功能用户数

价值

衡量功能的真正价值有三个指标：

1. 功能核心用户数：有多少用户是这个功能的核心用户，它的定义是符合某种要求的功能用户数，一般用使用次数、使用时长、使用天数、具备某种行为来定义”核心“

2. 功能对大盘贡献度，比如对大盘留存提升的共线

   功能A对大盘留存的提升共线=功能A渗透率*功能A的大盘留存率提升数

3. 功能带来的收入对比：每个功能每个月赚多少钱

• 产品的每一次决策都要基于逻辑性很强的数据证明

  “我觉得”这种词没有任何说服力，很容易被挑战，现有数据再有结论，不要先入为主

• 每个产品经理都有自己的内部指标

​ 必须去衡量你当前做的事情对大盘KPI的贡献度，只有大盘好才是真的好

• 实事求是，直面问题，持续改进

12.4 流量波动逻辑性分析

​ 留存波动包含新用户留存和老用户留存

​ 新用户留存与渠道和渠道过程有关

​ 老用户留存有两个影响因素：核心功能用户留存、非核心非功能用户留存

小结

• 渠道分析–渠道的整个过程和分析方法
• 功能模块价值分析–漏斗分析、功能常规指标和价值指标分析
• 流量波动逻辑性分析–一定要有逻辑，在过程非常严密的基础上得到正确的结果

十三.路径分析 ：用户的使用网络分析

定义

漏斗模型是非常经典的一种分析方法，但所有的漏斗都是认为假设的，也就是事前假设一天关键路径，事后看关键路径的转化数据

随着各类APP功能模块，坑位越来越多，用户的行为越来越分散化，比如很多APP不止有一个核心功能，可能有若干个核心功能，要在用户的所有操作行为中发现产品设计之初可能不知道、但非常有意思的用户前后行为–路径分析，路径分析师基于数据本身发现的，产品可能不太清楚，但是符合用户行为习惯

路径分析过程

日志介绍

路径分析实际上都是基于底层日志来做，用户在端内（APP内），所有的行为都是以表或者文件存储的，其中记录了用户最详细的行为信息，这就是日志

日志分析步骤

注意：实际上路径分析不难，但非常消耗体力，要每天去使用自己的APP，自己当做各类用户都要去体验自己的产品，因为用户在端内的任何行为都是合理的

路径分析思考

• 路径分析都是以功能点的时序整体分析为主，只有指标没有维度，而想要精细化运营，必须要进行维度拆分，如通过不同入口，通过桌面或是通过通知栏进来的用户，他们的路径分下差异在哪？这就是涉及做逻辑分析的时候要进行维度拆解
• 对于有些app，比如携程，小猪短租，用户可能在今天打开APP后逛了一下，然后就走了，过一周后再进来下单，对于这种用户一天不连续路径，如何进行分析呢？这是一个行业难题，没有很好地解决，无论是进行周期时间段的session分析，还是短期画像的分析，效果一般

十四.竞品分析 如何做竞品分析

为什么要做竞品分析？

• 当产品准备进入某个行业时，需要先报该行业的精品分析清楚，主要侧重行业规模和前景分析
• 当产品发展处于下降阶段，需要看竞品对手在做什么，主要侧重头部玩家的玩法分析
• 当产品发展处于瓶颈阶段，需要看竞品对手的数据和功能迭代，持续监控对手数据，从中找到突破
• 当产品发展处于快速上升期，一般不会做竞品分析

竞品分析包含两个点

• 竞品的选择：那些才是竞品？并不是所有头部行家都是你的竞品，而是根据你做竞品分析的目的来选择
• 分析什么点，这就需要你知道分析的背景是什么，从而有针对性切入

竞品分析的步骤

第一步：确定分析目的

分析目的分为以下几种情况：

• 当尝试将进入某个新的行业，需要评估可行性，这种竞品分析更加偏行业趋势，市场规模，财务收入，看大数不拘于小结
• 看精品的功能、玩法和数据，学习有点。主要以学习为主，这种分析目的比较常见，主要以功能体验、运营手法、具体数据为主，落地性非常强
• 通过看竞品的不同版本迭代功能、玩法和数据，揣摩竞品想什么，目的以预防为主看见竞品的版本迭代，思考竞品最近的战略中心在哪，这种情况往往是为了满足管理层的需要

第二步：挑选1-2家竞品，进行对比分析

首先挑选核心功能一样的1-2家产品，其次是功能体验分析，再就是运营手法分析，分析竞品的功能是怎么运用的，侧重对比运营手法，最后看宏观和微观的数据分析，也就是数据源，竞品数据源很关键，比如基础数据，财务数据，市场数据，这需要多部门合作完成

第三步：给初步分析结论

• 比如你常识进入某个新的行业需要评估可行性，那你最终的结论就是回答这个问题，是否可以进入，如果可以进入，步骤是什么
• 比如你纯粹看竞品的功能玩法和数据，学习有点，那最终的结论要落到竞品的什么功能好，接下来产品和运营如何去做，这样做与技能带来多少收益
• 比如只是看竞品不同版本迭代的数据，揣摩竞品想干什么，这种相对比较难

十五.营销活动 日常营销活动的分析模板

营销活动现状

数据分析人员优势—快和维度拆解性 劣势–细节性

• 分析的连贯性

  在活动前，活动中，活动后都要进行分析

• 分析的对比性

  不要单看活动本身，活动要与活动之间对比，这样才能更好分析什么样的活动更适合产品本身

• 分析的公正性

  该怎样就怎样，拉新、促活、品牌的判断都要应该有一套商定好的标准

营销活动具体分析

在做任何活动之前，活动运营方都花了很多心思，必然会出文案，找开发然后跟外面的合作方进行研讨，所有的这一切都会发生的很早，因此分析师想要做好分析，就要与活动运营方多沟通，知道活动整体

在活动前要准备好以下几件事：

• 活动前和运营方商定本次活动的目标
• 活动前和研发沟通好埋点
• 提前搭建好指标体系和报表
• 定好输出格式

活动中好好观察—期间每一天，包括预热

• 观察第一天的数据非常关键

  详细看指标体系的报表数据，查看是否有异常，因为前期修改成本非常小，对于负责人的研发也很乐意去解决这件事

• 观察1-3天数据

  预估活动目标的完成度，活动目标在前期一定是确定好的，这里要看是否要作适当调整

• 定时输出活动战报，每天早上输出，让所有人都知道情况

• 活动一周后数据复盘，1周之后进行一次详细复盘，并同步给管理层，让更高视野的人来给建议

十六. 用户增长 用户增长的本质是什么

用户增长模型

从拉新角度

AARRR模型出发角度是拉新，从这个角度是不断烧钱的，随着资本越来越理性，野蛮增长的时代过去了，不适用

从产品角度

先把产品打磨好，运营服务好，然后在留存的基础上进行变现，挣钱后再投入到渠道拉新，这样更加靠谱

首先考虑变现，产品能带来多少收入，净利润是多少，随着资本越来越理性，普遍会从流量思维切换到ROI思维

提示：

工作中很多做产品或者做数据分析时，都会看网上的模型，一直都在往一套模型上去套，最后效果也不是很好，建议不要纠结模型，不要指望通过数据分析突然找到一个很厉害的增长点，带来大量用户增长，有大腿坚决抱大腿

书籍

思维

北极星指标：一定要找到最核心的指标

做产品时，北极星指标一定要找对，找到后需对北极星指标进行拆解，拆解后的指标需要与每个团队的KPI挂钩，如果每个人都能够知道自己做的每件事是正向还是负向，那KPI完成程度就会很直观

A/B测试：目的是公正性和快速反馈性

A/B测试有两个原则：

1. 要基于数据分析来做A/B测试
2. A/B测试不只是看结果数据，还要看过程数据，排坑是第一步

建议

1. 不要玩概念，要独立思考和辩证性思维
2. 与其关注别人，不如多研究用户数据
3. 学习他人的优点，套用到自己身上来
4. 分析师要多看产品，运营的书，所有的分析增长都要靠产品、运营闭环
5. 只有成体系才是可传播的、可继承的

十七.问题定义和拆解 如何去定义问题、拆解问题

前言

在实际工作过程中，分析师经常会面对业务方的诸多需求，此时我们需要找到业务方的本质需求是什么，然后在此基础上按照逻辑树进行拆解

如何使用

• 先分享

  分享给别人后，别人会有不一样的理解、疑问、质疑和新想法，会增强你的认知程度

• 在使用

  每一课时的内容都只是我经历的一个沉淀，每个人都要结合自己的实际情况去使用，只有多和同伴交流，才能督促自己去对每个知识点进行更深入的理解

  开元知识分享，1加1大于2

• 使用方法

  截屏或分享链接，你要花更多时间去和同事探讨，并独立思考，自己也可总结笔记

问题拆解案例

问题识别

• 对方提了很多需求，问题有没有找到？
• 把问题拆解到第几层，大部分人拆解问题的深度不够
• 问题拆解到最后一层，去执行，而对于性格内向的人，找研发沟通这件事其次你做的好不好，效率高不高，这又是另一种能力的培养
• 掌握以上所有方法，同时在工作中发现别人问题所在，同时同事之间经常会有一些互相知道，当别人让你给一些指导时，你能够很好去用这些方法去帮助别人

问题识别方法论

二八定理的思考

遇到很多问题，其中比个主要问题，一旦这个问题解决了，其它问题也迎刃而解，所有问题一定会有破局点，当我们去跟业务方沟通，他们可能说了十个问题，那必然有一个主要问题，而这个主要问题就是你要去做的专题分析

先列出所有问题，自己头脑风暴，根据最大概率法则，一项一项来试，是否解决一个问题，其他都迎刃而解？如果真不会，请教leader

实际工作过程中，我把问题的拆解分为四步，这更加具有实操性：

1. 先快速按照你的理解去做拆解，不要管重复遗漏，能想到多少是多少
2. 拿着你的拆解去跟业务方（熟悉业务）的人对，请教—这代表业务方想法
3. 修改第一步的思维导图，做完后，请教你的leader–这代表你的leader在想
4. 再改一次，汇报给业务方leader–这个问题不会很大，否则就不是否定你一个人了

十八. 数据获取与分析：常见的SQL技巧和分析方法

数据获取前期准备

一般在正式写sql之前，要花一天时间做以下几件事情：

• 了解清楚业务方和研发说的是哪张表，哪份日志
• 了解这些表和日志的筛选条件是什么，为什么这么筛选
• 了解这些表和日志之前有什么坑，是不是哪天数据有缺失
• 验证现在是否有坑：select * ，先抛下核心数据看下

SQL提数常见问题

提数的最终目的是为了分析

sql提数看似很简单，但往往会因为其他事项而化比较长时间：

1. 被各种各样的其他事情打扰
2. 遇到一些坑需要思考
3. 突然找到一个新的点，就一直往下深挖
4. 自己本身不会提数和分析，不 知道如何看数据

解决办法

时间管理上具体可以给你以下建议：

• 早上时间一定要利用好，早点到公司，因为下午大部分都有会，会议的时间也不太好控制，所以早上时间一定要利用好
• 提前了解好会议主题，不要别人拉你去参加一个会，就直接去，发现这个会跟自己没啥关系，走也不好走，浪费了时间
• 中间所有进来的插队需求，先靠边站
• 利用工作之余时间多下功夫，专注去做事，一旦专注之后，其实别人也不太好意思打扰你
• 踩坑是必然的，要将踩的坑记录下来，防止后续持续踩坑
• 先不要纠结一个点，要将整体的模块做完

常用分析方法

• 对比分析
• 时间序列分析
• 相关性分析
• 机器学习
• 5W2H

总结

提数和分析完成之后，先不要急着写报告

要先把一些关键数据和初步结论同步给业务方核心人员，约个时间一起看下

目的是看他们怎么理解这个数据，有无明显问题，另一个是他们基于这些数据结论，准备怎么落地，需要他们提前想方案，在这个基础上再去撰写报告

十九. 报告撰写：专题报告的完美标准化格式

报告撰写有很多原则，掌握好这三个原则，基本没什么问题

1. 主题一脉相承分叉，只有一个主题，每页PPT都是围绕这个主题来分叉展开
2. 通俗简单移动：分析师的报告一定要简单易懂，文字要偏大白话
3. 结论和闭环先行，要有分析结论，且落地性强

主题一脉相承分叉

常见两种问题

• 专题报告没有主题

  通常报告中，这里写点，那里鞋垫。别人看是，别人觉得有问题，但也说不上来，如果你写报告没有主题，那肯定是因为你对专题报告的需求没有理解到位

• 专题报告有主题，但是写的逻辑有点乱，这是因为本身思维不够严谨，受到的指导太少

解决办法：看别人报告怎么写的，一页一页去斟酌

通俗简单易懂

数据分析师一定要让别人听明白你的报告，不管你是业务数据分析师，还是偏研发、偏算法的数据分析师，最终都是服务于业务，即使你不阐述PPT，也要保证业务方能看懂，否则就是给自己挖坑

一个数据分析专题报告，如果跟你最熟的业务方都理解不了，那对于其他人绝对是天书

解决办法：看产品经理日常怎么写报告

结论和闭环先行

PPT一定要有数据结论，以及在这个结论的基础上，业务方面怎么做，注意这里是真的准备怎么做，而不是你给的建议怎么做，数据分析用来决策而不是建议，确实很多人写专题报告还没有达到这个层面

**解决办法：**跟业务方多沟通数据结论，让他们给出落地项，而不是你建议怎么做

报告的组成部分

标准化的专题报告包含哪几个部分呢？

• 背景：为何要做这份专题报告，即问题的识别
• 分析结论：如果是面向管理层的汇报，结论可以先行
• 分析框架：即问题的拆解，往往这里不需要很细
• 第一个关键点结论
• 第一个关键点的支撑数据依次摆放
• 第二个关键点结论
• 第二个关键点的支撑数据依次摆放
• 整体结论：这里把结论再汇总依次
• 落地项：产品是怎么落地的，要非常具体（时间，人，预期效果）

二十. A/B测试

A/B测试：ab测试是为web或app界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析，评估出最好的版本，正式采用

流程

1. 根据数据分析的得到某建议项
2. 有了建议一项之后，产品经理直接就落地了吗？并没有，落地一般要通过A/B测试
3. 根据某落地项，研发和设计人员进行开发设计（往往是先设计，然后再丢到A/B测试平台里面跑数据局）
4. 研发人员数据采集，这一步现在基本都是自动采集数据，所以一般不用管
5. 分析师跟进A/B测试效果，当显著性在95%以上并且维持了一段时间，实验就可以结束

灰度

注意事项

站在数据分析的角度去看，A/B测试时要注意以下事项：

1. A/B两个组是否真的相同

2. 策略是否生效

3. A/B测试评估指标体系

4. 多观察几天数据

5. A/B测试的存档规划

二十一.行业分析：行业分析及框架分析

行业分析目标

行业分析两种背景：

• 当前公司准备进入某行业，需要分析师或者战略部门给出一份详细报告
• 当公司业务发展到瓶颈，需要分析师去验证当前市场对产品的需求有无变化

从背景来看，目标基本分为两种：

• 转型，希望通过行业分析看下公司转型到某个行业有没有切入点
• 用户需求整体的行业分析，比如看用户的需求还在不在

电商行业分析举例

• 背景

公司近期试水做电商业务，管理层知道很难做，但决策层又想找一些切入点，这时找战略部，希望战略部能给出一些建议，这种情况一般大家都是在摸着石头过河

行业分析的一般节奏：

​ 一周内快速出一些报告，拿着报告去和需求方沟通，这样可以避免一个月后做的专题分析不是对方想要的

​ 在于需求方对的基础上，把不确定的点剔除，把明确的点确定，然后将继续深挖

• 界定范围

从全局事业找切入点

• 市场规模

• 用户数描述

• 用户数分析

• 比较头部玩家

结论：

• 零售的本质还是多、快、好、省
  • 京东是物流快和好
  • 淘宝和天猫是多和好
  • 拼多多是省和供应链快（类似于沃尔玛）

未来预测：

通过界定范围，市场规模，热点事件以及头部玩家玩法，我们可以得出一下几点结论：

1. 当前对于电商这个领域，仍然有大量的用户还没有进入，还有非常大的增量空间，注意这里不是存量空间，是增量空间
2. 当前国内的网民数还真不是像大家想的那么多，未来厂商的争夺会更加激烈
3. 短视频是非常好的一个渠道，或者说入口
4. 当前国内在人均可支配收入上面不足，平均在2万元
5. 拼多多，因为它在用户的教育程度，各方面以及低于它的所见所识，相对来说都要比淘宝和京东差一点。所以未来在做面向该类群体做产品的时候，要结合该类用户的特征，比如说你的产品要尽量简单粗暴，让用户快速下单
6. 对于唯品会，未来拼多多对唯品会的威胁可能会大一点

推荐阅读：梁宁《产品思维30讲》

二十二.数仓 数据仓库的三种类型表

数据研发工程师和数据分析师的关系

APP日志采集中的埋点

日志的采集和传输里面具体的技术比较复杂，包括实时传输，批量传输

埋点前中期

数据分析师要主动参与到埋点的讨论，不要把前后端研发想的多专业，如果埋点出现问题，会非常耽误业务的分析，很多研发纯粹凭感觉埋点，在分析的时候发现有的点没有埋，或者埋错了，要重新进行一次埋点，这个活动很难分析出什么结论，浪费了彼此的时间

埋点后期

不要投入太多时间去想新的埋点，文档化即可，这样后面所有的人都可以参照文档，埋点虽然繁琐，但非常重要

数据建模步骤及举例

痛点

数据建模可以缓解这些痛点且有一下好处：

1. 提高整体计算效率，减少重复开发
2. 历史数据追踪，中间表数据可以存储一年
3. 更好适应业务发展，修改影响范围较小
4. 清晰数据结构，分析师更加容易理解

数据建模步骤

数据管理

数仓不要搞太复杂，很精细，一定要让业务倒逼，先把最核心的数据快速弄出来，如果把时间投入到这一块，肯定没有时间做分析师该做的事情—搞业务

数据分析师使用表时的注意事项

总结

1. 埋点的重要性：主动性和文档化
2. 数据建模的三层次：快速迭代
3. 数据的管理：权限管理

推荐书籍：《阿里巴巴大数据实战》

二十三.用户研究：用户研究和数据分析的根本联系和区别

什么是用户研究

项目前期

• 用户需求情况、用户基础画像情况、用户对于低价商品的迫切度
• 用户行为习惯
• 用户对产品的反馈点，竞品使用情况

用户研究的步骤和关键点

用户研究的注意事项

二十四 时间管理：优秀的数据分析师如何做时间管理

时间管理方法论