数据分析思维与实战（四）!

数据分析

• 1、如何解决临时题述需求
• 2、如何搞定BAT大厂的数据分析项目
  • 2.1 数据异常排查
• 3、怎样才能更好地转型或成功跳槽
  • 3.1 对上节课三个问题进行解答
  • 3.2 日常工作分析
  • 3.3 转型四步法
• 4、如何挑选适合项目场景的数据分析工具
  • 4.1 数据分析整体流程
  • 4.2 Excel常用操作
  • 4.3 SQL常用问题
  • 4.4 R语言以及python脚本案例
• 5、多元思维模型：数据分析需要具备的四大能力
  • 5.1 背景
  • 5.2 中观能力
  • 5.3 微观能力
  • 5.4 宏观能力
• 6、电商数据分析：京东App的详细产品分析
  • 6.1 如何看待京东App
  • 6.2 整体数据的分发效率
  • 6.3 漏斗分析
  • 6.4 新用户分析
• 7、互联网金融：芝麻信用分的建模过程是怎么样的
  • 7.1 背景
  • 7.2 授信模型
  • 7.3 模型落地
• 8、游戏：游戏行业的ROI和付费率是怎么算的
• 9、销售：传统行业如何做好交易额提升
• 10、指标体系搭建：指标体系的经典四步
  • 10.1 指标体系的定义以及选取原则
  • 10.2 建立指标体系的四个步骤
  • 10.3 知乎App指标体系实操
• 11、流量分析：如何分析数据波动
  • 11.1 背景
  • 11.2 渠道分析
    • 1.常见渠道及渠道分类
    • 2.渠道推广的整个过程
    • 3.渠道的关键指标及分析方法
  • 11.3 转化与价值分析
    • 1.漏斗分析
    • 2.功能模块分析
  • 11.4 流量波动逻辑性分析
    • 1.日活
    • 2.留存
• 12、路径分析：用户的使用路径网络分析
  • 12.1 路径分析定义
  • 12.2 路径分析案例——以美团APP为例
  • 12.3 路径分析思考
• 13、竞品分析：教你如何做竞品分析
• 14、营销活动：日常运营活动的分析模板
• 15、用户增长：用户增长的本质是什么
  • 15.1、用户增长模型
  • 15.2、国内用户增长现状
  • 15.3、增长案例解析
• 16、问题定义和拆解：如何去定义问题，拆解问题
• 17、数据获取和分析：常见的SQL技巧和分析方法
  • 17.1数据获取前期准备
  • 17.2 SQL提数常见问题
  • 17.3 常用的分析方法
    • 1.结构分析
    • 2.对比分析
    • 3.时间序列分析
    • 4.相关性分析
    • 5.机器学习
  • 17.4、总结:
• 18、报告撰写:专题报告的完美标准化格式
  • 18.1、报告撰写的原则
  • 18.2、报告的组成部分
  • 18.3、报告点评示例
• 19、A/B测试：AB测试的效果监控
  • 19.1、A/B测试介绍
    • 概念
    • 整体流程
    • 常见的两种A/B测试类型
  • 19.2、A/B测试注意事项
  • 19.3、A/B测试案例
• 20、行业分析：行业分析及框架分析
• 21、数仓：数据仓库的三种类型表
• 22、用户研究：用户研究和数据分析的根本联系和区别
• 23、时间管理：优秀的数据分析师如何做时间管理
• 24、结束语：数据分析师职场提升的关键点

16、问题定义和拆解：如何去定义问题，拆解问题

问题的基本结构

“问题”到底是什么？汉语的表述其实不太严谨。“问题”这个名词在我们生活中有很多种意思。比如：

• 这个数据有问题；
• 小明上班迟到了，因为路上出了点问题；
• 小明在网课上问了老师一个问题。

这几个句子中的“问题”表述的不是同一个概念。

在英语环境下相对来说更容易区分，你搜索“问题”的英文翻译，有很多种，比如：question、problem、trouble、fault、matter 等。刚才的句子里对应的英文意思大概是这样的。

• matter：这个数据有问题。
• trouble、problem：小明上班迟到了，因为路上出了点问题
• question：小明在网课上问了老师一个问题

当然这节课不是教你学英语的，我列举这些问题的解释是想先和你达成共识，避免我说的“问题”不是你理解的“问题”。比如：

• 业务问题，是业务上的某个 Problem/Trouble，你可以理解为业务上遇到的困难、困境、难题；
• 业务数据的分析问题（简称分析问题），是一个 Question，是一个问句。

