数据分析实战：思维先行、清洗留痕与表达落地

我见过不少数据分析项目，最后死得莫名其妙——不是算法不够高级，也不是代码跑不动，而是分析报告做完之后，业务方看两眼就放进了收藏夹，再也没打开过。前两天帮朋友救一个项目，Excel里两万多行销售数据，光清洗就折腾了三天，最后交付的时候，对方问了一句“所以呢？我们现在到底该干什么”，我朋友当场就愣在那了。这个场景太常见了，所以我特别想把数据分析实践里那些真正要命、但很少有人系统讲过的环节撸一遍。这篇是系列第二篇，不聊理论，不讲大模型，就围绕一个完整数据分析项目里最容易被低估的三件事：思维先行、清洗留痕、表达落地。顺便会串起工具链上的Python、Spark、可视化，以及金融风控、足球分析这类行业案例，最后再聊聊面试和笔试到底在考察什么。适合刚做完一两个项目、感觉哪里不对又说不出来的人，以及准备转岗数据分析、想系统补全实战细节的读者。

1. 分析还没开始，先回答"谁在看、怎么用"——这是数据思维的第一道门槛

1.1 为什么业务方看完报告只说"挺好"，然后就没有然后了

我做过的第一个商业化数据分析项目，是在一家零售公司做会员复购分析。当时我花了整整一周，把用户分群、RFM模型、复购率趋势全跑了一遍，excel表格做了十几张，自认为干货满满。汇报那天，运营总监听得很认真，最后只说了句“辛苦了，挺好的”。然后这个项目就再也没有后续了。

后来复盘我才明白问题出在哪：我给的是一堆“正确的事实”，但没有给“可执行的决策”。比如我说“高价值会员复购率下降了5%”，对方心里想的是“那我要做什么？”正确的表达应该是：“高价值会员复购率下降了5%，主要是购买后30天未激活的人群贡献的，建议针对这批人做一次定向优惠券触达，预计能拉回约8000人。”这就是数据思维的起点：分析不是为了证明自己会算数，而是为了让别人能做决定。

所以每次项目开工前，我都会先问自己三个问题：谁在看这份报告？他要做什么决定？我给出的信息能不能让他少纠结一次？这三个问题的答案，直接决定了后面所有分析路径怎么走。

1.2 用一张"问题清单"倒推分析路径

很多新人拿到数据就开跑，跑完才想起来“好像少拉了一个字段”，然后陷入取数、清洗、返工的恶性循环。我现在的做法是，动手之前先花半小时到一小时，把下面这张表填完：

这张表不用写得很正式，但必须能回答。如果填到“缺什么数据”那栏发现缺了一大半，那这个项目大概率还没准备好，强行做出来的东西也只能是“参考”。真正的数据思维，不是会绕开缺失数据，而是知道缺失数据对结论的影响有多大。

1.3 商业数据分析和学术分析，走的是两条路

我见过不少统计学出身的同学，做商业分析时特别纠结因果推断，总想着要跑一个完美的实验设计，要把p值卡到0.01。这种严谨让人敬佩，但商业场景里大多数时候没这个条件。

商业数据分析的核心是“在资源有限的情况下，找到收益最大、风险可控的动作”。比如你发现“北京地区的用户购买转化率明显高于上海”，学术上你要去验证是不是抽样误差，但业务上这个差异已经足够支撑你做一个区域试点。相关性有时候就是够用的，尤其是在做探索性分析的时候。

无监督学习在这些场景里特别常用。我做过一个客户分群项目，没有标签数据，也不想拍脑袋定义“高价值客户”，于是用聚类算法按消费频次、客单价、活跃时长把用户分成了五群。聚类结果并没有给每个群起名字，是我和业务同事一起看了特征分布之后才定义的：叫“价格敏感型”、“品牌忠诚型”等等。这个过程中，商业理解比算法参数重要得多。这不是说因果推断不重要，而是说分析要分阶段：先用相关性快速找到方向，再用更严谨的实验去验证关键假设。

2. 清洗数据别只会上工具，先建一条"脏数据流水线"

2.1 先认识脏数据的四种典型死法

数据分析里最枯燥也是最要命的就是清洗，枯燥在于重复劳动，要命在于清洗错一步，后面所有结论都可能报废。我把常见的脏数据归成四类：

