Python电商用户消费行为分析：从RFM模型到留存漏斗实战

1. 先把话说清楚：电商用户消费行为分析到底在解决什么问题

做电商数据分析这几年，我几乎每隔一段时间就会遇到同一个问题：后台报表一堆，日活百万，订单量几十万，可运营同学拿着这些数却不知道怎么动手。大家最常问的是三句——“哪些用户最值钱？”“他们什么时候会走？”“我该拿什么策略去留住他们？”

这其实就是用户消费行为分析要回答的事。用Python去拆解的，不是那些“今天卖了多少单”的汇总数字，而是把用户从注册、首单、复购到沉默流失的全过程，用数据重新讲一遍。核心对象是三个字：用户、行为、消费。把这三个词拆开，你就能得到一组分析主题：用户是谁、行为发生在什么节点、消费金额与频次如何变化。

所谓“基于Python”，并不是说Python有什么神秘的分析魔法，而是因为它把数据清洗、聚合计算、统计建模、可视化整条链路打通了。pandas处理订单明细，numpy完成指标计算，matplotlib/seaborn画分布图，scikit-learn做聚类分层，相当于一套工具扛下了从取数到出结论的全程。对于中文互联网环境下绝大多数电商业务，数据量级通常在百万到千万行订单、百G以内，“单机Python+关系型数据库导出”的组合完全够用，没必要一上来就上重型大数据框架。

我最想先纠正的一个误区是：跑数不是分析。“拉了一张表”和“得出一个可执行结论”之间，差着一整套业务理解和指标设计。比如同样是“客单价”，有人用GMV除以订单数，有人用GMV除以支付人数，还有人用GMV除以活跃用户数，三套口径出来的数字完全不是一回事。这就是为什么在聊代码之前，必须先聊分析框架。

1.1 为什么“跑数”不等于分析

很多刚入行的同学拿到订单表，第一反应是写一个groupby('user_id')['amount'].sum()，把用户消费总额排个序，然后输出Top100名单，觉得分析做完了。这其实只是“查询”。真正的分析需要回答：这个排名稳定吗？高消费用户是持续购买还是曾经爆发过一次？他们的复购间隔是多久？和低消费用户相比，他们在品类选择上有什么区别？

我接过的一个模拟项目里，运营最看重的是一批“高净值用户”，系统里标注的是累计消费金额Top10%。我拉出他们的消费明细一看，里面有接近四成用户只在某个大促节点买过一单大额商品，之后再也没有回来过。如果只看总额排序，这些人会被当成核心资产去维护，但实际上他们是一次性流量，价值远不如那些“消费金额中等、但每个月都买”的老用户。这就是“跑数”和“分析”的区别：分析是在数据之上加了一层业务解释。

所以，分析的第一步不是炫技，而是把业务问题翻译成可计算的指标，并且让这些指标经得起业务方的反问：“你这个‘流失’是怎么定义的？”“复购率的分母是哪些用户？”这些问题如果答不清楚，后面所有结论都站不住。

1.2 分析框架：四个核心维度

做用户消费行为分析，我习惯先搭一个四维框架，后续所有代码和结论都往框架里填。

• 用户价值维度：衡量用户给平台创造了多少收益，经典指标是累计消费金额、消费频次、最近一次消费时间，组合起来就是RFM模型（Recency, Frequency, Monetary）。
• 用户黏性维度：衡量用户是否持续回来，经典指标是留存率、复购率、活跃间隔、沉默周期。
• 用户行为路径维度：衡量用户在完成购买前的关键环节转化，经典指标是漏斗转化率（浏览→加购→支付）、品类偏好、购买频次分布。
• 用户生命周期维度：把用户分成新客、活跃期、衰退期、流失期等阶段，观察不同阶段的用户规模与贡献变化。

这些维度不是割裂的。一个完整的分析项目通常是：先定义口径和数据范围，然后清洗数据，接着用RFM做用户价值分层，再叠加留存和复购看黏性，随后用漏斗和品类偏好找增长机会，最后把所有结论汇总成运营可执行的策略清单。下面我按这条链路逐个展开，每一步都会给出可以“抄作业”的Python实现思路。

2. 数据准备与口径定义：结果准不准，全看这一步