这节课要解决的就是如何梳理业务数据分析问题，达成了共识，我们继续说梳理分析问题的框架。我认为提出一个完整的业务数据分析问题至少有两个部分：业务遇到的问题、分析的方向。

业务遇到的问题

业务遇到的问题一般就是**业务中现状和目标存在的差距，我们可以简称为业务问题。**我举几个数据分析中会遇到的场景做例子，看看什么是业务问题。

• 案例 1：“App 新用户数在持续下降”

这是不是一个业务问题？你可能会想，新用户数下降，这肯定算问题吧？新用户数少了，日活肯定会受影响，而且说明产品的健康度不行，长期下去肯定是不行的。

一般情况下，新用户确实越多越好，但是如果这款 App 已经准备停止运营了呢？这种情况不是没有，很多公司内部会展开赛马机制，在同一领域做很多同类型的 App，最后集中资源扶持其中最好的一款 App。如果新用户下降的 App 是被淘汰的那款，目前已经放弃运营，一周后会关闭。那么新用户少了就少了，无所谓。甚至我们还会希望新用户数越少越好，最好这些新用户都去另一款成功的 App 上。

你看，我们的目标变了，看起来很严重的问题反而变得无关紧要。差距不成立，问题本身就不存在了，所以一个问题必须要有目标。

• 案例 2：销售经理下达了本月的销售任务，每个销售员本月都必须完成 100 万的销售额。

这对于销售员小李来说，是不是一个问题？答案也是不一定。如果小李平时的销售额平均在每月 70 万左右，那么单月 100 万的销售额目标就是一个问题，所以小李必须想办法提升本月的销售额。那如果小李是金牌销售员，每个月随随便便就有 200 万的销售额，那达成 100 万销售额的目标就不是一个问题。

这个案例虽然有目标，但是没有说明现状，所以差距也不到一定成立，也就不一定是一个问题。

所以，业务问题至少要两个要素：**一个目标，以及和目标存在差距的现状。**如果把这两个案例转换成真正的问题将会是这样来描述。

1. 目标是 App 每天新用户数 10 万人，但现在只有每天 2 万人。现状的 2 万人和目标的 10 万人之间存在 8 万人的差距。
2. 目标是每月销售 100 万元，这个月预计只能完成 70 万。现状的 70 万和目标的 100 万之间相差 30 万。

上述的两个差距就是我们要解决的业务问题了，如果目标和现状之间没有差距，也就没有业务问题了。没有要解决的问题，也就没必要提出分析需求。

这里我也要提示你，在找出业务问题的阶段容易犯这么几种错误。

错误 1：把直觉当成了事实

我们一听到新用户下降，很自然地会认为这是一个问题。因为我们内心预设了一个标准，觉得考试那至少得及格，新用户那肯定是越多越好。不过这只是我们的预设立场，是我们过去的经验，不代表当下的事实。分析师的要求是严谨客观，所有的结论都要经得起逻辑的推敲。你直接预设一个立场，而不是依靠事实推理，就犯了主观判断的错误了。

错误 2：目标不是业务指标

我们的目标和现状都必须是一个业务指标。比如留存率、新用户数、转化率等等。当我们发现留存率没有达到目标，我们可以说这是一个业务问题。你不能说我的目标是想要知道某个数据，现状是没有数据，那这就变成取数需求了。我们要解决的是业务问题，不是业务方的问题。

错误 3 ：目标和现状没有对应关系

另一个容易犯的错误就是目标和现状两者的指标不一致，没有对应关系。比如说，这样一个问题：“这个月要从外部获取 10 万的新用户，但这个月只有 10 万元的推广费用，怎么办？”

我们平时的表达很多都是这样的形式，这个问题虽然符合问题的基本结构，并且我相信大家能大概看懂是什么意思，但是这个问题的目标和现状的指标不直接相关。因为目标是获取新用户，而现状是推广费用。这两者中间还相差了一层逻辑，费用和新用户的关系是什么。

如果按照目标来解读，提问者实际想要表达的是：这个月要从外部获取 10 万的新用户，现有的推广资金预计只能达成 3 万新用户，怎么办？

如果按照现状来解读，也可以表达成：要达成获客目标需要 30 万的推广费用，这个月只有 10 万元的推广费用，怎么办？目标和现状的不匹配，会让问题变得模糊。

业务问题是引发我们提出分析问题的原因，但只有业务问题还不够完整。既然是问题，你总得“问”吧？即问题的第二个要素——分析的方向。

分析的方向