• 缺失值：字段直接空着，比如用户的手机号没填、订单金额为NULL。处理方式不能一概而论，得先看缺失比例和分布。
• 重复值：同一笔订单出现了两次，或者同一个用户因为多渠道注册被存成了两行。如果不做去重，计数类指标就会虚高。
• 异常值：一个人一个月下单1000次，单笔金额100万，这种要么是测试数据，要么是刷单。不处理会让均值严重失真。
• 格式混乱：日期有“2024-01-15”也有“2024/1/15”，手机号有带区号的有不带区号的，费用里混着“元”和“万元”。这种是最烦人的，因为肉眼不好查。

没有固定的清洗顺序吗？有。我习惯的顺序是：先查格式和重复，再处理缺失和异常。因为格式统一之后，去重才可能做对；重复去掉之后，缺失和异常的比例计算才准确。顺序反了，统计出来的缺失率可能是错的。

2.2 Excel清洗：几万行以内的高效姿势

我最早也是Excel重度用户，数据量小的时候，Excel数据分析是效率之王。几个常用操作你得玩熟：

• 分列：按分隔符拆字段，比如把“城市-门店-编码”拆成三列，用“数据-分列”即可，不用写公式。
• 删除重复值：选中关键列，点击“数据-删除重复值”，但要先想清楚去重的唯一键是什么，是按订单号，还是按用户ID加时间。
• 条件格式：用颜色把异常值标出来，比如金额大于50000的标红，比做散点图找离群点快得多。
• Power Query：Excel 2016以上自带，适合做合并查询和追加查询。比如把1月和2月的销售表合并成一个表，用Power Query比写VLOOKUP优雅得多。

但Excel有个致命弱点：动作很难复现。你手动去重、改格式、填充缺失，每一步都靠记忆，半个月后想复盘“当时是怎么处理的”，全都想不起来了。而且数据量超过几十万行之后，Excel会明显变卡，多个sheet联动时常卡死。所以Excel适合做快速探索和临时分析，一旦要认真交付项目，我还是建议切到Python。

2.3 Python清洗三板斧：从pandas到一份可复跑脚本

Python里做清洗，pandas是绕不开的。我不打算给你堆API，就讲一套我自己反复用、也推荐团队用的最小方案，代码如下：

python复制import pandas as pd

# 1. 读取数据，先看一眼概览
df = pd.read_csv("raw_data.csv")
print(df.shape)
print(df.info())
print(df.isnull().sum())

# 2. 格式统一：日期、字符串、数值
df["order_date"] = pd.to_datetime(df["order_date"], format="mixed")
df["user_id"] = df["user_id"].astype(str).str.strip()
df["amount"] = pd.to_numeric(df["amount"], errors="coerce")

# 3. 去重：基于订单号去重，保留第一条
df = df.drop_duplicates(subset=["order_id"], keep="first")

# 4. 缺失值处理：金额缺失按业务用中位数填充，渠道缺失单独标为"未知"
df["amount"] = df["amount"].fillna(df["amount"].median())
df["channel"] = df["channel"].fillna("未知")

# 5. 异常值处理：用IQR方法标记极端值
Q1 = df["amount"].quantile(0.25)
Q3 = df["amount"].quantile(0.75)
IQR = Q3 - Q1
lower = Q1 - 1.5 * IQR
upper = Q3 + 1.5 * IQR
# 不直接删，先标记，让业务方确认
df["is_outlier"] = (df["amount"] < lower) | (df["amount"] > upper)

# 6. 输出清洗报告
clean_report = {
    "原始行数": len(df),
    "处理后行数": len(df[~df["is_outlier"]]),
    "缺失金额数": df["amount"].isnull().sum(),
}
print(clean_report)

这段代码有两个地方值得细说。第一，缺失值填充为什么用中位数而不是平均值？因为金额这类数据通常右偏，少数大额订单会把平均值拉高，用平均值填充相当于给缺失值强加了一个扭曲的分布；中位数更稳健。第二，异常值不要直接删，而是加一列标记，把“是否异常”这件事暴露给业务方，因为你觉得异常的数据，在业务眼里可能是真实的大客户。清洗不是把数据变成“你想要的形状”，而是把数据处理逻辑透明化。

2.4 非程序员的AI辅助路线：用Dify做数据清洗

