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 一份可用的订单数据长什么样电商用户消费行为分析的底层数据一般来自订单表和用户行为日志表。订单表至少需要包含这些字段字段名含义关键注意事项order_id订单编号可能存在同一个订单拆成多个子订单的情况user_id用户ID需要确认匿名ID和登录ID是否统一order_time下单时间有时和支付时间不一致需明确用哪个pay_time支付时间分析消费行为建议以支付为准amount订单金额注意是否含运费、是否含退款status订单状态只有已支付/已完成才算有效消费product_id商品ID用于品类分析product_category商品类目层级类目需统一到同一粒度quantity购买数量结合金额可算实际单价如果要做漏斗分析还需要用户的浏览日志、加购日志通常以事件表格式存储每条记录包含user_id、event_typeview/cart/pay、event_time、product_id。日志表比订单表庞大得多千万行起步很正常所以数据清洗时的性能问题也要提前考虑。2.2 清洗逻辑与指标口径拿到原始数据后我通常会按以下顺序清洗每一步都会顺带校验业务口径。第一处理订单状态。只保留“已支付”“已完成”“已发货”这类正向状态。退款订单怎么处理要特别小心我建议把退款额单独拆出来而不是直接从GMV里减掉因为“用户买了又退”和“用户根本没买”是两种完全不同的行为。如果项目只关注实际成交可以用净成交额口径实付金额减去退款的净额但报表里要同时保留“订单金额”和“净金额”两个字段。第二时间统一。所有时间字段转为datetime类型时区统一到东八区。特别提醒跨年、跨月的凌晨订单容易在字符串转日期的过程中被截断我遇到过一个案例因为某个月份数据月首日缺失导致该月“新客数”整整少算了一天。第三去重和异常值处理。同一用户短时间内重复下单并不代表恶意但要和刷单区分开。我通常先查看单用户单日下单次数分布如果超过一个业务上不可能的频率比如一小时下50单就会标记出来单独评估。金额字段出现负数时要特别警惕可能是退款未标记也可能是测试订单。第四明确指标口径。这一步必须在写代码之前完成否则后面全是返工。我把常用的几个口径固定成下表后续分析一律照此执行指标推荐口径GMV支付成功的订单金额合计含税含运费净GMV支付成功的订单金额减去退款金额客单价净GMV / 支付成功订单数用户价值按净GMV统计的用户累计真实消费活跃用户当日在平台有任意行为记录浏览/加购/支付的用户付费用户当日在平台有支付成功行为的用户新用户首次支付时间落入统计周期的用户复购用户在统计周期内完成过两次及以上支付的用户提示复购率有两种常见算法。一种是“某周期内完成过一次购买的人中有多少人在下个周期又买了”另一种是“所有成交用户中购买次数大于1的人占比”。前者是行为追踪逻辑后者是存量结构逻辑两者用途不同公布结论时一定要说明自己用的是哪一种。我做留存分析时用前一种做用户结构盘点时用后一种。3. 用户价值分层RFM模型落地与分群策略RFM是用户消费行为分析里最经典的模型没有之一。它只用三个字段就把“用户值不值得运营”这件事拆成了三个可量化的问题你多久没来了你来了几次你花了多少钱3.1 RFM的核心逻辑与阈值设定RRecency指最近一次消费距今的天数越小说明用户越“新鲜”FFrequency指一段时间内消费频次越高说明用户越依赖平台MMonetary指累计消费金额越高说明用户消费能力越强。把这三个维度分别分成高低两组就得到八个用户群RFM用户类型典型画像初步运营方向高高高重要价值用户最近常来、买得多、花得多重点维护提供专属权益高高低重要发展用户活跃高频但消费力有限提升客单价做品类拓展高低高重要保持用户花钱大方但不常来增强粘性召回并促成复购高低低一般发展用户最近来过但消费弱培养购买习惯推送高性价比商品低高高重要挽留用户曾经很值钱但正在流失定向召回用权益唤醒低高低一般挽留用户曾经高频最近沉寂推送新品/活动观察响应低低高重要唤回用户买过大额但很久没来高价值召回专人触达低低低一般唤回用户即将被遗忘的边缘用户低成本触达能召回一个算一个阈值设定是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(days1) # 按用户聚合三个指标 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, axis1, inplaceTrue) # 分位数打标签 def rfm_score(series, reverseFalse): # reverseTrue表示数值越小越好R这时低于中位数给1分 median series.median() if reverse: return (series median).astype(int) return (series median).astype(int) rfm[R_score] rfm_score(rfm[recency], reverseTrue) 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]], onuser_id, howleft ) # 计算支付日期距离首次支付日期的天数 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, onfirst_date, howleft) 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( indexuser_id, columnsproduct_category, valuesorder_id, fill_value0 ) # 转成布尔矩阵买过为1没买过为0 cross_bool (cross 0).astype(int) # 计算任意两个类目的共同购买用户数 co_occurrence cross_bool.T.dot(cross_bool) # 计算类目A→类目B的置信度 support_A cross_bool.sum(axis0) confidence co_occurrence.div(support_A, axis0)置信度的意思是买过类目A的用户里有多少比例也买过类目B。这个指标可以直接转化成运营动作比如“买过婴儿推车的用户有63%也购买过婴儿辅食”那么推车订单完成页上推荐辅食就是合理设计。不过我要多说一句关联规则里的“强规则”不等于“因果”。可能两个类目同时被买只是因为在同一个促销会场里展示。所以购物篮分析的结果必须回到业务现场验证不要全盘照搬。6. 数据量变大的性能优化实操这一章节是纯经验篇。订单数据从几十万行往几百万、几千万行进时同样的pandas代码运行时间会从秒级变成分钟级再变成“跑到一半内存爆炸”。很多人一遇到数据量大就想着换Spark但实际上大部分电商私域分析场景单机Python优化一下完全够用。6.1 先别急着上Sparkpandas还能再救一下先说结论如果数据在单机内存的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, chunksize500000, 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在这里的作用是帮我们把复杂数据变成可理解、可决策、可行动的信息。模型和代码都可以重写但围绕业务问题的分析思路和落地方法才是这套东西的长期价值。我自己做这类项目的习惯是先花几天想清楚业务问题再花一天清洗数据最后用半天跑完分析和画图剩下的大部分时间都在跟业务方反复确认结论和调整策略。这个顺序反过来的话做得越快错得越离谱。