接下去我们要确定分析的方向，分析方向也就是你想要从哪些角度分析这个问题。

我们可以从很多维度分析一个业务问题，比如“哪些人”“什么时候”“是什么”“是多少”“为什么”“会怎样”“怎么办”等。

比如现在的业务问题是广告拉新的效果一直不及预期目标，对此你提出了这样一些分析方向。

• 问题 1：有哪些好的广告拉新渠道？
• 问题 2：有哪些拉新效果好的广告形式？
• 问题 3：什么时段的广告投放效果比较好？

你还可以问其他的问题，比如拉新广告文案怎么写？拉新用户的男女比例分布怎么样？是不是三四线城市的点击率更高？等等。

虽然这些问题的结构都是完整的，有业务问题，也有分析方向。不过这不是一个好的业务数据分析问题，因为问题本身往往意味着答案。

上面这些问题都会限制分析问题的方向，我们来看一下。

• 问题 1：有哪些好的广告拉新渠道？

这个问题的答案是找到一些效果更好的渠道，然后在这个渠道上投放广告。

• 问题 2：有哪些拉新效果好的广告形式？

这个问题的答案就变成如何优化拉新的广告形式。

• 问题 3：什么时段的广告投放效果比较好？

这个问题的答案是找出投放效果好的时段，然后将资源倾斜到这些时段。

如果我们问的问题不正确的话，那答案也肯定不能解决业务问题。如果我们提出问题的目的是解决业务问题，那我们为什么不直接问“怎么办”呢。比如“广告拉新的效果一直不及预期目标，怎么办？”这个问题没有太多的限制，分析方向就很自由了。

• 我们可以从投放的渠道分析：目前哪个渠道效果好？还有哪些类似的渠道？
• 我们可以从广告优化分析：广告的文案怎么改？广告的素材怎么改？广告的形式怎么改？
• 我们还可以从拉新成功的用户分析，看一下这些用户的特点是什么，如何触达同类型的其他人？

只问“怎么办”，我们的分析方向就会足够多，就很容易找到问题的突破口。所以这是一个强大的问题公式：业务现状+怎么办。

如果你之前经常觉得自己分析的时候没思路，有可能不是你的问题，而是提问者的问题。不过我们没办法要求提问的人都得学会这个方法，但至少你下次遇到类似问题的时候用问题公式这么改造一下，说不定思路一下子就打开了。

由于业务问题中的目标和现状的指标是对应的，并且“怎么办”这个分析方向是固定的，所以我们接下来要做的就是确定业务问题的指标。

确定业务问题的指标

我们可以根据指标的口径找到数据即可，所以这里我们可以分为两个步骤：确定指标、确定数据。

（1）确认指标

业务方提出的需求，往往是比较模糊的，比如“如何提升某功能新用户的人均使用次数”这个需求。这个问题中的要提升的指标是“某功能新用户的人均使用次数”，这个指标名字一听就很长，维度很多，我们需要先确认一下这个指标到底能不能用。

确认指标的过程，我们常常会遇到这样三类问题。

• 指标不合理

我们制定的指标可能并不能很好地衡量我们的业务。案例里是想提升某功能的新用户的人均使用次数，那么为什么要用这个指标呢？如果是想衡量新用户对功能的忠诚度，用留存率是不是会更好呢？这个问题必须搞清楚，如果这个指标制定得不合理，那么后续的分析的基础就崩塌了，分析地再深入也没有意义。

• 指标的口径不一致

指标的口径问题是一个做数据分析特别常见的问题。大家都在聊同一个指标，但可能每个人对这个指标的理解都不一样。

案例中的目标指标是某功能的新用户人均使用次数 5 次，这个里面有太多的口径需要确认了。比如新用户的口径。这可能是每个公司里面最混乱的一个口径了。我就遇到过在同一个业务线，新用户这个口径就有四、五种不同的理解。还有使用某功能，是按照进入页面算使用呢？还是必须完成一个特定动作算使用？人均使用次数是按平均数算还是中位数算？

这些口径必须提前确定清楚，只有大家把口径都统一了，后续的分析才能够继续。

• 数据获取问题

由于数据采集的问题，不是所有的指标都能够获取到。有时候我们确定了口径，但是这个指标没办法获取到，那我们就只能用其他的指标来替代。

（2）确认数据

解决了以上的指标选择与口径的问题，第二步就可以确认每一个指标的具体数据了。

业务方提的需求往往比较主观，他只会告诉你，目标是提升某功能新用户的人均使用次数。那么到底提升到多少呢？这个目标一般业务人员自己是清楚的，因为业务部门在每个季度或者每个月都会制定一个业务目标。所以你可以与业务方沟通，直接拿来用就行。