做这套分析，最花时间的往往不是建模，而是把数据整理到能算的状态。很多同学拿到数据就开跑，结果算出来的复购率一会儿20%一会儿80%，最后发现是同一个用户ID在不同表里一个按字符串存、一个按数值存，join的时候全被拆散了。这种坑我踩过不止一次，所以现在每做一个分析项目，第一步永远是统一口径和清洗数据。

2.1 一份可用的订单数据长什么样

电商用户消费行为分析的底层数据，一般来自订单表和用户行为日志表。订单表至少需要包含这些字段：

如果要做漏斗分析，还需要用户的浏览日志、加购日志，通常以事件表格式存储，每条记录包含user_id、event_type（view/cart/pay）、event_time、product_id。日志表比订单表庞大得多，千万行起步很正常，所以数据清洗时的性能问题也要提前考虑。

2.2 清洗逻辑与指标口径

拿到原始数据后，我通常会按以下顺序清洗，每一步都会顺带校验业务口径。

第一，处理订单状态。只保留“已支付”“已完成”“已发货”这类正向状态。退款订单怎么处理要特别小心：我建议把退款额单独拆出来，而不是直接从GMV里减掉，因为“用户买了又退”和“用户根本没买”是两种完全不同的行为。如果项目只关注实际成交，可以用净成交额口径（实付金额减去退款的净额），但报表里要同时保留“订单金额”和“净金额”两个字段。

第二，时间统一。所有时间字段转为datetime类型，时区统一到东八区。特别提醒，跨年、跨月的凌晨订单容易在字符串转日期的过程中被截断，我遇到过一个案例，因为某个月份数据月首日缺失，导致该月“新客数”整整少算了一天。

第三，去重和异常值处理。同一用户短时间内重复下单并不代表恶意，但要和刷单区分开。我通常先查看单用户单日下单次数分布，如果超过一个业务上不可能的频率（比如一小时下50单），就会标记出来单独评估。金额字段出现负数时要特别警惕，可能是退款未标记，也可能是测试订单。

第四，明确指标口径。这一步必须在写代码之前完成，否则后面全是返工。我把常用的几个口径固定成下表，后续分析一律照此执行：

提示：复购率有两种常见算法。一种是“某周期内完成过一次购买的人中，有多少人在下个周期又买了”，另一种是“所有成交用户中，购买次数大于1的人占比”。前者是行为追踪逻辑，后者是存量结构逻辑，两者用途不同，公布结论时一定要说明自己用的是哪一种。我做留存分析时用前一种，做用户结构盘点时用后一种。

3. 用户价值分层：RFM模型落地与分群策略

RFM是用户消费行为分析里最经典的模型，没有之一。它只用三个字段，就把“用户值不值得运营”这件事拆成了三个可量化的问题：你多久没来了？你来了几次？你花了多少钱？

3.1 RFM的核心逻辑与阈值设定

R（Recency）指最近一次消费距今的天数，越小说明用户越“新鲜”；F（Frequency）指一段时间内消费频次，越高说明用户越依赖平台；M（Monetary）指累计消费金额，越高说明用户消费能力越强。

把这三个维度分别分成高低两组，就得到八个用户群：

阈值设定是RFM落地过程中最容易被拍脑袋的部分。常见做法有两种：一种是按业务经验给固定值，比如“90天没有购买算流失”，但不同品类的购买周期差异极大，大件商品用户一年买一次也正常；另一种是分位数法，用数据说话。我更推荐第二种，把R、F、M各自的50%分位线作为中位数阈值，低于中位数叫“低”，高于中位数叫“高”。这样做的好处是，分群结果天然形成“一半一半”的对比，业务方容易理解。

3.2 Python实现：从订单表到价值标签

下面给出一个可以直接套用的实现。数据以DataFramedf表示，至少包含user_id、pay_time、amount三个字段，且已经完成了第二章说的清洗。