我知道很多人看到pandas就头皮发麻，尤其是纯业务背景的同事。这两年低代码、AI应用平台慢慢多了起来，比如Dify这类工具，确实可以拿来做一部分数据分析清洗工作。

Dify本身是一个大模型应用开发平台，它更擅长的是处理非结构化文本和做一些流程化的数据编排。比如你有一批用户反馈文本，需要先做敏感信息脱敏、再按意图分类、最后提取关键字段，原来的做法是写正则表达式或者调一堆接口，现在可以在Dify里搭一个可视化工作流：上传文件，配置几个节点，让模型按提示词完成清洗和结构化输出。这个过程确实比写Python门槛低。

但要注意，别把它当成万能的。对于需要精确计算、大规模数值处理的表格数据，Dify这类大模型工具的输出是概率性的，它可能把997当999，也可能漏掉一行。我的建议是“分工明确”：数值型清洗、去重、去异常，用Python或SQL；文本清洗、格式归并、简单打标，可以试试用Dify这类工具加速。版本管理和可复现性依然是Python占优，AI工具适合一次性、低精度要求的场景。

2.5 清洗验收：把每一步都留痕

清洗做完不算完，必须有一份清洗报告，不然项目上线后出了问题，你根本不知道是清洗的锅还是上游数据的锅。我自己的模板很简单，就三块：

• 数据概况：原始表行数、列数、各字段缺失比例、重复行数。
• 清洗动作：每一步做了什么、影响了多少行。比如“删除重复订单321条，中位数填充金额缺失89条，标记异常订单45条”。
• 数据质量结论：这份数据是否可以直接用于后续分析，还有哪些字段因为质量太差不建议使用。

这份清洗报告不需要长，但一定要跟着数据走。我在实际工作中吃过亏：有一次没有记录清洗步骤，两周后上游数据刷新了，重跑脚本发现结果对不上，差点背锅。后来再也不敢不写清洗报告了。数据清洗做得好的标志，不是处理完之后数据有多“干净”，而是任何一步处理都能被人复现、被审计。

3. 单机装不下了再上Spark：一个离线分析案例的设计复盘

3.1 什么时候应该从pandas换到Spark

很多人在简历里写“熟悉Spark数据分析”，但实际项目里公司数据量小得可怜，pandas跑几秒就出结果了，非要上Spark，纯属给自己找麻烦。我判断是否要用Spark的核心标准就三条：

• 单表数据量是否超过单机内存：比如你的机器16G内存，表有40G，pandas读进来直接OOM。
• 单次计算时长是否超过30分钟：如果pandas跑一个groupby要半小时以上，说明数据和计算复杂度已经不适合单机了。
• 是否需要多人共享同一份计算资源：如果数据都在HDFS或S3上，大家用Spark集群统一算，比各自下载到本地方便得多。

新手最容易犯的错是拿“数据量大”当理由，但数据量大到一定程度、比如几十GB，pandas确实跑不动，可你首先要想的是能不能做预聚合、能不能只取需要的列，而不是直接抬高技术栈。只有在单机优化已经做到位、SQL逻辑分明但资源依然不够时，再上分布式才是合理的。

3.2 一个Spark离线数据分析案例的骨架

我做过一个游戏日志的离线分析项目，每天大概产生1.5亿条事件日志，要统计用户次日留存率。数据量很大，日志散落在几十个parquet文件中，Spark是天然适合的选择。核心代码其实不复杂：

python复制from pyspark.sql import SparkSession
from pyspark.sql.functions import col, countDistinct, to_date

spark = SparkSession.builder.appName("daily_retention").getOrCreate()

# 读取分层好的parquet日志
df = spark.read.parquet("hdfs:///logs/game/2024/")

# 只需要关键字段，减少扫描成本
df = df.select("user_id", "event_name", "event_time") \
       .filter(col("event_name").isin("app_open", "register"))

# 按天和事件类型聚合
daily = df.withColumn("date", to_date(col("event_time"))) \
          .groupBy("date", "event_name") \
          .agg(countDistinct("user_id").alias("uv"))

# 通过自关联计算次日留存
reg = daily.filter(col("event_name") == "register") \
           .selectExpr("date as reg_date", "uv as reg_uv")
open_next = daily.filter(col("event_name") == "app_open") \
           .selectExpr("date as open_date", "uv as open_uv")

retention = reg.join(
    open_next,
    reg.reg_date == open_next.open_date - 1,
    "left"
).select(
    reg.reg_date,
    (open_next.open_uv / reg.reg_uv).alias("next_day_retention")
)