如果业务部门没有具体的目标，那我们可以根据历史的数据趋势推断出来，或者拿历史的较大值出来做目标。而现状就比较好办了，只要口径是确定的，那么从数据库中获取这个数据就可以了。

经过数据分析师的改造，这个问题就变得非常清晰了。

目标：使用某功能的新用户的人均使用次数 5 次

现状：目前人均使用次数 3 次

分析方向：怎么办？

结语

一个完整的业务数据分析问题包括两个部分：业务遇到的问题和分析的方向，它是我们梳理问题逻辑时必须掌握的知识。了解问题的结构，我们就能将错综复杂的问题，用逻辑清晰的方式提炼出其本质，这对于我们理解业务、指导后续分析方向都有着非常重要的作用。

17、数据获取和分析：常见的SQL技巧和分析方法

17.1数据获取前期准备

一般在正式写SQL之前，要花1天时间做以下几件事：
1、了解清楚业务方和研发说的是哪张表、哪份日志
2、了解这些表和日志的筛选条件是什么，为什么要这么筛选
3、了解这些表和日志之前有什么坑，是不是哪天数据有缺失
4、验证现在是否有坑：select*,先跑一个核心数据看下

SQL提数常见问题
提数的最终目的就是为了分析
SQL提数看似很简单，但往往会因为其他事项而比较花时间：
1、被各种各样的其他事情打扰
2、遇到一些坑需要思考
3、突然找到一个新的点，就一直往下深挖
4、自己本身不会提数和分析，不知道如何看数据

时间管理上具体可以给你以下建议：
1、早上时间一定要利用好，早点到公司
因为下午大部分都有会，会议的时间也不太好控制，所以早上时间一定要利用好
2、提前了解好会议主题，不要别人拉你去参加一个会，你傻乎乎的直接去了 到了之后发现这个会议好像跟你没啥关系，然后走也不太好走，所以一定要先确定是否必须参加
3、中间所有进来的插队需求，先靠边站
4、利用晚上回家时间、周末时间在这件事上多下功夫，专注去做事
一旦专注之后，其实别人也不太好意思打扰你
踩坑之后，要总结，观人阅事

17.2 SQL提数常见问题

如果突然找到一个新的点，或者说突然很纠结某个点
一定要跳出小的圈子，最重要的事情是先把问题的拆解模块做完

1、先聚合再计算
如果要计算某个维度下的用数，不要直接icount (distinct imei)
而是Select city. count (1) as uv from( select city. imei. count( 1) from a group by city imei) group by city
2、一列变多行
Ab测试中会对一个用户打很多标签，而这些标签都是存在一个字段中，所以要看标签维度指标，就要对该字段进行列变行拆解
Select , b from tl Lateral view explode (a) table as b
3、取TOP
要看某分类下的top10消费額子分类（金額一致就并列）
Select, rank () over (partition by a order by b desc) as rank from table tl

17.3 常用的分析方法

1.结构分析

2.对比分析

所有的数据只有对比才有意义
实际工作中，最常见的对比对象就是大盘，比如新上线一个功能，怎么样评估这个功能效果？
除了看功能使用人数，更加要做的是这个功能的留存和大盘的留存对比。

3.时间序列分析

一般看某指标时，都会把时序周期拉长，看数据趋势，而数据都是波动的，所以都会进行拆解分析，寻找具体波动项

4.相关性分析

5.机器学习

17.4、总结:

Who:指用户基础属性、用户画像
Where :渠道分析，渠道入口，用户从哪里来
when时间上的特征
What:用户使用了什么功能，哪些行为更加重要
Why:为什么要这么做，用户是主动还是被动做的
How:怎么做的，行为路径是什么

提数和分析完成之后，不要急着写报告
要先把一些关键数据和初步结论同步给业务方核心人员，约个时间一起看下 目的是看他们怎么理解这个数据，有无明显问题
另一个是他们基于这些数据结论，准备怎么落地，需要他们提前想方案
在这个基础上，再去撰写报告。

18、报告撰写:专题报告的完美标准化格式

18.1、报告撰写的原则

报告撰写有很多原则，但这三个原则，如果你把握好了，基本上没什么问题
1.主题一脉相承分叉：只有一个主题，每页PPT都是围绕这个主题来分叉展开
2.通俗简单易懂：数据分析师的报告一定要简单易懂，文字要偏大白话
3.结论和闭环先行：要有分析结论，且落地性强