import pandas as pd import datetime as dt # 假设df已经清洗完成，pay_time为datetime类型 # 选择一个分析截止日期，用于计算R值 analysis_date = df['pay_time'].max() + pd.Timedelta(days=1) # 按用户聚合三个指标 rfm = df.groupby('user_id').agg( last_purchase_date=('pay_time', 'max'), # 最后一次消费时间 frequency=('order_id', 'count'), # 消费次数，也可以改用nunique去重 monetary=('amount', 'sum') # 累计消费金额 ).reset_index() rfm['recency'] = (analysis_date - rfm['last_purchase_date']).dt.days rfm.drop('last_purchase_date', axis=1, inplace=True) # 分位数打标签 def rfm_score(series, reverse=False): # reverse=True表示数值越小越好（R），这时低于中位数给1分 median = series.median() if reverse: return (series <= median).astype(int) return (series > median).astype(int) rfm['R_score'] = rfm_score(rfm['recency'], reverse=True) rfm['F_score'] = rfm_score(rfm['frequency']) rfm['M_score'] = rfm_score(rfm['monetary']) # 组合标签 rfm['segment'] = ( rfm['R_score'].astype(str) + rfm['F_score'].astype(str) + rfm['M_score'].astype(str) ) segment_map = { '111': '重要价值用户', '110': '重要发展用户', '101': '重要保持用户', '100': '一般发展用户', '011': '重要挽留用户', '010': '一般挽留用户', '001': '重要唤回用户', '000': '一般唤回用户' } rfm['user_type'] = rfm['segment'].map(segment_map)

这段代码里，recency的计算是核心。我用的是“分析截止日期-最后消费日期”，而不是“今天-最后消费日期”，因为分析一批历史数据时，日期应该锚定在数据末端，否则随着时间推移每次重跑结果都不一样，没法对比。

分群做完之后，别急着交差。我会做三件额外的事：

• 统计每个用户群的人数、消费总金额、人均消费，看头部用户群的收入贡献是否真的突出。往往你会看到10%的用户贡献了50%以上的GMV，这个结论本身就可以单独输出。
• 画R、F、M的分布图。三维指标基本都是长尾分布，直接看数字看不到，画出来更直观。
• 把“连续三个月都存在用户群规模变化”做成趋势图，观察高价值用户有没有在持续萎缩。

RFM有一个天然盲区：它只看用户整体的金额和频次，区分不出“消费力强但只买打折货”和“原价买了很多”的人。所以实际项目中，我通常会在RFM之上再叠加一个指标——客单价和折扣敏感度。如果数据里有优惠券金额字段，可以算“优惠金额占订单金额比”，高于某个阈值的用户即使M值高，运营时也要考虑他们的利润贡献。

4. 留存与复购：衡量用户黏性的两个关键指标

如果说RFM解决的是“用户现在值多少钱”，那留存和复购解决的就是“用户未来还能不能继续值钱”。很多电商项目死于一个错觉：拉新特别猛，月流水特别好看，但把时间拉长看，新客里能活过三个月的不到20%。留存率就是把这层窗户纸捅破的指标。

4.1 留存率的正确计算姿势

留存率的定义不复杂：某天（或某周、某月）新增了一批用户，这批用户在之后第N天还有多少比例回来，就是N日留存率。但落地时有几个细节特别容易出问题。

第一个细节：留存的“回来”指什么？我建议区分“活跃留存”和“付费留存”。活跃留存在有行为日志时用，指用户在后续第N天有过任意行为；付费留存只看订单表，指用户在后续第N天有过支付成功行为。付费留存对电商更有业务意义，因为用户逛了不买，对收入贡献为零。

第二个细节：留存统计的时间粒度。新客数量少的平台不建议按天算，今天新增30人、明天留存3人，算出来的留存率波动极大。这时候按周或按月较稳定。具体选择看业务节奏，有大规模促销活动的平台，按周更合理。

下面给一个计算“按日新增用户的7日付费留存”的核心代码。

# 新增用户表：新客首次支付日期 first_pay = df.groupby('user_id')['pay_time'].min().reset_index() first_pay['first_date'] = first_pay['pay_time'].dt.date new_user_cohort = first_pay.groupby('first_date').agg( new_user_cnt=('user_id', 'nunique') ).reset_index() # 所有支付记录 df['pay_date'] = df['pay_time'].dt.date # 把支付记录和首次支付日期对齐 df_merged = df.merge( first_pay[['user_id', 'first_date']], on='user_id', how='left' ) # 计算支付日期距离首次支付日期的天数 df_merged['day_diff'] = (df_merged['pay_date'] - df_merged['first_date']).dt.days # 计算每个新增批次在第N天的付费用户数 retention_days = [1, 3, 7, 14, 30] retention_result = [] for day in retention_days: day_users = df_merged[ (df_merged['day_diff'] == day) ].groupby('first_date')['user_id'].nunique().reset_index() day_users.columns = ['first_date', 'retained_cnt'] result = new_user_cohort.merge(day_users, on='first_date', how='left') result['retained_cnt'] = result['retained_cnt'].fillna(0) result['retention_rate'] = result['retained_cnt'] / result['new_user_cnt'] result['retention_day'] = day retention_result.append(result) retention_table = pd.concat(retention_result)