retention.write.mode("overwrite").parquet("hdfs:///output/retention")

这个案例里有几个工程细节很关键。第一，parquet列式存储能大幅减少读取量，日志表几十个字段，分析只需要三个字段，用parquet的列裁剪只扫这三列，速度能提升一个量级。第二，所有过滤条件尽量往下推，比如只处理“app_open”和“register”两类事件，越早过滤，后面计算的数据量越小。第三，聚合先用countDistinct，可能导致shuffle量很大，但游戏日志场景下用户数不算夸张，能接受；如果用户量达到十亿级，就需要改用HyperLogLog近似去重，节省大量网络传输。

3.3 数据工程里最值得注意的三个优化点

做这类离线分析，与其把精力花在研究各种新框架上，不如先把三个基本功做好：

这三个点能解决绝大部分Spark作业慢的问题。我遇到过太多人，写了看起来很牛的复杂代码，结果慢在每天全表扫描同一个大文件夹，明明只要一个分区就能搞定。数据工程这种东西，不靠炫技，靠的是基本功扎实。

3.4 离线数据分析和实时分析的界限

热词里经常看到“离线数据分析”，很多人觉得这是过时技术，实时才是未来。但实际上，大多数业务决策根本不需要实时。留存率、复购率、用户画像这些指标，T+1的离线分析完全够用，而且离线任务可以跑更复杂的逻辑，比如全量回溯、实验评估。真正的实时分析只用在风控拦截、异常监控这些对时效性要求极高的场景。所以不要一听离线就觉得落后。选择的原则只有一条：业务需要在数据产生后多久内做出反应？几分钟内需要反应的，上实时；一天内能接受的，老老实实做离线。把简单的需求做复杂，是项目失败的好方法。

4. 做出来的图表没人看？可视化要跟着业务逻辑走

4.1 选图表之前先问"要对比什么"

数据可视化最大的坑，不是不会写代码，而是没有想清楚这张图要回答什么问题。我见过有人拿饼图展示连续三个月销售额趋势，观众看着一圈一圈愣是不知道是在涨还是跌。图表选型其实可以很机械，先问自己：我要做对比、看构成、看分布，还是看趋势？然后直接对照下表：

记住一个原则：一张图只讲一件事。如果你什么都想表达，那就拆成多张图，而不是塞进一张图里。业务汇报的时候，多图拼接但每张图各说一件事，效果远好于一张花花绿绿的大杂烩。

4.2 Python可视化的两套打法

Python数据分析与可视化是很多人的入门标配，但这里有个容易犯迷糊的地方：matplotlib、pandas、seaborn、Plotly到底怎么选？我的习惯是这样的：

• 快速探索：直接用pandas内置的plot方法，几行代码出图，比如 df.plot(kind="line")，适合自己看。
• 正式交付：用matplotlib或seaborn精细控制，配色、图例、文字都能改。
• 交互式汇报：用Plotly，鼠标悬停看数据，适合放到网页或Dashboard里。

举个最简单的分组柱状图示例：

python复制import pandas as pd
import matplotlib.pyplot as plt

# 假设有一个月度分渠道销售表
df = pd.DataFrame({
    "月份": ["1月", "2月", "3月"],
    "线上": [120, 135, 150],
    "线下": [80, 78, 85],
})

df.plot(x="月份", kind="bar", figsize=(8, 5))
plt.title("各渠道月度销售额对比")
plt.ylabel("销售额（万元）")
plt.xticks(rotation=0)
plt.legend(title="渠道")
plt.tight_layout()
plt.show()

这张图胜在简单，一眼能看出线上和线下渠道的对比关系。但这里有个细节，很多人会忽略：y轴要不要从0开始？对于柱状图，y轴必须从0开始，否则柱子长度比例会误导人。而折线图有时候为了展示波动，可以截断y轴，但必须标注清楚。这种细节决定了你的图表是“专业图表”还是“业余图表”。

4.3 汇报页的"结论先行"叙事结构

图表做得好看，不代表汇报有效果。我见过太多汇报是把所有图从头到尾放一遍，讲到第五张，听众已经忘了第一张讲的是什么。业务汇报的正确结构应该是“结论先行”：