主题一脉相承分叉
常见两种问题
1、专题报告没有主题
通常在报告中，这里写点，那里写点。给别人看时，别人觉得有问题，但也说不上来 如果你写的报告没有主题，那肯定是因为你对专题报告的需求没理解到位
2、专题报告有主题，但是写的逻辑有点乱，这是因为本身思维不够严谨，受到的指导太少
解决办法：看别人报告是怎么写的，一页一页去斟酌

通俗简单易懂
数据分析师一定要让别人听明白你的报告
不管你是业务数据分析师，还是偏研发、偏算法的数据分析师，最终都是服务于业务 即使你不阐述PPT,也要保证业务方能看懂，否则就是给自己挖坑
一个数据分析专题报告，如果跟你最熟的业务方都理解不了，那对于其他人来说绝对是天书
解决办法：看产品经理日常怎么写报告

结论和闭环先行
PPT一定要有数据结论，以及在这个结论的基础上，业务方准备怎么做
注意这里是真的准备怎么做，而不是你给的建议怎么做
数据分析用来决策而不是建议，确实很多人写专题报告还没有达到这层面
解决办法：跟业务方多沟通数据结论，让他们给出落地项，而不是你建议怎么做

18.2、报告的组成部分

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

如何衡量专题报告的价值。
在所有的数据结论和落地项当中，只要最后有1-2真正落地了，就非常有含金量。

18.3、报告点评示例

应该遵循结论和闭环先行原则：
基于什么数据
发现什么结论
基于这个结论的建议是什么
基于这个建议的产品落地项是什么

对于如何写好专题报告
建议你平时多看优秀的专题报告，重点是把自己带入到场景中 比如推给你一篇文章，你看的时候一定要把自己带入到场景当中去思考 思考文章作者说的到底有没有道理，思考作者的见解，文章的架构
每写一次专题分析，一定要获得他人的反馈

19、A/B测试：AB测试的效果监控

19.1、A/B测试介绍

概念

整体流程

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

整体节奏要按照灰度、5%、10%、20%、50%、100%来控制
灰度通俗讲就是小版本
比如一个千万量级的Apple ,灰度代表5~10w这样的一个水平

常见的两种A/B测试类型

实际工作中的问题
严格模式下，所有的专题报告落地项（除了明显的Bug修复和明显的用户体验）都要靠A/B测试展开
举个例子：
2个月前，产品上线了短视频功能
2个月后，大盘略涨（之前是略跌趋势）
短视频和非短视频的数据增加也明显
现在短视频业务方希望分析师能量化出——大盘的上涨主要是因为短视频带来的

19.2、A/B测试注意事项

站在数据分析师的角度去看，A/B测试时要注意以下事项：
1.A/B两个组是否真的相同
2.策略是否生效
3.A/B测试评估指标体系
4.多观察几天数据
5.A/B测试的存档规划——方便后续找增长点

站在数据分析师的角度去看，A/B测试时要注意以下事项：
1.A/B两个组是否真的相同
A:001 00 2003 004 005
B:001 002 003 004
C:001 002 003 004 006
D:X Y 001 002 003 004
A、B、C可做A/B测试
2.策略是否生效
工作中常见这种现象，产品经理根据分析师的专题报告落地项，然后进行某个A/B测试，研发也进行了A/B测试，最后发现效果不明显 此时所有人都觉得X优化项没用，也就没有多去做更多尝试。
数据分析师要对X进行测试，有没有明显问题。
3、A/B测试评估指标体系

4、多观察几天数据（4-10天）

5、A/B测试存档

19.3、A/B测试案例

海报案例——不同地区爱点击的海报不同
广告位放哪更适合用户体验

案例思考
A/B测试涉及到设计师、产品经理、数据分析师三方
设计师：一定跳出传统的设计思维，在这个基础上，要多去看一些A/B测试增长黑客的书
产品经理：光凭直觉是不靠谱的，A/B猜测的闭环能够让我们去更好地理解用户
数据分析师：大多数改动都不会带来大幅效果的提升，A/B测试的效果往往都是略好，所以要持续迭代。如果出来上涨30%，观察是否数据出现错误。

学习资料见知识星球。

以上就是今天要分享的技巧，你学会了吗？若有什么问题，欢迎在下方留言。

快来试试吧，小琥 my21ke007。获取 1000个免费 Excel模板福利​​​​！

更多技巧， www.excelbook.cn

欢迎 加入 零售创新 知识星球，知识星球主要以数据分析、报告分享、数据工具讨论为主；