这段代码的关键点是day_diff的计算。用“支付日期-首次支付日期”而不是“记录时间-首付时间”，避免了跨天边界影响。另外，分母永远是“该批次新增用户数”，而不是“该批次活跃用户数”，这两者差别很大。曾经有个同事把分母搞成了“第N天还在使用的用户”，算出来的留存率高达90%多，被业务老大当场问倒，场面很尴尬。

4.2 复购周期与流失预警

留存率看的是“群体视角”，复购分析则更偏向“个体行为节奏”。我最常用的两个指标是“回购率”和“平均回购间隔”。

回购率我习惯这样算：观察周期（比如一个月）内成交的用户中，有百分之多少的人在下一个观察周期内再次成交。代码上就是“本月付费用户”和“下月付费用户”取交集，除以“本月付费用户”。

平均回购间隔则是对同一个用户的多次购买时间做差，求出平均间隔。这个指标能直接指导“沉默期多久算流失”。举个例子，某平台用户的平均回购间隔是45天，那么一个用户60天没下单，就已经明显偏离正常节奏，可以启动召回；但如果平均间隔是180天（比如低频高客单价的家具类目），那“90天没买就标记流失”显然不合理。

流失预警不需要等用户真正流失才做。我常用的一个简单方法是“按用户最近一次活跃距离今天的天数分桶”，统计每个桶里的用户占比和这个桶的历史回购率。你会发现，随着天数增加，回购率一路下降，到某个时间点之后几乎不再回升。那个时间点就是流失拐点。

举个例子，我分析过一组数据：用户最近一次购买后第7天、第14天、第30天、第60天、第90天的存量用户各自的历史回购率分别是58%、46%、31%、15%、6%。第60天以后回购率断崖式下跌。于是“60天未回访”被定义为该业务的流失阈值。这个闸口一旦确定，运营就能把它嵌入自动化召回流程，不必每周人工捞数。

注意：流失阈值不是拍脑袋决定的，而是从数据里看出来的。分析报告中如果只写“我们定义90天未购买为流失”，却不解释为什么是90天，业务方大概率不认这个结论。把你的回购率衰减曲线画出来，让数字自己说话。

5. 转化漏斗与品类偏好：从行为数据里找出增长机会

用户价值分层和留存分析回答的是“哪些人值得运营”，这一部分回答的是“这些人为什么不买更多”。转化漏斗把用户从进店到成交的过程拆开，找出环节之间的流失；品类偏好则决定你该用什么样的商品去打动用户。

5.1 漏斗分析的边界与口径

标准电商漏斗是“曝光→点击→详情页→加购→支付”，但很多分析团队拿不到全部环节的数据。如果手里只有日志表的浏览、加购、支付三类事件，也能做一个简化版漏斗：浏览→加购→支付。

做漏斗时最重要的不是每个环节的人数，而是相邻两个环节之间的转化率。计算逻辑很简单：

event_data = ... # 列：user_id, event_type, event_time events = event_data.groupby(['user_id', 'event_type'])['event_time'].nunique().reset_index() # 统计各环节事件人数 funnel = events.groupby('event_type')['user_id'].nunique() # 计算相邻环节转化率 num_view = funnel.get('view', 0) num_cart = funnel.get('cart', 0) num_pay = funnel.get('pay', 0) view_to_cart_rate = num_cart / num_view cart_to_pay_rate = num_pay / num_cart

逻辑很简单，但有几个口径坑。第一，“pay”环节用支付成功事件还是支付订单数？漏斗讲究的是“人数路径”，一个用户下两单也只算一个人，所以必须先user_id去重再算事件人数。第二，事件之间的时间窗口如何设定？用户A今天浏览，明天加购，后天支付，算不算同一漏斗？我通常设定一个“会话周期”统一口径，比如“浏览后7天内支付的用户都算作从浏览进入购买路径”。不做这个限制，漏斗每个环节会被人为拉平，看不出真实衰减。