• 第一页：直接说结论，比如“本月复购率下降5%，主要影响来自华南区老用户”。
• 第二页：放一张核心趋势图，证明这个结论。
• 第三页：拆解原因，用维度对比图说明为什么是华南区、为什么是老用户。
• 第四页：给出行动建议，比如“建议对华南区老用户做一次召回活动，预算控制在10万以内”。

这个顺序背后的逻辑是：人的注意力在开场前3分钟最集中，如果你不先把结论亮出来，对方就会带着自己的疑问听你讲，很容易跑偏。我在公司内部做过一个实验，同样一份分析，改成结论先行之后，业务方提的“然后呢”少了八成，因为他们基于结论直接讨论行动方案了。

4.4 我踩过的可视化坑

最后说几个我真实踩过的坑，希望你别再踩。

• 双Y轴滥用：把销售额和毛利率放在同一张图，左右两个轴，看起来两条线趋势相似，其实量纲完全不同，很容易得出错误结论。能不用双Y轴就不用，一定要用，必须明确标注。
• 3D图华而不实：3D饼图、3D柱状图看着炫，但人眼对深度距离的感知很弱，第三维基本是噪音。数据分析要的是信息密度，不是视觉效果。
• 颜色含义混乱：在没有约定俗成语义的情况下，不要随意给同一类维度用红绿双色。比如把正增长和负增长用红绿标，在中国用户习惯里绿色是正向，但有些人会觉得红色才是正向。最好在正文里明确图例。
• 坐标轴截断不标注：你截断y轴是为了突出波动，但如果不标注截断符号，读者会按比例误解差异大小。

可视化不是艺术创作，是信息传达。每一次配色、每一个轴、每一处标注，都应该服务于“让读者更快抓住关键信息”这个目标。

5. 从金融风控到足球分析：行业数据项目的套路都一样

5.1 金融风控数据分析的常规盘面

金融风控数据分析一直是大热门，但很多新人以为风控就是建模、调参、刷AUC。实际工作中，风控数据分析包含大量“清洗+监控+解释”的活。我参与过某互联网银行的数据分析笔试和项目，题目往往是“给一份逾期用户数据，分析逾期特征并给出策略建议”。这类题考的不是你会不会逻辑回归，而是你能不能把分析落到风控策略上。

风控领域有几个绕不开的指标：逾期率、通过率、坏账率、KS值、AUC。其中逾期率和通过率本身就是矛盾指标，收紧审批会降低逾期率但也会减少业务量，分析的价值就在于找到那个平衡点。无监督学习在风控里也常用，比如用聚类做客户分群，观察不同群体的逾期表现，找出潜在风险客群。但在业务上，我们更关心的是“这群人有什么特征、从哪里来、应该怎么处理”，而不是聚类算法本身。

做风控数据分析，最核心的一条经验是：不要把“模型预测高风险”直接等同于“拒绝这个人”。分析报告的落点应该是“这个客群的风险溢价是否值得接受”，而不是非黑即白的“通过或拒绝”。这种思路，和很多行业的数据分析是相通的。

5.2 足球数据分析：从"印象流"到用xG说话

足球数据分析是很有意思的跨界方向，也能看出数据分析思维在不同领域的差异。以前大家看比赛都说“某队控球率高所以强”，但用数据分析的眼光看，控球率和赢球之间的相关性并没有想象中高。现在比较受认可的是xG（预期进球），它衡量的是每次射门的得分概率，能更客观地反映机会质量。

举个例子，我曾经分析过某支球队的数据：A队全场射门20次，B队射门8次，比分却是B队2比0赢。只看射门数会觉得A队可惜，但看xG数据，A队20次射门的总xG只有0.8，说明大量射门都是远射和角度很小的勉强打门；B队8次射门里有3次是绝佳机会，总xG达到2.1，赢球其实是合理的。这个案例特别适合用来理解“数据不能只看表面指标，要深挖指标背后的生成逻辑”。

足球数据分析和金融风控听起来风马牛不相及，但分析框架高度一致：先定义业务目标（赢球还是控制风险），再找关键过程和结果指标（xG还是逾期率），然后拆分影响因素，最后形成可执行的策略。这里用到的依然是“假设-数据-验证-结论”这条老路。

5.3 跨行业可复用的分析框架

从金融风控到足球，再到零售、游戏，我越来越觉得数据分析的“术”千差万别，但“道”是一致的。我自己总结了一个五步框架，每次接新项目都会拿出来套一遍：

