数据分析从零到精通第四课在产品需求、开发、运营和迭代中进行数据分析

最新推荐文章于 2024-09-14 10:35:19 发布

办公模板库素材蛙

最新推荐文章于 2024-09-14 10:35:19 发布

阅读量1.2k

点赞数

分类专栏：数据分析教程文章标签：数据分析 HIve Mysql OKR

教程同时被 2 个专栏收录

1193 篇文章 258 订阅

订阅专栏

数据分析

44 篇文章 23 订阅

订阅专栏

08 数据平台：本机部署大数据平台工具及使用

你好，我是取经儿。上一课时我带你学习了快速搭建 BI 平台来构建报表。本课时我将手把手教你在本地电脑安装离线大数据处理工具 Hive。Hive 也是数据分析师最常使用的工具。在本机部署Hive ，可以帮助没有数据工作经验的同学快速上手。而对于已经参加工作的数据分析师来讲，本地 Hive 在语法的测试验证方面也会更方便快速。

下面我们讲下如何在本地 Linux 或者 MacOS 安装 Hive。

Hive 安装流程

Linux 或 MacOS 安装 Hive主要依赖以下环境：

Java；
Hadoop；
MySQL；
MySQL-Connector。

首先 Hive 是 Hadoop 生态系统数据仓库工具。Hive 运行依赖 Java 环境，属于 Hadoop 重要组件。同时，Hive 元数据一般使用 MySQL 来存储，所以在安装 Hive 之前需要先安装 Java、Hadoop、MySQL 。

注意：本课时涉及安装下载的软件，为了方便，我会为你提供两种方式下载。第一种是官网下载链接；第二种是我出于速度考虑，特意帮你准备的百度网盘下载链接。

下面我们一步一步部署本机安装 Hive 所需要的环境。

第一步：安装 JDK。

先检查本机是否安装 Java。使用下面命令，如果显示 Java 版本在 1.8 以上，即可继续第二步安装。

workindata:local qujinger$ java -version
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)

如果本机未安装 Java，则按下面步骤先安装 Java。

1.下载 JDK。

方式一：JDK 官网下载。
方式二：JDK 百度网盘（密码：okb7）。

2.解压JDK并将解压文件夹移动到 /usr/local。

tar -xvf jdk-8u161-linux-x64.tar.gz -C /usr/local

3.配置环境变量。

# 输入下面命令, 打开.bashrc 文件
vim ~/.bashrc
# 在文件.bashrc 中添加下面代码
# 配置 JAVA 环境
export JAVA_HOME=/usr/local/Java/jdk1.8.0_181/
export JRE_HOME=$JAVA_HOME/jre
export PATH=$JAVA_HOME/bin:$JRE_HOME/bin:$PATH
export CLASSPATH=$JAVA_HOME/lib:$JRE_HOME/lib:.
# 保存.bashrc 后退出, 然后用下面命令生效配置
source ~/.bashrc

4.测试 Java 环境生效。

# 测试 Java 安装命令，如下，命令行输入代码: java -version
workindata:local qujinger$ java -version
java version "1.8.0_261"
Java(TM) SE Runtime Environment (build 1.8.0_261-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.261-b12, mixed mode)

以上过程后，本机便顺利安装上了 Java 环境，下面我们来安装 Hadoop。

第二步：安装 Hadoop。

Hive 运行依赖于 Hadoop 工作环境，所以需要先在本机搭建 Hadoop 环境，以下是介绍如何在本机上搭建 Hadoop 环境。

首先，下载 Hadoop，并解压到/usr/local路径里。

方式一：Hadoop官网下载（选择 Binary 文件进行下载）。
方式二：百度网盘（密码：okb7）。

sudo tar -zxf ./hadoop-3.2.1.tar.gz -C /usr/local

1.设置环境变量。

# 输入下面命令, 打开.bashrc文件
vim ~/.bashrc
# 添加如下代码
export HADOOP_HOME=/usr/local/hadoop
export PATH=$PATH:/usr/local/hadoop/bin
export PATH=$PATH:/usr/local/hadoop/sbin
# 保存.bashrc后退出, 然后用下面命令生效配置
source ~/.bashrc

2.检测 Hadoop 安装状态。

workindata:local qujinger$ hadoop version
Hadoop 3.2.1
Source code repository https://gitbox.apache.org/repos/asf/hadoop.git -r b3cbbb467e22ea829b3808f4b7b01d07e0bf3842
Compiled by rohithsharmaks on 2019-09-10T15:56Z
Compiled with protoc 2.5.0
From source with checksum 776eaf9eee9c0ffc370bcbc1888737
This command was run using /usr/local/hadoop/share/hadoop/common/hadoop-common-3.2.1.jar

以上为安装 Hadoop 步骤。在 Hadoop 配置完成后，下一步安装 MySQL，用于 Hive 元数据管理。

第三步：安装 MySQL。

在 CentOS 系统中安装 MySQL，安装步骤可以参考 07 课时《07 一小时搭建可视化 BI 数据平台》，我在那一课时中介绍了为 CentOS 系统安装 MySQL 的步骤。

在 MacOS 系统中安装 MySQL，则要先下载安装包。

方式一：官网下载（选择 DMG 格式下载）。
方式二：百度网盘（密码：okb7）。

下载完后需要进行安装。这时候，按照提示一步步安装即可：

image (1).png

注意：MacOS 安装 MySQL 完成后要启动 MySQL。以下是 MacOS 系统启动、停止、重启 MySQL 服务的命令。

# 启动 MySQL 服务
sudo /usr/local/MySQL/support-files/mysql.server start
# 停止 MySQL 服务
sudo /usr/local/mysql/support-files/mysql.server stop
# 重启 MySQL 服务
sudo /usr/local/mysql/support-files/mysql.server restart

安装完成后，我们需要在 MySQL 创建新用户。新用户的用户名和密码都设置为 Hive。操作命令如下：

# Root 账户登录 MySQL
mysql -uroot -p 
# 新增用户
mysql> create user 'hive'@'%' identified by 'hive';
mysql> grant all on *.* to hive@localhost identified by 'hive';   
# 后面的 hive 是配置 hive-site.xml 中配置的连接密码
mysql> flush privileges;  
# 刷新权限

第四步：下载 Hive 安装软件。

方式一：官网下载。
方式二：百度网盘（密码：fvfk）。

解压 Hive 安装包并移动到 /usr/local 中即可。

sudo tar -zxvf ./apache-hive-3.1.2-bin.tar.gz 
sudo mv apache-hive-3.1.2-bin /usr/local/  -- copy到/usr/local目录
sudo mv apache-hive-3.1.2-bin hive       # 将文件夹名改为 hive

第五步：配置环境变量。

# 输入下面命令，打开.bashrc 文件
vim ~/.bashrc
# 添加如下代码
# Hive 环境变量
export HIVE_HOME=/usr/local/hive
export PATH=$PATH:$HIVE_HOME/bin
export HADOOP_HOME=/usr/local/hadoop
# 保存.bashrc 后退出，然后用下面命令生效配置
source ~/.bashrc

第六步：下载 mysql-connector-java.jar。

方式一：官网下载。
方式二：百度网盘（密码：8s0s）。

下面将下载的jar文件Copy到路径/usr/local/hive/lib 中。

cp mysql-connector-java-8.0.21.jar /usr/local/hive/lib

第七步：启动 Hive。