漏斗分析发现机会之后，一定要落到人群和商品上。比如团队曾发现“加购→支付”的转化率比行业水平低一大截，进一步拆解发现，支付转化率低的用户集中在大促前两周加的购物车。他们加购的是预售商品和赠品单，大促开始后居然是降价了，但用户反而犹豫不决，转化被拖到最后一波才爆发。如果没有漏斗，这个规律很难被发现。

5.2 品类偏好与购物篮分析

用户买了什么、不买什么，直接决定运营策略。品类偏好最简单的分析是“每个用户订单里类目的分布”，用交叉表加占比来完成。进阶一点可以做“类目组合分析”，看哪些品类经常被一起购买。

购物篮分析最常用的算法是关联规则中的Apriori，但在极大规模数据上直接用现成库会比较吃力。不过如果只关注两个类目间的共同购买关系，可以用pandas自己算：

# user_id × product_category 的购买关系 user_cat = df.groupby(['user_id', 'product_category'])['order_id'].count().reset_index() user_cat = user_cat[user_cat['order_id'] > 0] # 交叉表：每个用户买过哪些类目 cross = user_cat.pivot_table( index='user_id', columns='product_category', values='order_id', fill_value=0 ) # 转成布尔矩阵：买过为1，没买过为0 cross_bool = (cross > 0).astype(int) # 计算任意两个类目的共同购买用户数 co_occurrence = cross_bool.T.dot(cross_bool) # 计算类目A→类目B的置信度 support_A = cross_bool.sum(axis=0) confidence = co_occurrence.div(support_A, axis=0)

置信度的意思是：买过类目A的用户里，有多少比例也买过类目B。这个指标可以直接转化成运营动作，比如“买过婴儿推车的用户，有63%也购买过婴儿辅食”，那么推车订单完成页上推荐辅食，就是合理设计。

不过我要多说一句：关联规则里的“强规则”不等于“因果”。可能两个类目同时被买，只是因为在同一个促销会场里展示。所以购物篮分析的结果必须回到业务现场验证，不要全盘照搬。

6. 数据量变大的性能优化实操

这一章节是纯经验篇。订单数据从几十万行往几百万、几千万行进时，同样的pandas代码运行时间会从秒级变成分钟级，再变成“跑到一半内存爆炸”。很多人一遇到数据量大就想着换Spark，但实际上大部分电商私域分析场景，单机Python优化一下完全够用。

6.1 先别急着上Spark，pandas还能再救一下

先说结论：如果数据在单机内存的2-3倍以内，先尝试优化pandas代码；如果超过这个量级，再考虑换分布式方案。因为Spark的引入意味着整个技术栈复杂度上了一个台阶，数据分析这种迭代频繁、结论快速变化的场景，性能提升不一定能抵消运维成本。

我见过最典型的性能杀手是“全表暴力遍历”。比如判断用户类型时，有人写一个for i in range(len(df))，一行行if-else，跑几百万行数据耗掉二十分钟。而用np.where或pandas.cut向量化操作，同样的逻辑只需要几秒。pandas和numpy的设计哲学就是“能向量化就向量化，绝不逐行处理”。

6.2 几个立竿见影的内存优化手段

第一个手段是数据类型压缩。订单金额字段在数据库中经常被存成float64，实际上金额精确到分的话，用int32或float32就够了。用户ID如果是纯数字，从object类型转成int32能节省大量内存。这一步用.astype()一行搞定。

第二个手段是用category类型压缩枚举字段。产品类目、订单状态、渠道来源这类低基数字段，转成category后内存占用能减少一半以上。字符串类型的user_id如果有几千万个唯一值，用category反而更占内存，这一点要小心。

第三个手段是分块读取。如果数据量实在太大，直接用pd.read_csv()读取常会内存崩溃。可以分块读入后先做聚合再合并：

chunk_iter = pd.read_csv('orders.csv', chunksize=500000, parse_dates=['pay_time']) agg_list = [] for chunk in chunk_iter: # 只保留需要的字段，提前过滤无用行 chunk = chunk[chunk['status'].isin(['paid', 'completed'])] agg = chunk.groupby('user_id').agg( amount_sum=('amount', 'sum'), order_cnt=('order_id', 'count') ) agg_list.append(agg) summary = pd.concat(agg_list).groupby('user_id').sum()