1. 业务理解：用一句话说清楚这次分析要帮业务方做什么决定。
2. 数据准备：列出需要的数据，检查和清洗，写清洗报告。
3. 分析建模：从描述性统计开始，再看要不要做预测或分群。
4. 结果解读：把模型系数、聚类中心翻译成业务语言。
5. 决策落地：给出建议动作、预期收益、风险评估。

这套框架看起来很简单，但真正能每一步都做扎实的人不多。大多数项目挂在第1步和第5步：一开始没想清楚业务问题，最后给了一堆结论但没法落地。如果你觉得自己项目经验不够，试着多找几个不同行业的案例，用这个框架去拆解，你会发现套路真的都一样。

6. 笔试面试不刷题，数据分析师到底在考什么

6.1 笔试题目背后的三层能力

很多人准备数据分析笔试，就是疯狂刷SQL题、背机器学习公式。但真实笔试，尤其是互联网银行、金融科技公司的数据分析岗，考的是三层能力：取数准确性、统计直觉、业务思维。

我印象很深的一道笔试题目是这样的：给你一张用户还款表和一张借款表，统计逾期率。看起来很简单，但里面埋了三个坑：一是金额单位不统一，有的“元”有的“万元”；二是“逾期”口径没定义，是按逾期天数还是按逾期金额占比；三是去重逻辑，同一用户多笔借款怎么算。答完这道题，基本就能看出这个人有没有数据分析实战经验，而不只是会不会写SQL。

所以笔试准备不建议只刷题，更建议把手边真实项目里的每一个指标口径、每一次去重逻辑、每一段清洗步骤都复盘一遍。我面过一些候选人，SQL写得很溜，但问他“这个去重为什么按用户ID而不是订单号”，他就答不上来了。数据分析笔试的终点不是算出数，而是证明你算的数是靠谱的。

6.2 案例面试答题结构：从"某APP次日留存下降5%"说起

案例面试几乎是数据分析面试的标配，常见的题目是“某APP的次日留存率下降了5%，你怎么分析”。这种题没有标准答案，但考察的是你的分析框架。

我建议用一套固定的结构来回答，既不会乱也不容易漏：

• 先确认口径：下降5%是用户维度还是设备维度？是新增用户还是全体用户？时间范围是不是自然日？
• 再拆维度：按渠道、版本、机型、地区、新老用户拆开看，找到主要集中在哪个维度。
• 提出假设：比如“是XX渠道买量质量下降”“是新版本iOS端注册流程改版导致流失”。
• 给验证方案：用数据验证这些假设，比如对比渠道投放前后留存变化、查看新版注册流程的漏斗转化率。
• 落到行动：如果假设证实，建议是暂停渠道投放或回滚版本；如果假设证伪，继续迭代。

面试官想听到的不是你直接猜到原因，而是你面对一个模糊问题的思考路径。所以哪怕你心里没底，也一定要把过程说出来，“我觉得可能需要先看看……”这种表达比沉默然后憋一个错误答案好得多。数据分析面试题本质上是在考察你逻辑的完整性，而不是标准答案。

6.3 面经里的高频误区：堆模型、背指标、不落决策

我刷过很多数据分析面经，也做过面试官，发现候选人最容易踩的坑有三个：

• 第一个误区：拼命堆模型。一上来就是“我要用XGBoost、用深度学习”，但业务问题还没讲清楚。面试官其实更想看到你会不会先用分组对比、透视表做探索。
• 第二个误区：指标背诵。能说出“留存率 = 次日留存用户数 / 当日新增用户数”，但不知道这个指标在什么场景下会失真。比如说，如果某一天买了大量低质渠道流量，次日留存率会被拉低，但你可能会误判成产品问题。
• 第三个误区：不落决策。分析到最后只说“我们发现用户活跃度下降”，但不提“建议做XX”。面试官问“所以呢”，很多人就卡住了。

我自己的经验是，每当分析一个东西，我都强制自己回答“所以需要做什么动作”。哪怕最后建议是“暂不行动”，那也是一种决策。因为数据分析师真正区别于“取数工具人”的地方，就是能不能从数据里走到决策层。关于这一块，我下一篇会展开讲一个完整的留存分析案例，从取数到清洗再到输出建议，到时候你可以拿这个框架亲手练一遍。