# 启动 Hive 前，先启动 Hadoop
$ start-dfs.sh
$ $ hive
SLF4J: Class path contains multiple SLF4J bindings.
...
...
Logging initialized using configuration ...
Loading class `com.mysql.jdbc.Driver'. ...
Hive Session ID = fbeb3b3b-23d6-41e0-bbd2-8563f623ed29
Hive-on-MR is deprecated in Hive 2 and ...
hive>

启动 Hive 的过程中，可能遇到一些问题。经哥将这些问题和解决方法进行了汇总。感兴趣的同学可以去下面的链接看一看：
解决 Hive 启动报错：java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkArgument。

这通常是因为 Hive 内依赖的 guava.jar 和 Hadoop 内依赖的 guava.jar 版本不一致造成的。

 # 查看 Hadoop guava.jar 版本命令，发现版本：guava-27.0-jre.jar
ll /usr/local/hadoop/share/hadoop/common/lib | grep guava
-rw-r--r--@ 1 1001  1001  2747878  9 10  2019 guava-27.0-jre.jar
# Hive 中 guava 版本低
ll /usr/local/hive/lib | grep guava
-rw-r--r--@ 1 qujinger  staff   2308517  9 27  2018 guava-19.0.jar
# 解决方法：
# 将 Hadoop 中高版本 guava 包，cp 到 Hive 路径下, 并删除 Hive 路径下低版本包: 
cp /usr/local/hadoop/share/hadoop/common/lib/guava-27.0-jre.jar /usr/local/hive/lib/
rm /usr/local/hive/lib/guava-19.0.jar

解决 Hive 启动报错：metadata.SessionHiveMetaStoreClient，参考 stackoverflow 网站一个解决方法。

 # 由于我们使用 MySQL 管理 Hive 元数据库, 我们需要初始化下:
 $ cd /usr/local/hive/bin
 $ ./schematool -dbType mysql -initSchema  
 $ ./schematool -dbType mysql -info
 # 再运行 Hive, 并执行 show databases 命令就没有问题了

Hive 创建数据库报错：Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask。

# Hive 运行：create database tmp_db2; 报错如下：
hive> create database tmp_db2;
FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. MetaException(message:Unable to create database path file:/user/hive/warehouse/tmp_db2.db, failed to create database tmp_db2)

# 在 Hadoop 中创建 Hive 所需的仓库：
hadoop fs -mkdir -p /user/hive/warehouse
# 将/user 路径及其子路径授权给当前登录用户。比如我当前登录用户名为：qujinger, 则运行下面命令：
sudo chown -R qujinger:wheel /user
# 设置完 Hive 本地仓库以及授权后, 再运行 Hive 创建数据库命令, 执行正常
hive> create database tmp_db2;
OK
Time taken: 0.333 seconds
hive> show databases;
OK
default
tmp_db2
Time taken: 0.513 seconds, Fetched: 2 row(s)

第八步：创建本地 Hive 外表。

由于是本机安装，因此我们没有真正分布式的 HDFS 文件，这时候需要根据本地文件来制定Hive 外表。

# 测试数据在本地/tmp/test_data.txt, 我们查看前 3 行：
cat /tmp/test_data.txt |head -3
2019/10/1	1	51
2019/10/2	2	49
2019/10/3	3	50

这里需要使用 Hadoop 命令 HDFS 来创建目录以及将测试数据 Copy 到指定路径，用于生成 Hive 外表。注意：必须使用 Hadoop 命令进行，如果使用本地 Shell 命令 Copy 数据，无法完成表创建和使用。

$ hdfs dfs -mkdir -p /usr/local/hive/tmp_db/order_info   # 创建临时数据库
$ hdfs dfs -cp /tmp/test_data2 /usr/local/hive/tmp_db/order_info
# 根据本地文件创建外表使用：
hive> CREATE EXTERNAL TABLE order_info (dt string, id int, order_num int)
    > COMMENT 'user orders'
    > ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t'
    > STORED AS TEXTFILE
    > LOCATION '/usr/local/hive/tmp_db/order_info';
OK
Time taken: 0.086 seconds

第九步：本地 Hive 进行基础统计。

下面我们就可以利用本机安装的 Hive 进行数据统计了。你可以尝试统计上面新建表的数据，比如：统计表格中的每月订单量。

# 设置运行结果, 同时输出字段名称
hive> set hive.cli.print.header=true;
# 运行 SQL, 统计每月订单总和, 单天最小订单量和最大订单量
hive> select split(dt, '/')[1] as dt, sum(order_num) order_num, min(order_num) as min_order_num, max(order_num) as max_order_num from order_info group by split(dt, '/')[1] order by dt;
Query ID = qujinger_20201018120317_c81beb8f-8c55-4869-aa75-9d510026a1b3
Total jobs = 2
Launching Job 1 out of 2
Number of reduce tasks not specified. Estimated from input data size: 1
...
...
2020-10-18 12:03:20,995 Stage-2 map = 100%,  reduce = 100%
Ended Job = job_local183869176_0006
...
Total MapReduce CPU Time Spent: 0 msec
OK
dt	order_num	min_order_num	max_order_num
10	2091	45	90
11	2189	57	98
Time taken: 3.226 seconds, Fetched: 2 row(s)

经过以上步骤，想必你已经在本机成功安装了 Hive。现在，你可以在本地创建数据库和表格，并对其进行基础统计，从而进行练习，加深学习效果。在这个过程中，你也可以及对 Hive 基础语法、函数进行学习和巩固练习了。

总结

09 贯通业务：处理临时需求的正确姿势

你好，我是取经儿。之前第一部分的八节课我们主要讲的是数据处理技术相关的内容，我们这节课开始第二部分的学习：数据分析师如何进行业务分析。

当你历经艰难，终于成为一名数据分析师。在你开启数据分析师职业生涯的第一个阶段，首先要面对的就是处理业务方的提数需求。这里说的"提数"，是指从当前数据仓库中通过 SQL 提取业务方想要的数据指标的过程。目前，提数既是数据分析师了解业务最好最快的方式，却也令很多数据分析师深陷其中、无法抽身，让人倍感苦恼。

我们之所以苦恼是因为以下原因：

提数的苦恼

1. 提数需求个性化、一次性，自我提升有限。

提数需求往往是个性化的，一次性的。每次提数会占用你不少工作时间，但数据用完后却不一定有复用性。

产品一般提出的需求有：

数据异常排查，进行产品上线前后归因；
新老版本产品，用户使用情况数据对比；
不同画像用户（性别、年龄等）对某功能使用渗透情况、功能留存等；
不同产品的数据报表需求，监控产品数据情况。

运营一般提出的需求有：

某客户或某单品历史交易数据（电商行业）；
重大节日活动效果数据；
根据自定义规则，选取优质商家用于某种营销；
根据自定义规则，选取不同类型用户开展活动，例如召回流失、发放优惠券激励用户购买转化等。

这些需求，很多是阶段性的需求，复用性并不强，对于自我提升并不能直接产生太多收益。

2. 精力有限，临时提数需求会打乱专项分析的节奏。

一般公司产品同学和运营同学，尤其运营同学，数量非常多。相对而言，数据同学就显得人数较少了。这时候每个业务同学一周提出两三个需求，就可能将数据分析师的时间占满。

有意思的是，你会发现每个同学都会火急火燎地对你说，这个需求特别紧急还特别重要。恨不得马上拿到数据！但是往往数据分析师可能还在同时进行专题分析。如果这时候你放下手头的专项分析，处理这些临时提数需求，会打断我们原本正在进行中的分析节奏，降低效率。而且，最让我们沮丧的是，这些临时提数需求可能并没有那么紧急。

3. 提数属于日常业务支持，很难有大的工作产出，说白了就是年终汇报基本体现不出来。

如果你的工作重点是提数。那么很快，你在公司的角色会变成一个提数机器。从你的工作中，领导看不出你作为数据分析师的分析能力、看不到你对业务的推动作用。其实不只是领导，我们自己也不愿意看到在年底总结时，我们只能说自己“承接了 xxx 个提数需求”。我们似乎变成了一个 SQL boy或者 SQL girl。这体现不出来我们作为数据分析师的价值，容易自我沮丧，也让我们的年终汇报变得非常尴尬。

想要发挥数据分析师的价值，我们需要采用正确的方式来处理源源不断的提数需求。下面我们开始讲下处理临需的方法。

如何正确地处理提数需求

1. 摆正心态，提数之前先了解业务目的，再动手。

虽然提数需求会给我们带来诸多苦恼，但是我们也必须承认它是有价值的。提数可以帮助我们熟悉业务、了解业务最新进展，并帮我们与业务同学建立良好的信任关系。尤其是新入职的数据分析师，很多人是通过提数需求来循序渐进熟悉业务的。

提数能够帮助你快速熟悉数据仓库数据表和字段的含义，了解核心业务指标含义以及生产的过程。方便以后自己进行业务异常定位和数据挖掘。一般互联网公司的数据表数量很庞大，字段很多。而且很可能在未来随着业务变化而不断更新。如果你对数据仓库里的数据表不太熟悉，就很难赋能业务了。这个时候，我们要观察产品和运营方的提数需求。因为通常情况下，产品和运营等业务方向你索要的数据，大概率也是业务中比较重要的部分。通过完成提数需求，我们对于公司核心业务的数据存放地点会更加熟悉。
数据分析师的计算机技能是通用的，但是不同公司的业务逻辑是不同的。尤其是换工作的同学，可以通过提数需求，多跟业务同学沟通，借机多多学习、熟悉业务。比如，对于电商公司来说，公司的核心业务是交易。你需要重点了解的可能是，如何对商品和买家进行匹配，从而达成最大化成交？如何提高用户购物体验，从而带来平台收益？如何策划不同电商节日的促销活动，来推广销售，获取利润？比如，对于短视频公司来说，公司的核心业务则是作者拍视频、用户观看视频。你需要重点了解的可能是，如何提升作者拍视频的意愿，为平台提供更多的内容？如何激励作者拍出质量更好的视频，提升平台内容的质感？如何帮助用户找到最感兴趣的视频，提升用户在平台的使用时长，为公司商业变现创造更大的空间？

不同业务方的提数需求，都是在帮数据分析师提供不同的视角来了解公司业务、运转现状。所以，它是有价值的，我们需要先摆正心态。

2. 数据需求规范化、流程化。

数据需求规范化。完整的需求，需要业务方告诉我们，项目背景、数据指标、数据口径、数据周期、数据目的等。这个至少有两点好处：

降低沟通成本，不需要来回确认提数的目的和指标；
帮助提需求的同学，自己先梳理逻辑，从而确定所需求的数据能解决问题，避免无效数据需求浪费时间。

按照这种规范化的提需要求，往往能降低数据的需求量。因为流程本身增加了业务方提需求的成本，帮助业务方进行了自我筛查。对于真正希望看到数据的业务方，他一定会认真按流程执行，而对于那些本身问题没想清楚，随便看看数据的同学，可能就放弃了。

所以流程化，本身能过滤掉一些低价值的业务需求，保留较高价值的业务需求。这本身对于数据分析师同学是件很好的事情，可以帮助我们尽量把自己有限的精力投入到高价值的事情上。

3. 常见需求及时报表化。

满足业务方提数需求时，有时会遇到一些相似甚至相同的需求。这时候，我们要和业务方明确，这些需求是否是长期需求？如果是，可以将需求提给 BI 平台部门进行报表化处理。这样，业务方针对类似需求可以直接通过报表了解。
记住一点，能用机器代替人力的数据需求，一定优先使用机器。

4. 业务方 SQL 技能培训。

SQL 是数据分析师的必备技能，但是并不代表只有数据分析师才可以提数。很多公司数据库的权限对产品、运营等都是放开的。如果业务方也能懂一些简单的 SQL 基础语法，有时候，哪怕只是能懂SQL语言，就可以通过简单修改一些参数来完成数据提取工作。

比如，产品不定期的跟踪某个功能的使用人数，这个需求的 SQL 语法、使用的底表，都是固定的，每次只需要修改日期就可以查询到他想要的数据。

比如，销售同学，他可能只关心自己负责的产品品类的销售金额，也可以通过修改 SQL 语句中的产品类别来满足不同销售的需求。

类似这种周期性重复，但是也不适合通过报表的形式来满足的需求，我们可以通过对业务方的简单培训，或者提供 SQL 查询模板，让他们自行满足需求。这样不但减轻了我们的工作量，业务方获提数据也更为方便快捷。

5. 数据需求排期。

如果业务方的数据需求，通过上面的方式，还是没有解决。这时候你只能承接下该数据需求。承接下需求后，尤其是有多个需求的时候，不要马上开始上手做，而应当按照需求的轻重缓急进行优先级排序。
首先，对当前需求池里的所有需求，根据需求的重要性和紧急程度作出初步判断，优先满足重要且紧急的需求。其次是紧急不重要和重要不紧急的需求，最后是不重要不紧急的需求。其实，评估各需求的花费时长，及时跟各业务方同步需求排期和预期产出时间，如果排期与业务方的预期不一致，再对相应的排期作出调整。
比如，产品发现核心业务指标突然明显下降，并且推测某个产品功能存在 Bug，这种需求属于重要且紧急，需要优先处理。
又比如，运营只是想复盘上个月的活动效果，复盘报告下周五才汇报。这个需求属于重要但不紧急，我们可以暂缓处理。

需求排期的好处有以下几点：第一，让需求方 Battle 排期，他们是最了解业务的，不至于耽误重要的业务进度；其次，需求方对需求输出的时间有明确的时间预期，合理调整业务进度；最后，分析师也能更好地掌握处理需求的节奏，不至于手忙脚乱。

6. 学会说“不”。

现有工具能解决业务方的需求吗？需求对业务决策真的有帮助吗？需求合理吗？所有需求都有必要满足吗？如果答案是否定的，你也要学会拒绝。

比如，产品想知道某个功能的点击人数，可以直接通过埋点平台查询。这种需求我们完全可以拒绝。又比如某个运营活动参与的人数远远未达到预期，运营同学提出分用户群拆解，目的是找到一个可“汇报”的角度，我们也可以拒绝。还比如，产品想看近期某几个指标的数据现状，这几个指标可以在不同的 BI 报表里获取到，我们当然也可以拒绝。

工作中不是所有业务方的需求都是合理的，当遇到不合理的数据需求，必要时要学会说“不”。这也是一种专业能力的体现。如果来者不拒，业务方的需求只会越来越多，而且需求价值会变得越来越小。

以上六点，如果你能够在工作中顺利实践。相信在你的工作中，临时提数需求占用的时间会变得越来越少。既能“服务”好我们的业务方，与他们保持良好的合作关系，也能为自己争取到更多的时间投入到重点专项研究上，保证我们的产出，更大化体现数据分析师的价值。

总结

本节课主要分享经哥在处理临时数据需求的一些方法。希望对已经在职或者即将进入数据分析行业的同学有所帮助，希望你能够快速找到工作方向，避免陷入临时提数需求的工作模式。

如果当前工作中遇到数据需求类似问题不知道如何解决，欢迎在留言区提问，也欢迎大家关注我的微信公众号（数据民工来取经儿）进行学习。非常感谢你的用心学习，加油！

10 问题诊断：定位数据异常的快速方法

你好，我是取经儿。今天分享的主题是如何快速定位数据异常的问题。

解读数据波动、快速定位数据异常原因，可以说是数据分析师必备的能力之一。我作为面试官时，会着重考查候选人这方面技能，对初中级分析师来说，它更是一个必问的问题，非常重要。

为什么定位数据异常的能力这么重要呢？

在我看来，通过这个问题，可以初步了解候选人的三大能力。一是，候选人是否有一套成型甚至成熟的分析体系。工作中我们经常会遇到各种数据异常，每次的原因都有可能完全不同。不同指标的数据异常、不同时间节点的异常、不同时间周期的异常对应不同的定位方式，这样可以更快速地找到原因。二是，候选人以面到点、化大为小的解决问题的能力。在我看来，数据分析的工作可以按具象和抽象分为两类问题。具象的问题相对好解决的。比如老板问我们昨天的 DAU 和收入有多少，我们不需要过多思考就可以回答。但是抽象的问题怎么具象化（就是我说的以大化小），就比较难了。比如老板问，周末活跃的用户相比工作日活跃的用户，有什么区别呢？这个问题就需要数据分析师抽丝剥茧、把问题条理化和具象化，然后再进行回答。三是，候选人是否足够了解业务。了解业务也分两个层次：一是数据分析师能敏感地察觉到可能的原因，随后定位到产品、运营或者推荐策略等；二是数据分析师拥有能从果推到因的能力，数据异常是个结果，知道这个结果背后的因，才算完成了。

如何快速定位数据异常的原因呢？

我们首先需要了解哪些变化可能会导致数据异常。不同的情况，对应方法不同，所谓见招拆招。下面分别讲下引起数据异常的几种情况。

特殊事件节点发生的数据异常。

特殊事件节点一般包括客户端发布新版本、重大节假日、重大运营活动（含站内运营活动，也可能是竞品的大型活动）等突发性事件。这种特殊节点的数据异常，通常指向性非常明确，排查方式也相对套路。下面我们还是还原业务场景，来一一说明。

我们假设下图是某款 App 的日活趋势（假设在此期间该 App 没有进行大规模的用户拉新）：

Drawing 0.png

1. 客户端发版后的数据异常。

比如日活急剧下降（也可以是某项功能的使用人数、App 时长异常等）。为了明确问题，我们以上图 4 月 20 日日活下降来做一个说明。假如 4 月 20 日该 App 发布了新版本。常用的排除方式是分 24 小时趋势图、分版本看。如下图所示，分 24 小时趋势图中显示：4 月 20 日下午 2 点，日活开始下降，与发版时间吻合。另外分版本也可以看到：4 月 20 日新版的日活起量，旧版本日活下降，但是新版的增长低于旧版的下降，造成整体日活下降。以上两点，我们可以明确，日活下降是由发布新版本导致的。

Drawing 1.png

分析到这，如果你觉得已经结束了，那么你距离中高级分析师还差一步。我们沿着这个问题继续想，为什么发版会造成日活下降，但是并没有导致日活变为 0？也就是说，新版本可能只是漏报了部分日志，才导致日活只是下降。

说到这个问题，我们需要回到数据口径来讲解。不同公司的日活口径是不同的，每个 App 都可以定义自己的“活跃”。它可以是用户 App 使用时长大于 0 的用户、是有启动 App 行为的用户、是有互动行为的用户等。当然，我们也可以定义多个日志中，含任何一条日志的用户都算活跃用户。我们假设该 App 的日活为有启动 App 或者有 App 使用时长的用户。

如下图，我们看到发布新版后，启动日志的上报量直线下降。这基本可以断定由于新版用户漏报启动日志，从而造成日活量下降。

Drawing 2.png

2. 重大节假日的发生的数据异常。

我们继续看“活跃用户数趋势图”。5 月 1 日，日活量有突增。结合 5 月 1 日为节假日，可以合理推断是因为假期用户的休闲时间变多，导致 App 活跃数增长。但这时还需要通过数据进一步明确原因。相对其他群体，我们知道五一假期对工作群体的影响会更大。可以进一步分年龄段确认，如是否是22岁~50岁日活量增长导致？也可以分城市类型确认，是否主要由一二线城市用户导致？

Drawing 3.png

3. 运营活动等突发性事件。

比如 2018 年 10 月 16 日赵丽颖官宣领证结婚，微博后台直接瘫痪，当日日活量激增；比如双十一购物街，淘宝的订单量增长，可能会影响到竞争对手京东、苏宁易购的订单量下降。

Drawing 4.png

不可控因素导致的数据异常

我们继续看“活跃用户数趋势图”。5 月 11 日，日活量小幅增长。5 月 11 日这天既没有发布新版本，不是节假日，内外部也没有重大运营活动。那么这种情况，我们别无他法，只能各个维度拆解，分析是否能将日活的增长，从而定位到某个用户群体上。最常见的不可控因素为自然因素，比如某个省份连续多天大雨天气。天气如果放晴，一些用户会选择户外游玩，导致日活下降。又比如某个地市发生小幅地震，更新“朋友圈”的用户变多。

策略或者业务调整引起的数据异常

这种异常，按照前面两种数据异常的定位方式，即使细分人群，也往往找不到原因。我们会发现各种人群的指标变化趋势相近，并没有集中在某个用户群上。这种情况，我们需要根据业务特征来归因。常用的方法是根据业务属性拆解，或者根据漏斗转化拆解。下面我们还是举例说明。

注意，设定的场景只为说明数据异常定位方法，数据和结论纯属虚构。

假如：从 6 月 21 日开始，使用微信朋友圈的用户数和时长开始缓慢下降。

我们通过分析已经排除了发版、运营活动和自然因素的影响。这个时候，漏斗分析可以有效地帮我们定位问题。漏斗分析是，监控从用户行为起点到终点各阶段转化率。浏览朋友圈的用户数下降的漏斗为：打开微信→点击“发现”→点击“朋友圈”→开始浏览朋友圈

Drawing 5.png

上图我们看到，6月21日之后，浏览朋友圈用户数下降主要是因为从“发现”到“朋友圈”的用户数减少了。那么，进入“发现”的用户，他们的行为变化是怎样的呢？下面我们可以继续分析这批用户在“发现”的行为。

Drawing 6.png

我们发现，在 6 月 21 日之后，进入“发现”的用户，更多地被分流到“视频号”。原来在 6 月 21 日，“视频号”从前期的小流量灰度，到全面放开了，导致“发现”页其他入口的流量均有所分流。

需要对用户行为进行归因的数据异常

这种异常往往是最难找到原因的，事实上上面 3 类定位数据异常的方法普适性更好，它们可以运用到任何指标的数据异常，也不太受限于业务类型。而我们现在要讨论的用户行为归因则与业务类型强相关，它需要可能需要分析用户在 App 内的行为、社交关系、消费充值等各方面情况，从根本上得出数据异常的原因。

我们以短视频 App 为例，在此虚构一个日活百万、名叫 SmallVideo 的 App。在 SmallVideo 里可以观看短视频和直播，如果你没有用过短视频类 App，建议你下载抖音或快手来了解我们所说的这个场景。

我们现在面临的数据异常是，从 3 月 1 日开始，日活（DAU）呈阴跌趋势。

Drawing 7.png

我们先按照常用的用户细分的方式拆解，发现不同地域、年龄、性别等日活下降幅度相近，也排除是发版或者日志上报的问题。那么，到底是什么原因导致的日活下降呢？此时，就要按用户行为来归因。一个维度是，用户是怎么打开 App 而成为一个活跃用户的？用户可以通过主动打开 App、通过分享链接、通过 Push 打开、甚至可能通过短信链接打开 App......另一个维度是，用户使用短视频 App 的原因有哪些？SmallVideo上，用户可以看短视频、看直播、自己当作者上传短视频或者做主播、直播购物、陌生人社交等。是不是 SmallVideo 不能满足用户的这些需求了？我们的分析就建立在对这些用户行为之上进行分析。

我们先来看用户通过各种方式打开 App 的变化趋势。如下图，能看到各种方式的用户均下降，可以排除是分享、Push、流失召回等带来的影响。

Drawing 8.png

我们再来看站内各种行为的用户量变化趋势。如下图，可以看到，下降的用户数集中在观看直播和直播购物。到这里，我们可以初步判断日活主要是受电商直播的影响。

Drawing 9.png

下面我们继续分析是哪些电商直播的用户数在下降，如下图，按主播的粉丝数区间划分，可以看到主要是 100w 以上粉丝的主播的观众数量在下降。

Drawing 10.png

而站内 100w 粉丝以上的开播主播数量只有不到 100 个。我们逐个排查发现，因为某大 V 主播，在 2 月 29 日违反了站内条款而被封号，导致其无法再进行直播带货了。这间接导致他的粉丝活跃度下降。至此我们通过用户行为归因定位到了日活下降原因。

Drawing 11.png

当然，以上情况并不能囊括所有数据异常的情况，比如刷子行为也是导致数据异常的一种常见原因。这块涉及反作弊，在此不赘述。

总结

以上我们可以看到，一个小小的数据异常问题，可能会牵扯到业务的方方面面。产品、运营、推荐策略、客户端开发、甚至自然因素等都有可能成为数据异常的原因，但是万变不离其宗。只要我们掌握了完善的方法体系、加上对业务的了解，相信你就离真相不远了！如果当前工作中遇到数据异常相关问题不知道如何解决，欢迎在留言区提问，也欢迎大家关注我的微信公众号（数据民工来取经儿）进行学习。非常感谢你的用心学习，加油！

11 精细运营：数据分析在用户运营中的运用

你好，我是取经儿。今天给你分享的是数据分析在用户运营中的运用。

市面上充斥着大量教我们如何提高数据处理技能的文章，可读了这类文章所教授的技能，我们还是不清晰数据分析师该做什么，因为这些技巧性的东西常常是脱离业务的。本课时，我们不谈 SQL、Python、Spark 等数据处理技巧，我们聊聊数据分析在运营中的运用。

运营是什么？

不同的产品为用户提供不同类型的服务。比如，微信提供用户社交的场景，爱奇艺和腾讯视频提供的是影视综艺内容，抖音快手提供的是短视频和直播场景。而运营是为用户提供是差异化的服务，从而提升平台的商业价值。比如某个新剧在爱奇艺上独播，这个新剧就是平台提供的差异性价值。

一般而言，运营可以分为几大类：用户运营、内容运营和活动运营。针对不同的产品形态、不同发展阶段的产品，运营抓手的侧重点有所不同。我们以新浪微博和拼多多为例子，设定一些业务场景进行来讲解，避免自己脱离业务。

新浪微博的例子

产品初期的新浪微博，其主要价值随时随地发现新鲜事儿。所以前期微博发展的重点之一就是，寻找优质的内容生产者（后面我们简称他们为 KOL，Key Opinion Leader），为平台提供高质量的内容。再通过这些内容留住用户。寻找 KOL，入驻微博，并持续地提供内容，是这一时期用户运营的工作重点。数据分析可以帮助运营更高效地找到 KOL。一种方式是通过爬虫挖掘站外 KOL，为运营提供站外 KOL 名单、联系方式（当然，联系方式通常很难拿到，实际中，可能只能拿到用户昵称，再由运营通过昵称与 KOL 取得联系）。另一种方式是挖掘站内有潜力成为 KOL 的用户，给予流量倾斜，来站内培养。挖掘的流程是，先筛选出一批稳定输出内容的用户。再从涨粉速度和内容互动率（被点赞或者评论）的角度，筛选高潜力 KOL。通过这种方式，可以最大程度的帮助运营跳过“盲选”阶段，提高运营同学的效率。

当微博逐步发展到稳定期，KOL 逐渐增多，站内内容的供给可以满足用户浏览各类内容的需求，用户运营的工作重点也进行了调整。此时，重点不再是寻找 KOL，重点开始变为维护站内 KOL，减少他们向其他平台流失的风险。

这个阶段，数据分析师需要帮助运营同学做精细化运营。常用的模型是通过RFM 模型，将 KOL分群，运营针对不同状态的 KOL，制定不同的运营策略。在这个场景里：

R（Recency），KOL 在平台内最近一次发微博的时间；
F（Frequency），KOL 在最近一周内发布的微博数量（统计周期视业务属性而定，微博相比视频生产平台，是一个更高频的场景，如果发博间隔过长，可能 KOL 已经流失了）；
M（Monetary），可以是衡量 KOL 价值的任何一个指标，比如给微博带来的广告收入、发布微博带来的阅读流量（围观用户数）等。

根据用户 R、F、M 的现状，将 KOL分群。

对于高活且高价值的 KOL，一对一维护。在我们设定的场景里，他们是最近一周发布微博数量多、时间短、有大量群众围观的 KOL。
对高价值且高流失概率的 KOL 给予挽留、对大量长尾的 KOL 实施监控，及早发现问题等。

在内容运营侧，随着微博流量变大之后，微博热搜的影响也越来越大。微博热搜已经成为用户在微博里的一个重要内容消费场景。所以，对微博热搜的运营显得尤为重要。数据分析师在微博热搜运营方面能产生价值的地方，主要有两点：一是，针对进入热搜页面的用户，最大限度地提高用户对热搜内容的消费数量和时长；二是，帮助运营找到有潜力成为热搜的内容，提供稳定的内容供给。

对于第一点，热搜的排序会影响用户在热搜内的消费深度，试想如果热搜上排名前几的话题，你都不感兴趣，你还有耐心看下去吗？所以，需要实时分析不同话题的曝光点击率，及进入热搜后的浏览时长。对于表现不佳的话题在排序上进行降权，甚至下掉部分热搜话题，以保证热搜内容是用户所关注并有兴趣的内容。

对于第二点，可以通过分析站内话题热度提升速度（比如参与讨论的用户数、回帖的数量、话题搜索量等），提早挖掘潜力热搜话题。潜力热搜话题的挖掘，可以为平台内容不断注入新鲜血液，避免部分潜力话题因为流量分配机制，而不能被发现（也受产品形态影响）。

但是，我们也知道，任何一款产品，都会存在用户流失的事实。我们可以做的是减缓用户的流失，对流失的用户尽量召回。对此，数据分析师可以利用用户生命周期模型，合理定义用户所处的阶段。当然，前面提到的 RFM 模型也常被广泛使用在这里。它可以有效识别降频用户。除了定位到人，数据分析还可以定位到用户进入衰退期的原因，具体可以参考《10 问题诊断：定位数据异常的快速方法》，我们提到的用户行为归因方法。从而帮助运营制定精确化的运营策略来挽回用户。

拼多多的例子

前面我们设定了新浪微博各个发展阶段的一些运营场景。相对而言，微博是一个偏内容社交的一款 App。下面我再以电商领域的新起之秀拼多多为例，来讲数据分析在运营中的运用方法。

拼多多在发展初期，用户定位的是广大农村市场，走薄利多销的路线。所以选品、打造爆款显得尤为重要。通过打造爆款，拼多多直接找到供应链的源头，以量大来压低价格，进而反哺线上，以此跑通整个商业模式。在选品上，数据分析师可以协助内容运营选品。具体来说，前期符合拼多多商业模式的选品原则，在数据上体现为以下几点：

商品定价低，但并不是低到接近 0 才是最优的，要保证企业有一定的利润空间，所以需要通过数据，根据商品毛利和销量来综合决定较优的商品价格区间；
商品的受众为三四线以下的低线城市用户，用户较为明确，才能更好地做到有的放矢；
销量要大足够大，这点可以通过销量排序可以得到；
商品属性最好偏单一，这样容易打造爆款。

以上选品原则都可以通过数据量化的形式，找到答案的。当然，也可以通过目前站内已经累计的数据，找到不同价格区间的实际爆款，在此基础上扩展爆款的边界。这些都是数据分析对业务的价值。

另外，我们也可以看到，各个电商 App 首页的一级入口顺序不太相同。移动互联网行业中，流量即金钱。入口靠前就意味着流量大、变现能力强。所以，每个入口的顺序都不是靠主观判断来定的。我们需要通过数据，定量化用户对各个入口的真正需求，然后再排除入口顺序的影响（可以通过 A/B 实验来测算）。最后由各入口的点击、订单转化、订单销售额及各入口的消费频次等共同决定如何实现各个位置流量价值的最大化。

image (1).png

你知道现在拼多多的百亿补贴活动是怎么演化来的吗？

有一个传说是，活动初期，运营只是制定了一个小活动，当时的活动也不叫“百亿补贴”。活动起源于 2019 年，当时拼多多的用户总量已经积累到了一定量级，尤其在三四线以下低线城市，渗透率已经很高了。这种情况下，拼多多想下一步提高用户在一二线高线市场的渗透。针对这个目标，运营发起了一场低价正品的活动，没想到活动效果出乎意料得好。运营干脆把它做成了常规活动，才逐步演变成现在我们看到的百亿补贴。具体的活动效果数据，我们不得而知。但是我们可以聊聊，在这个场景里，什么样的数据效果算好的数据效果？

如果我负责这个活动的运营效果分析。首先我会复盘整个活动的规模，这包括在该活动中下单成功的用户数和商品销售额。其次，结合活动的背景，我们需要重点关注一二线城市用户在这个活动中的下单转化量。为了突出活动效果，可以对比一二线城市的用户在非该场景下的下单转化量。还有就是活动前后销售额的变化。如果数据上只是单纯的销售额增长，这不足以让公司决策决定继续投入资源来做百亿补贴活动。实际上，数据上看到，这个活动对一二线城市的拉新效果真的很好，用户复购率明显提升。而一二线城市的用户正是这场活动的目标，所以，数据上得出的结论就是品牌补贴活动，降低了对于一二线城市用户拉新成本，活动投入产出比很好，进而推动公司升级活动，制定出百亿补贴的品牌活动。

总结

回到开头我们提到的“什么是运营”问题上。运营是为用户提供稳定预期以外的价值，从而提升平台的商业价值。如果你问我数据分析是什么，答案同上。只不过运营落地有用户、内容、活动等作为载体。这使运营看起来是具象的。而数据分析，则为运营、产品、推荐、甚至开发、市场等等各方提供额外的附加价值。以数据技能为基础、以业务洞察为磨刀石，修炼一把尚方宝剑，为业务向前发展打怪神级。

如果当前工作中遇到运营相关问题不知道如何解决，欢迎在留言区提问，也欢迎大家关注我的微信公众号（数据民工来取经儿）进行学习。非常感谢你的用心学习，加油！

12 产品迭代：巧用数据分析优化产品

上一节我们对数据分析在用户运营中的运用有了全面的认识。今天我们来了解一下，数据分析如何在产品迭代中为产品赋能。

产品功能迭代，我们分析什么？

产品迭代的本质是持续优化用户体验，为用户提供产品价值。所以我们使用的 App 大都定期发布新版本。这些版本或增加新功能，或优化已有旧功能、下线某些旧功能，来满足用户日益变化的需求，为用户提供新价值。针对这些问题，数据分析需要回答：有多少用户对新功能有需求？用户喜不喜欢新功能？和我们的预期有没有差异、差异在哪？下一步如何优化？回答完这些问题，我们就能大体明白，用户对新上功能是否买账？旧功能优化后用户使用率是否会提升？以及某些功能下线背后的真正原因。

我们以短视频/直播 App 的一个场景，来逐步梳理产品功能分析中常用的方法。假如下图顶部导航栏中的“直播”栏目是一个新增的产品功能，进入“直播”栏目后，用户可以选择点击直播间封面，进入直播间观看直播。对于这个场景，我们分析什么？又从哪些方面分析？

常用的分析方法

1. 功能规模分析

一个功能代表了一种用户需求。当 App 新增一个产品功能后，产品经理们最关心的问题是：有多少用户会用这个新功能。功能规模分析主要用来回答某个功能的用户量级问题。同时它也可以观测到某个功能的趋势变化。功能规模分析常用的指标有功能使用用户数、功能使用次数、功能渗透率。

功能使用用户数（UV），独立访问用户数（去重），它代表了使用一个功能的用户量级。
功能使用次数（PV），访问用户的点击量。用户打开某功能到关闭离开的过程即为 1 次访问点击，PV 与 UV 的比值一定程度上反映产品的黏性，比值越高黏性越高。
功能渗透率，是指使用某功能用户在 App 活跃用户中的占比。

注意，以下数据均为编造的非真实数据，仅用来帮我们梳理和理解数据分析在功能迭代中是如何赋能优化产品的。

通过功能规模分析可知，上线第 7 天，进入“直播”栏目的用户数为 224 万、次数为 467 万次，功能渗透率为 22.4%（假设该 App 的日活跃用户数为 1 千万）。实际中，仅仅给出数字是不够的。好的数据分析师，不仅提供“数字”，更提供认知。我们可以给出顶导上“关注”和“北京”栏目的功能渗透率，横向对比 3 个栏目的渗透率，从而综合判断“直播”栏目是否处在一个合理的水平上。

另一方面，功能规模分析还可以用于观测进入“直播”栏目用户数的趋势变化，如下图所示，在“直播”上线第 100 天开始，进入“直播”栏目的用户数呈下降趋势，我们需要对此进行归因（归因方法参考《10 问题诊断：定位数据异常的快速方法》进行学习）。

2. 功能漏斗分析

通过功能规模分析，我们得知在“直播”栏目里进入直播间观看直播的用户数为 168 万（仍然假设日活为 1 千万），用户渗透率为 16.8%。这时，产品经理们需要知道，哪些方面可以提高用户渗透比例。常用的方法就是漏斗分析。漏斗分析可以监控从用户行为起点到终点各阶段的转化率，可以快速定位流失环节。这样，就可以重点优化解决这些问题环节了。现实中，漏斗分析使用场景非常广泛。它常用于激活登陆转化、关注互动转化、付费购买转化等流程中。在我们设定的这个场景里，漏斗转化表现为以下形式:

通过上图我们可以看到，用户渗透率为 16.8%。第一步的转化折损较大，只有 22.4% 的用户进入“直播”栏目页面。横向对比进入“关注”和“北京”栏目的用户渗透，“直播”存在较大的提升空间。

通过使用产品我们发现，用户进入“关注”栏目有两种方式：一是通过点击“关注”进入；二是通过左右滑动页面进入。但是“直播”栏目只能通过点击“直播”进入。通过埋点，可以得到“点击”和“滑动”进入各个栏目的用户量级。我们发现用户进入“关注”和“北京”更多的是通过左右滑动页面进入。而“直播”目前只能通过“点击”进入，因此损失了大量滑动进入的用户。所以，后期重点就可以放在解决用户进入“直播”栏目的交互方式，预期可以提升功能渗透。

3. 功能使用深度分析

产品经理们设计一个新功能，除了希望更多的人来用，还希望用过的人能多用。通过前两步的分析，我们对“直播”栏目的使用情况有了整体上的认知，但是我们并不知道用户对功能的使用深度情况：用户看了多少个直播、看了多长时间。功能使用深度分析是通过用户的使用频次、使用时长、社交互动等指标反映用户的使用程度。

人均使用频次：功能使用次数/功能使用用户数。
人均使用时长：功能使用总时长/功能使用用户数。

在我们设置的场景里，有 168 万的用户在直播栏目里观看了直播。通过功能深度分析我们得知他们人均观看 8~9 个直播间、对应 17.5 min 的直播，如下图：

但是，我们知道平均值容易受到极值的影响。尤其是移动互联网用户，存在大量的长尾效应，可能有相当一部分用户会被平均，均值并不能代表这 168 万用户的整体水平。所以我们通常还需要结合分布图来分析。如下，我们可以看到只有 8.8% 的用户观看 20 个以上直播间，但是他们贡献了 51% 的直播时长；相反，有 72% 的用户只看 1~5 个直播间，仅贡献 19% 的直播时长。说明，目前 16.8% 的渗透用户中，存在大量的浅度用户。（实际中，需要进一步分析浅度用户，帮助增加他们的使用深度。）

4. 功能使用黏性分析

以上 3 点我们回答了功能规模、用户使用深度等问题。试问，如果一个功能的渗透率低，就真的代表该功能没有价值？反之，如果一个功能的渗透率高，就一定代表它的用户价值高吗？

答案是否定的。因为功能策略可以“捏造数据”，这样的数据会“骗人”。比如下图中，招行 App 右上角的角标。角标本意是为了促使用户打开 App 。刚上的时候，确实有用，数据上也可以看到 App 启动次数有大幅提升。但是这种效果随着时间明显衰退，用户知道被“Cheat”后。再次，因为右上角角标而打开 App 的概率大幅下降。

Drawing 6.png

![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/2d55ce468b3ca7c8751e94e1af731748.png#pic_center)

这就是我们本小节要提出的概念：功能使用黏性。它指通过分析用户使用功能的留存或者一段时间内使用功能的频次，来反映功能的健康度。

N 日功能留存：某日使用功能的用户，在 N 日后仍然使用该功能的用户比例。短期通常看次日、7日留存；长期看 14 日、30 日留存。
功能的频次：在 N 日内，用户使用功能的天数，N 通常取 7 日或 14 日。

回答本小节开始提到的问题：功能渗透不能代表该功能的价值。如果一个功能的渗透率很高，但是留存很低，很可能是某种激进的策略导致。我们要注意，不要被 Cheat。如果功能的渗透率很低，但是留存高、用户使用频次高，说明有一小部分用户对这个功能有明确和稳定的诉求，它也是有价值的。

5. 分群分析

如果说上面的分析，只是帮我们了解功能被使用的现状，那么分群分析可以帮助我们理解核心用户，为指导产品迭代和精细化运营提供解决方案。分群分析是指将用户按照某种属性或者行为特征分为几个不同群体，分析他们的差异，以期望找到优化点。用户分群的划分标准可以按照用户画像划分，也可以按照用户行为划分。用户画像标签包括年龄、性别、机型、地域等；行为特征包括 App 使用时长、App 内时长分配、30 天使用 App 天数分层等。

我们还是以“直播”栏目为例，通过性别和年龄分群分析，可以看到，女性、18 岁以下青少年及 45 岁以上中老年用户，观看直播的用户比例较低。数据详见图 1 和图 2。这里我们可以猜测目前直播栏目中的内容，有可能不符合他们对内容的偏好。进一步分析他们在直播栏目中的直播曝光点击率 （曝光点击率=用户点击直播间数量/曝光直播间数量，反映了内容对用户的吸引程度），如下图 3 和图 4。女性、18 岁以下青少年及 45 岁以上中老年用户的点击率，明显低于男性和青年用户。（我们可以进一步通过分析曝光的直播内容，来佐证目前的内容不符合他们的偏好，这里就不做详述了。）

基于此分析，我们建议，在推荐策略上，针对不同的属性用户个性化推荐内容；另外在内容上增加女性、18岁以下、45岁以下偏好内容的覆盖度。

![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/60e12dbb0f43ed669715b8ed856d5635.png#pic_center)

上面是通过画像做的人群分析，我们也可以针对用户行为属性来分群，下面简单举例说明。对于老用户，他们在站内已经积累了大量的行为数据，我们可以按照他们之前消费的短视频内容类型将他们分类，比如游戏类、美食类、户外类等等，根据他们的短视频偏好推荐相应的直播。这在一定程度上也能增加推荐的准确性。或者根据用户的手机安装列表来判断用户的偏好，这也是一种方法。

另外，还有一些更复杂的用户分群方法，这些用户分群方法可以为用户提供的精细化运营，比如，生命周期管理、RFM 模型等。数据分析可以识别处于不同生命周期的用户，对于成长期的用户采取提高留存策略、对稳定期用户采取延缓衰老策略、对衰退期用户采取挽留策略、对流失的用户采取召回策略等； RFM 模型是数据分析常用的模型，模型针对高频高 ARPU 用户重点关怀、刺激高频低 ARPU 用户消费等。

6. 用户调研

以上都是定量的分析方法，它能帮助我们客观、全量地了解产品和用户。我们知道，给用户呈现的产品形态，主要是产品经理和 UI 设计共同打磨而成的。一定程度上，他们可能并不是这块 App 的核心用户群。他们也是通过理解用户需求来打磨产品（这里我没有提开发、测试、运营等，是因为他们的工作，本质上是不改变产品形态）。那么用户调研则为我们直接接触用户、了解用户需求，提供了通道。常用的用户调研方法有：问卷调研、深度访谈、焦点小组访谈、眼动实验、可用性测试、参与式设计等。

总结

以上是数据分析在产品迭代中的常规方法。这些方法本身可以系统性帮我们在产品迭代中输出建议，但是好的分析离不开对业务的理解，并对此产生自己的想法。同时，从输出建议到建议落地还有很大一步需要跨过去。这其间的推动力也是一个数据分析师从初级到中高级的自我修炼。如果当前工作中遇到产品分析相关问题不知道如何解决，欢迎在留言区提问，也欢迎大家关注我的微信公众号（数据民工来取经儿）进行学习。非常感谢你用心学习，加油！

13 自我驱动：如何开展专题分析

这节课给你讲下数据分析师如何做专题分析。

专题分析是数据分析师自驱研究项目，通过挖掘数据来解决当前业务潜在问题。需求的发起方是数据分析师，发现问题的方式是通过分析数据现状来洞察业务问题。期望达到的目的是优化现有数据策略提高某个关键指标，或者驱动产品跌倒产品功能以提高功能渗透率或是功能留存，或者能指导运营精细化运营某个用户群体。

![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/604c9fadb18ccf9304a78cd18f955a7e.png#pic_center)

下面我们按照以下三个步骤来阐述如何做专题分析：

提出问题；
分析思路；
解决方案。

提出问题

数据分析最终是为公司业务发展服务的，不是为了分析而分析。所以，提出的问题要围绕公司业务发展大方向展开。问题可以是产品重点关心的功能项目，也可以是重大节日活动运营项目，或是推荐关心的项目。具体来说，现在很多互联网公司都会制定公司级 OKR（Objectives and Key Results），即目标与关键成果法，并且会将 OKR 拆分到各个部门、小组、甚至个人。OKR 是分析师提出问题的一个很好的出发点，它能保证我们的目标与业务方一致。当后续业务资源有保障的情况下，我们才可能最终推进项目落地。另一方面，围绕 OKR 提出的解决方案，也能在更大范围内对业务产生影响力。

上面我们讲的是，可以围绕 OKR 缩小，提出问题的范畴。不同部门 OKR 的重点是不一样的。假设，公司今年的目标是日活提升 50%，达到 5000 万，为了达成这个目标，各部门会采取不同的方法。

产品将的重点是迭代哪些产品功能，优化用户使用 App 体验。
运营的重点是通过挖掘或扶持 KOL 来承接用户对内容的需求，或者重点打造站内活动为用户营造社区归属感。
推荐算法的优化方向是流量头部化，或者权衡站内生态。

可以看到，围绕 OKR 的方向有很多，数据分析师需要合理评估自己的能力模型，结合对业务的了解深度，选择发力点，围绕 OKR，提升新用户留存和老用户活跃，从而完成用户增长目标。

通过上面张图，我们提出了下面几个研究方向。

1. 如何提升新用户留存率？
公司花费大量成本拉来的新用户，如果注册后不再活跃（用户流失），即留存率很差。这是非常严重的问题，会导致产品获取单个用户的成本高、用户规模也很难做大。
影响留存率的原因很多，有些方法已经是业内通用的解决方案，比如：

简化注册流程，减少登陆过程中的用户折损。常用的解决方法，如绑定微信一键注册，甚至可以直接允许用户以游客身法体验产品的基础功能，如果用户触发某个交互行为（比如直播 App 中的关注主播行为）再提示用户注册、登陆等。
利诱新用户，引导用户登录，或下单转化。比如在新用户浏览首页时，通过弹窗提示用户领取大礼包（短视频 App 看视频领红包、电商 App 的 1 元购或者大额满减券、打车 App 的折扣券等）。

除了这些常规的提升新用户留存的方法，数据上还可以探索的问题其实还有很多，比如新用户的需求是否被满足？如果没有，如何优化来提升留存？

2. 老用户流失原因分析？
新用户的留存固然重要，但是老用户的量级更大，所以维护老用户更是必不可少。实际工作中，针对老用户使用较多的活动是：Push 促活和流失召回。而对于老用户的流失归因分析和流失预警做的比较少，这些地方，数据分析其实更能发挥其主观能动性。
流失原因是可以直接反映在用户行为上的，可以通过分析老用户流失的不同场景，有针对性地制定一些挽回策略。
3. 平台提供的内容与用户需求是否是匹配的？
对于短视频公司来讲，每天都会有新增的视频内容。如何经过算法和人工标注，让视频出现在对应用户眼前？这里面存着极大的挖掘空间。
针对上面提出的问题，我们尝试从数据分析的角度来展开分析思路，并且围绕部分场景，延伸一些可能的解决方案。

分析思路和解决方案

新用户需求是否被满足？

不同类型 App 提供的核心服务不同，衡量是否被满足方法也不同。我们可以通过用户新增当天的行为来分析。下面分享思考和分析的过程。

以电商平台为例，核心指标是浏览商品、收藏、加购物车，店铺关注，购买等。围绕核心指标，衍生出以下几点，用来衡量电商新用户的需求是否被满足。

第一，商品曝光量、浏览商品详情页数量，代表用户是否有购买需求。

第二，商品曝光量到浏览商品详情页转化率，代表推荐的商品与用户需求的匹配程度。

第三，浏览商品到加购物车的转化率、加购物车到支付的转化率，代表购物需求是否被满足。

如果只是统计上述新用户的指标，无法得到有洞察的数据结论。可以分用户群体、拉长时间趋势分析等。比如：

1. 不同用户群体有哪些不同。

对比不同性别、年龄、地域的数据指标差异。可能可以得到一些有意思的基础结论。

三线城市用户的重要性并不比一线城市用户差。三线城市的客单价虽然略低，但是成单量远高于一线城市用户，二者对平台 GMV 的贡献率相当。而且，其商品浏览深度和 App 使用时长也都比一线城市用户更高，这些浏览行为可以为优化推荐算法提供大量的训练数据。
女性用户购买力强于男性用户，其各项指标都远高于男性用户。
虽然男性用户购买数据整体不如女性，但是下单转化率更高，购买决策的时间更短。

上面的分析都在说明一个事实，衡量不同类型新用户的需求是否被满足的标准是不同的。

2. 不同时间的用户有哪些不同。

分时间周期分析核心指标：一是不同时间周期的用户行为有显著差异的，应该差异化对待；二是拉长时间周期监控新用户核心指标变化。如果指标增长或下降，可以及时归因到产品或运营上的调整，那这些调整应该加强还是叫停？比如：总结出节假日和工作日的不同特点，以及每天不同时间段用户数据上的不同特点。是否可以得出一些指导运营的结论，比如打折、满减优惠券、无门槛优惠券、邮费券等。哪个时间段使用运营结论，更能提升用户的下单转化率？比如新用户在白天的时候，浏览深度浅，用户更多是关注和收藏，是否需要在晚上的时候 Push 通知用户继续完成购买流程？

以上的分析，反过来看，平台策略应该是有差异的。数据分析帮助制定不同策略来承接用户不同需求，以提升用户留存。

老用户的哪些流失场景？

每个用户在一个平台上都有其生命周期，从新用户到高度活跃再到最后流失，只不过每个用户生命周期的长短不同而已。很少 App 能像微信那样，可以长期把用户圈在 App 上（微信社交黏性太强大了）。

我们以短视频平台为例来分析老用户流失。短视频平台的核心指标是观看视频数量、单个视频平均观看时长、完播率、转评赞率等。用户流失在数据上的表现是，核心指标会处于下降状态中。如何从数据上找到流失的场景，及如何解决？

用户更换短视频账号，造成原来账号不在活跃。比如同一个手机设备拥有两个手机号，用户切换到某个固定账号下使用 App。这种属于一个设备 ID 对应多个 user_id 的情况，分析流失时应该首先排除它们，这些用户的行为数据都是脏数据。
产品功能的迭代，让老用户不习惯新 UI 的交互。这个可以通过 A/B 实验进行归因，看一下不同版本中相同类型老用户，经过一段时间使用后的流失情况。根据新来版本的用户留存和使用情况，推动产品功能回滚或者推全（回滚是指 App 某个推全功能回退到推全前的交互样式）。
特殊群体，如学生用户在寒暑假期间和开学期间活跃状态的改变。分析时也应该排除学生群体。
竞品引起，自己平台用户流失，被竞品承接。分析用户是否是由于关注关系而流失的。从而引导用户在平台内多关注其他主播，增加用户对平台的社交黏性；分析用户是否是由于对平台内容不满意而流失的。从而对浏览深度较浅的用户做重点优化，提高用户体验。
平台上某个大 V 流失，或者新作品更新变少，其粉丝活跃度下降。针对这点，需要运营同学介入维护平台大 V 的活跃状态。

以上，简单列举，老用户流失可能是因为其他原因。除了以上分析方法，还可以通过用户访谈来获得最一线用户流失的原因。

内容和用户匹配策略如何优化？

几乎任何一家互联网公司都有一支推荐算法团队，来提高平台内容和用户兴趣的匹配度。电商公司需要提高用户与商品的匹配度、短视频公司需要提高用户与视频的匹配度、信息流公司需要提供用户与信息的匹配程度等。

推荐算法团队更多的是通过 A/B 实验查看核心指标的涨跌来判断模型迭代的优劣。但是 A/B 实验只能回答选择哪个方案更好，不能回答问题的最优答案是什么。数据分析师可以站在平台生态的角度，来评估当前推荐算法是否有优化空间。还是以短视频 App 为例，它是一个需要兼顾生产者和用户的双边平台，让优秀的生产者获得更多的流量曝光，让用户看到自己感兴趣领域的优质内容，是平台应该做的事情。

内容生产侧： 每天上传的视频数量有多少、都是哪些用户上传的、这些视频的内容分别是什么种类的视频、有多少视频能获取热门流量、流量又是如何分布的等。
内容消费侧： 每天用户在站内观看多少视频、用户喜欢哪些内容类型的视频、单次观看时长是多久等。

推荐算法的 AB 测试可以得出优化的算法是否更优了，数据分析可以进一步分析优化结果出现的原因，指导下一步优化的方向。

比如，优化后的算法，会推出更多粉丝数量比较高的作者的视频，所以平台里用户看到的视频质量整体变得更好了，用户侧的观看数量增长了。但是，作者生产侧，由于获取不到流量的作者变多了，所以上传视频的作者却下降了。长远看，粉丝数量较低的作者在平台里找不到涨粉的渠道，可能会流失，从而造成平台内的内容供给出现问题。那么，即使这个优化算法可以提高用户侧的消费指标，也应该再评估一下对生产侧的影响。
比如，优化后的算法，会推出更多之前推出较少出现的视频类型（比如财经类视频、户外类视频），用户的惊喜感更强，从而提升了消费侧的指标，那么，沿着这个思路可以再分析一下还有哪些视频类型也可以达到这种效果，进一步提升指标。

以上，从三个方面举例说明，如何展开专题分析。

由于篇幅所限，我们主要讲解思考的出发点和通过数据可能探索的一些方向。实际专题分析要在当前基础上进一步深入论证，最后与算法、产品、运营一起来解决相应的问题。