第四个手段是尽早投影和过滤。数据读取后第一件事是drop掉用不到的列，然后立刻过滤业务无效行。每减少一列、一行，后面的所有计算都会加速。很多人在这一步偷懒，结果就是内存白白被无关数据占满。

第五个手段是把中间结果落盘。做RFM、留存、漏斗分析时，会产生多个中间表。如果内存吃紧，可以把中间表存成parquet格式，后面随时读回来，不用每次重算。parquet是列式存储，读入速度远快于CSV，我第一次从CSV切到parquet后，同样的数据加载从25秒降到3秒。

提示：大数据分析项目的时间开销常常不在算法复杂度，而在I/O和内存往返。把数据“读一次、洗一次、落一次盘”的顺序设计好，比盲目优化算法更有效。我自己现在做任何Python电商分析项目，第一步都是建一个data_processed.parquet，后面所有分析模块都从这个文件读数据，节省了大量重复清洗时间。

7. 从分析结果到运营动作：让结论真正落地

分析做得再漂亮，如果输出的是一堆图表和术语，业务方看完只会点头然后继续干原来的活。让分析结论真正发挥作用的关键一步，是把“我们发现了一个规律”翻译成“我们应该去做某件事”。

7.1 用户分层后的运营策略示例

结合RFM分层和留存分析，运营动作通常可以分为四类：维护、拉高、召回、舍弃。下面是我在一个模拟项目中实际用过的策略框架，供参考。

• 重要价值用户（R高F高M高）：这类用户不需要过多打扰，重点做权益保障。推送新品首发、会员日专属折扣、专属客服通道。切忌频繁发送低价促销短信，会拉低品牌在他们心中的价值感。
• 重要发展用户（R高F高M低）：购买习惯已建立，但消费力没释放。策略是品类拓展，从他们历史购买类目中找出关联类目，推送关联商品。
• 重要挽留用户（R低F高M高）：曾经的核心资产，现在正在流失。策略是定向召回券+电话/短信触达，召回成本可以设得比一般用户高，因为他们回来后的预期消费额大。
• 一般唤回用户（R低F低M低）：这类用户占比往往很高，但贡献有限。策略以轻量级触达为主，比如App push和大促短信，不建议投入人工客服成本。

分层后还要算一笔账：每个分层人群的运营预算上限是多少。计算方法很简单，用户历史年均贡献GMV × 预期挽回概率 × 毛利率。如果召回成本超过这个值，做再多也是亏钱。这笔账算清，运营和执行团队就能直接按规则批量操作，而不是凭感觉。

7.2 效果验证：不要只看短期GMV

策略落地后一定要验证，但验证方法不能只看“做了活动后GMV涨没涨”。GMV上涨可能来自自然增长，也可能只是把未来消费提前兑现了。我建议至少做三个维度的验证：

第一，人群对比。把目标分层人群和未触达的同属性人群做对照，看活动的净增量。可以用简单的“活动前7天均值 vs 活动后7天均值”的差，如果有条件，做A/B测试更可靠。

第二，用户行为变化。不只看到底买了没有，还要看是否改变了购买习惯。比如召回用户被发券后，如果只是“领券后买一单然后继续沉默”，那说明这次召回不改变他们的长期价值；反之，如果他们的回购间隔缩短、购买品类变宽，这才是真正的胜利。

第三，成本收益核算。把活动支出、商品折扣成本、履约成本全部记入，算出每个分层用户的净ROI。我见过一个项目，活动期间GMV很好看，一算净利是负的，因为折扣力度太大把老客的毛利都吃掉了。

验证结果反过来还会修正分析模型。比如某次运营发现“重要价值用户其实对价格敏感，收到大折扣券后复购不降反升”，这和最初“高价值用户不应该发大额券”的判断不一致，那么模型里的分群标签就要加入价格敏感度维度，重新调参。分析-落地-验证-迭代，这条闭环才是电商用户消费行为分析真正值钱的地方。

说到底，Python在这里的作用是帮我们把复杂数据变成可理解、可决策、可行动的信息。模型和代码都可以重写，但围绕业务问题的分析思路和落地方法，才是这套东西的长期价值。我自己做这类项目的习惯是：先花几天想清楚业务问题，再花一天清洗数据，最后用半天跑完分析和画图，剩下的大部分时间都在跟业务方反复确认结论和调整策略。这个顺序反过来的话，做得越快，错得越离谱。