前几天有位做电商运营的朋友给我甩来一个压缩包,里面是某店铺2023年全年的订单明细Excel。他说:“Excel一打开就卡死,VLOOKUP跑一次要几分钟,你帮我看看下半年销售额为什么上不去。”这个需求太典型了,正好是一堂完整的Python数据分析实战课。我最终用Python配合pandas、Matplotlib、Seaborn完成了从数据清洗、指标计算到可视化输出的全流程,十几万行订单十分钟左右就能跑完。这篇文章会把整个分析项目拆开讲清楚:怎么定义指标口径、怎样做数据清洗、核心销售指标怎么算、哪些图表真正有用,以及我在处理这批数据时踩过的坑。适合已经掌握Python基础语法、想通过真实项目把数据分析能力落地到业务场景的读者。
1. 先从业务角度拆解“电商销售数据”的分析目标
1.1 为什么非要用Python而不是Excel/BI工具
先说结论:如果你只有几万行数据、分析一次就完事,用Excel或BI工具完全没问题。但一旦数据量超过十万行,Excel的透视表和VLOOKUP就开始力不从心,公式链长了还会出现“保存半天、计算更久”的情况。朋友这份订单明细有12万多行,Excel打开都费劲,更别说做复杂的去重、条件聚合和跨表计算了。
Python做这件事的优势有三个。
第一,过程可复现。Excel里点鼠标的每一步操作,换个人或者过两周再看,很难还原;但Python脚本保存下来,下次换一份新数据,只要结构相同,跑一遍就能出全部结果。第二,处理链完整。从读取、清洗、聚合到可视化可以写在一个流程里,中间每一步都有据可查。第三,处理性能足够。pandas是内存计算引擎,十几万行的订单数据属于“小数据”,在普通笔记本上跑聚合计算就是秒级的事,完全不需要上大数据框架。
当然,BI工具比如Power BI、Tableau也很强,但它们的强项是“拖拽式探索”和“固定看板”。如果你要做一次专题分析,比如“下半年销售额为什么下滑”,需要灵活地自定义指标口径、做多层拆解,用Python脚本的性价比反而更高。两者不是替代关系,是不同场景的选择。
1.2 分析框架:先定指标,再碰数据
“帮我看看销售额为什么上不去”这句话,不能直接当分析目标。拿到数据后第一件事不是写代码,而是把业务问题翻译成可计算的数据指标。
我当时和那位朋友确认了几个具体问题:
- 下半年销售额下滑,是购买的人数少了,还是客单价降了?
- 哪些商品类目在拖后腿?哪些类目还在增长?
- 新客户和老客户的贡献比例有没有变化?
- 哪个渠道、哪个区域的波动最大?
这些问题落到指标层面,就是几个核心口径:销售额(GMV)、有效订单量、客单价、复购率、类目销售额占比、月度环比/同比。后续所有代码都围绕这几个指标展开。
一个值得提醒的点是:指标口径必须在分析开始前和需求方对齐,不然算出来的数字可能对不上业务部门的报表。比如“销售额”到底是订单应付金额还是实付金额,退款的订单算不算,未付款订单算不算,这些口径差一个,最终结论就完全不一样。
1.3 数据字段说明与分析范围
朋友这份订单表导出来是CSV文件,共12.6万行,主要字段如下:
| 字段名 | 示例值 | 说明 |
|---|---|---|
| order_id | OD202301010001 | 订单号,一个订单可能对应多行商品 |
| order_date | 2023-01-01 12:23:11 | 下单时间 |
| user_id | U100234 | 用户ID |
| product_id | P88712 | 商品ID |
| category | 数码/家电/服饰 | 商品类目 |
| quantity | 2 | 商品数量 |
| unit_price | 2599.00 | 商品单价 |
| total_amount | 5198.00 | 该行商品的实付金额(含优惠分摊) |
| order_status | 已完成/已退款/已取消 | 订单状态 |
| channel | 小程序/App/直播 | 下单渠道 |
| city | 上海 | 收货城市 |
做分析前我先和需求方确认了两个分析边界:第一,分析周期是2023年1月1日到2023年12月31日;第二,只统计“已完成”的有效订单,“已退款”和“已取消”的订单不参与销售指标计算。这个边界非常重要,它决定了后面清洗逻辑怎么写。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据清洗:从原始订单表到可分析DataFrame的必经之路
2.1 导入数据与字段类型检查
不管原始数据是Excel导出的CSV还是数据库导出的文件,读取之后第一件事永远是看“元信息”。我习惯先跑这三行代码:
python复制import pandas as pd
df = pd.read_csv("orders.csv", encoding="utf-8-sig", parse_dates=["order_date"])
print(df.shape)
df.info()
display(df.head())
这里有两个小细节值得单独说。第一,encoding="utf-8-sig" 是处理Excel导出的CSV最稳妥的编码方式,不会有中文乱码;如果文件本身就是GBK编码,可以把编码改成 gbk(或者 gb18030)。第二,parse_dates=["order_date"] 会在读取时把下单时间直接解析成datetime类型,省得后面再手动画转换。
df.info() 能快速看到每列的数据类型和缺失情况。这次检查发现几个典型问题:
city列有约3000个空值;channel列有少量空值;order_status有“已退款”“已取消”等非有效状态;total_amount有个别记录为0或负数。
这些如果不在清洗阶段处理掉,后面所有指标都会失真。
2.2 缺失值、重复值、异常值的处理策略
数据清洗不是把所有空值都删掉,而是根据业务含义决定“删除”“填充”还是“保留分析”。我当时的处理逻辑是:
先剔除无效订单状态。
python复制valid_status = ["已完成"]
df = df[df["order_status"].isin(valid_status)].copy()
这一步直接去掉已退款和已取消订单,避免GMV被高估。做完之后可以打印一下剩余行数,方便后面追溯。
再处理缺失值。
核心业务字段如果为空,比如 order_id、user_id、total_amount 为空,这行数据没法参与销售或用户分析,只能删除。非核心字段像 city、channel,可以直接填充为“未知渠道”“未知城市”,保留行本身的数据价值。
python复制df["city"] = df["city"].fillna("未知城市")
df["channel"] = df["channel"].fillna("未知渠道")
df = df.dropna(subset=["order_id", "user_id", "total_amount"])
重复值处理要区分“整行重复”和“订单号重复”。
电商订单表里一个订单多行商品是正常现象,所以不能用 order_id 去重。判断重复值应该用 df.duplicated() 看是否整行一模一样,有的话直接 drop_duplicates()。
python复制df = df.drop_duplicates()
异常值用条件筛选而不是肉眼看。
我对金额和数量设了三个过滤条件:单价不能为负数,数量必须大于0,实付金额必须大于0。这个操作会排除掉一小部分测试订单和异常单。
python复制df = df[(df["unit_price"] > 0) & (df["quantity"] > 0) & (df["total_amount"] > 0)]
洗完之后最好把清洗前后的行数对比打出来,比如“清洗前126000行,清洗后118320行,剔除比例为6.1%”。这个数据放到分析报告里,能帮助别人理解你的数据质量边界。
2.3 时间字段与业务维度的衍生特征
清洗完原始数据,下一步是造“分析辅助列”。电商销售分析几乎离不开时间维度,所以我先加了几个时间特征:
python复制df["order_month"] = df["order_date"].dt.to_period("M")
df["order_quarter"] = df["order_date"].dt.to_period("Q")
df["order_weekday"] = df["order_date"].dt.day_name()
df["order_hour"] = df["order_date"].dt.hour
order_month 用于月度趋势分析,order_weekday 可以观察周内销售节奏,order_hour 用于看一天中的下单高峰。这些衍生列在EDA阶段会非常有用。
另一个重要特征是“订单行金额校验”。我拿每个商品的quantity * unit_price 和 total_amount 做了一次比对,发现有部分订单的行金额与明细对不上。原因是平台会做促销分摊,比如满减金额被拆到各个商品上,导致实际 total_amount 不等于单价乘以数量。这不是脏数据,是业务规则。搞清楚这个机制之后,后续所有销售额计算都以 total_amount 为准,不要再自己乘一次。
3. 核心销售指标的计算:不是写代码,是定义口径
3.1 销售额、订单量、客单价的计算口径
核心指标计算不复杂,复杂的是口径统一。先看最简单的整体指标:
python复制total_sales = df["total_amount"].sum()
total_orders = df["order_id"].nunique()
avg_order_value = total_sales / total_orders
print(f"有效销售额: {total_sales:.2f}")
print(f"有效订单量: {total_orders}")
print(f"客单价: {avg_order_value:.2f}")
这里必须强调一个坑:订单量一定要用 nunique(),不能用 count() 或 size()。因为这个表一个订单可以拆成多行商品,如果用 total_amount 的count去数订单数,会把订单量虚高好几倍,客单价也会被严重拉低。
月度指标同样要注意这个逻辑:
python复制monthly = df.groupby("order_month").agg(
销售额=("total_amount", "sum"),
订单量=("order_id", "nunique")
)
monthly["客单价"] = monthly["销售额"] / monthly["订单量"]
月度结果一出来,问题已经很明显了:上半年月度销售额基本在90万到110万之间波动,下半年从9月开始下滑,10月、11月虽然有双十一预热,但也没有超过上半年的峰值。接下来需要继续拆解,找到下滑原因。
3.2 同比环比与趋势分析
环比是相邻两个周期的对比,比如9月对比8月。代码如下:
python复制monthly["销售额环比"] = monthly["销售额"].pct_change()
monthly["订单量环比"] = monthly["订单量"].pct_change()
pct_change() 算出来的是小数,如果要展示成百分比,可以乘以100,再保留两位小数。环比数据能清楚看到9月销售额较8月下降了多少、订单量下降了多少。如果两个指标下降幅度不同,就说明影响因素可能不同。
我这次看到的规律是:9月订单量只下降了5%左右,但销售额下降了近12%,客单价也同步下降。这说明“不是没人买,而是买得便宜了”。继续往下看客单价和商品类目,会发现是低价商品销量占比提升,拉低了整体客单价。
这里补充一个经验:pct_change() 算环比时,第一个月的结果是NaN,这是正常的,不用处理。如果要看平滑趋势,可以用 rolling(3).mean() 做三个月移动平均,减少单月促销带来的噪声。
3.3 商品和类目的销售贡献拆解
销售额下滑是一个结果,真正的原因藏在“什么商品卖不动了”里。先做类目汇总:
python复制category_stats = df.groupby("category").agg(
销售额=("total_amount", "sum"),
订单量=("order_id", "nunique")
).sort_values("销售额", ascending=False)
category_stats["销售额占比"] = category_stats["销售额"] / category_stats["销售额"].sum() * 100
类目拆出来之后,我发现“服饰”这个类目的销售额占比超过40%,但它的销售额从8月开始连续下降。数码类目虽然客单价高,但订单量基数小,对总体销售额的拉动有限。家电类目则因为大促集中在6月,下半年的自然销量就是偏低的,这不是异常,而是季节性。
所以分析不能只看销售总额,还必须落到类目、商品、用户的交叉维度,才能定位到真正的问题源。
4. 用户与商品的分析视角:找出真正驱动销售的因素
4.1 用户复购与RFM分层
销售额 = 用户数 × 用户平均消费频次 × 客单价,这是电商分析的万能公式。销售额下滑,要么是买的人少了,要么是每个人买得少了,要么是客单价低了。先把用户维度算出来:
python复制user_stats = df.groupby("user_id").agg(
订单数=("order_id", "nunique"),
消费总额=("total_amount", "sum"),
最近购买日期=("order_date", "max")
)
user_stats["复购用户"] = user_stats["订单数"] > 1
repeat_rate = user_stats["复购用户"].mean()
这里的“复购率”口径是:有复购行为的用户数占总用户数的比例。如果想看“老客贡献”,可以进一步算复购用户的消费总额占所有消费总额的比例,这个数通常很惊人——20%的复购用户往往贡献了超过60%的销售额。
更细一点可以做RFM分层。RFM是三个维度的缩写:
- R(Recency):最近一次购买距离分析截止日有多久,越短越好;
- F(Frequency):购买频次,越高越好;
- M(Monetary):累计消费金额,越高越好。
实际操作中比较简洁的做法是把每个维度分成高分和低分两组,组合出八类人群。比如“高R、高F、高M”是重要价值客户,“低R、高F、高M”是需要唤醒的沉睡客户。这个分层可以直接指导运营动作:重要价值客户做权益维护,沉睡客户做召回活动。
4.2 高价值商品与连带销售分析
商品维度不能只看单款销量,还要看“是否拉动其他商品一起卖”。我先把每个订单内包含的商品数量算出来:
python复制order_items = df.groupby("order_id").agg(
商品数=("product_id", "nunique"),
订单金额=("total_amount", "sum")
)
multi_item_orders = order_items[order_items["商品数"] >= 2]
这些“多商品订单”才是连带销售的分析对象。如果某个商品经常出现在多商品订单里,说明它是引流款;如果某个商品总是被单独购买,那它的增长更多依赖自然流量或搜索流量。
进一步做商品组合分析,可以用“同一订单内商品共同出现的次数”来排序,找出关联强度较高的品类组合。比如灯具和插座经常一起买,那就可以在商品详情页做搭配推荐。这个逻辑再往前一步就是关联规则挖掘,但第一阶段用交叉频次就能发现很多可执行的规律。
4.3 渠道与地域维度洞察
渠道分析主要看不同渠道的销售额和客单价差异:
python复制channel_stats = df.groupby("channel").agg(
销售额=("total_amount", "sum"),
订单量=("order_id", "nunique")
)
channel_stats["客单价"] = channel_stats["销售额"] / channel_stats["订单量"]
我这次看到的数据里,App渠道的客单价最高,但订单量增速放缓;直播渠道订单量增长很快,但客单价明显偏低,大量是9.9元、19.9元的引流品。这也能解释为什么订单量没怎么掉、销售额却下滑——销售结构在向低价渠道转移。
地域分析要先处理城市字段的标准化。比如“上海”和“上海市”其实是同一个城市,但文本不同会被当成两个值。用 df["city"].str.replace("市", "") 就可以统一。做完之后再按城市汇总销售数据,才能看出哪些区域在增长、哪些区域在下滑。
5. 可视化输出:让图表替你说出业务结论
5.1 选图逻辑:什么数据配什么图
可视化不是把图表堆满PPT,而是让看图的人在十秒内理解你想表达的观点。我的选图原则很简单:
| 分析目的 | 推荐图表 | 原因 |
|---|---|---|
| 销售额/订单量随时间变化 | 折线图 | 趋势清楚,适合看拐点和斜率 |
| 类目销售额对比 | 横向柱状图 | 类目名称长,横向排布更好读 |
| 类目占比 | 环形图或堆积柱状图 | 一眼看出结构关系 |
| 单量/金额分布 | 直方图、箱线图 | 识别偏态和异常值 |
| 指标间关系 | 散点图、热力图 | 发现相关性 |
有几个图我几乎不用:3D图、雷达图、花哨的仪表盘。原因很简单,它们传递信息的效率通常不如普通二维图,还容易产生视觉误导。
5.2 用Matplotlib/Seaborn生成趋势、分布、对比图
先做全局设置,保证中文不乱码:
python复制import matplotlib.pyplot as plt
import seaborn as sns
plt.rcParams["font.sans-serif"] = ["SimHei"]
plt.rcParams["axes.unicode_minus"] = False
sns.set_style("whitegrid")
画月度销售额趋势:
python复制fig, ax = plt.subplots(figsize=(12, 6))
monthly_reset = monthly.reset_index()
monthly_reset["order_month"] = monthly_reset["order_month"].astype(str)
sns.lineplot(data=monthly_reset, x="order_month", y="销售额", marker="o", ax=ax)
ax.set_title("2023年月度销售额趋势")
ax.set_xlabel("月份")
ax.set_ylabel("销售额")
plt.xticks(rotation=45)
plt.tight_layout()
plt.show()
这里有个细节:order_month 是Period类型,直接传给Seaborn可能出问题,所以我先 astype(str) 转成字符串。这是pandas+Seaborn结合时很常见的坑。
类目对比图我用柱状图加数据标签:
python复制fig, ax = plt.subplots(figsize=(10, 6))
sns.barplot(data=category_stats.reset_index(), y="category", x="销售额", ax=ax)
ax.set_title("类目销售额排名")
如果需要看数据分布,比如客单价分布,用直方图和箱线图配合:
python复制fig, axes = plt.subplots(1, 2, figsize=(14, 5))
sns.histplot(df["total_amount"], bins=50, ax=axes[0])
axes[0].set_title("订单金额分布(含长尾)")
sns.boxplot(data=df, x="total_amount", ax=axes[1])
axes[1].set_title("订单金额箱线图")
通常你会发现订单金额严重右偏,大部分订单在100元以下,少量大额订单把平均值拉高。这也是“为什么中位数客单价远低于平均值”的原因。
5.3 让图表具备可读性与业务表达力
图表写出来只是第一步,更重要的是“用图表讲结论”。我会在关键图上做两件事:加趋势标注,加结论文字。
比如在月度销售额折线图上,8月到9月的下滑拐点非常关键,我会用 ax.annotate() 在这个点上标注“9月销售额环比下降12%”,看图的人就不需要自己再对比数据。
颜色方面,我习惯整张图只用一个主色,需要强调的点用红色或橙色标注,避免使用彩虹色。输出图片时我会把 dpi 设成200,确保放到PPT或报告里不模糊:
python复制plt.savefig("monthly_sales.png", dpi=200, bbox_inches="tight")
还有一个容易被忽略的点:图表标题和坐标轴标签不要只写“销售额”,要写清楚统计口径,比如“有效订单销售额(已剔除退款)”。这样看图的人不会产生歧义。
6. 分析之外:自动化报表与踩坑复盘
6.1 把分析脚本封装成每周自动报表
分析做完了,如果朋友每个月都要看一次这个数据,把所有代码揉在一个Notebook里显然不够。我会把核心逻辑拆成函数,做成一个可重复执行的脚本:
python复制def load_data(path):
df = pd.read_csv(path, encoding="utf-8-sig", parse_dates=["order_date"])
return df
def clean_data(df):
df = df[df["order_status"].isin(["已完成"])].copy()
df = df.dropna(subset=["order_id", "user_id", "total_amount"])
df["city"] = df["city"].fillna("未知城市")
df["channel"] = df["channel"].fillna("未知渠道")
# 其他清洗逻辑
return df
def calc_monthly_metrics(df):
df["order_month"] = df["order_date"].dt.to_period("M")
monthly = df.groupby("order_month").agg(
销售额=("total_amount", "sum"),
订单量=("order_id", "nunique")
)
monthly["客单价"] = monthly["销售额"] / monthly["订单量"]
return monthly
然后主流程就是先 load_data、再 clean_data、再分别计算月度数据、用户数据、商品数据,最后用 pd.ExcelWriter 把多个结果写入同一个Excel的不同sheet:
python复制with pd.ExcelWriter("report.xlsx", engine="openpyxl") as writer:
monthly.to_excel(writer, sheet_name="月度指标")
category_stats.to_excel(writer, sheet_name="类目分析")
user_stats.to_excel(writer, sheet_name="用户分析")
这样每周只要把最新的订单CSV丢进来跑一遍脚本,就能自动生成一份带全部指标的分析报表。如果能配合计划任务,比如Windows下的任务计划程序或macOS下的cron,还能做到定时自动运行。不过刚开始不建议一步到位,先把脚本跑稳,再考虑自动化调度。
6.2 我在处理这批数据时踩过的四个坑
第一个坑是编码问题。Excel导出的CSV在Windows下经常是GBK编码,pandas默认用UTF-8读,直接中文乱码。后来我统一要求导出时选“CSV UTF-8”格式,代码里也固定用 utf-8-sig,才算彻底解决。
第二个坑是订单量与商品行数混淆。刚开始我用 df.shape[0] 当订单量,结果把同一个订单拆出的多个商品行都算成了独立订单,订单量虚高几千单,客单价也跟着算错。后来一切涉及订单量的计算全改成 order_id.nunique(),再也没出过错。
第三个坑是没剔除退款订单。第一版分析报告里GMV包含了已退款订单,数值比实际高了将近8%。业务方一眼就看出不对,因为对不上财务口径。这个教训很深刻:不要急着算数,先把“什么订单算数”问清楚。
第四个坑是日期字段类型混乱。有些月份是从Excel复制出来的,order_date 被读成了字符串,排序时“2023-09”排到了“2023-10”前面。解决方法是读取时用 parse_dates 明确指定时间列,如果再有问题就用 pd.to_datetime() 强制转换。
6.3 后续扩展方向与个人体会
这次分析的结论最终落在了几件事上:服饰类目需要做秋冬新品强化、低价渠道需要搭配高价商品做连带销售、沉睡的高价值用户需要触达唤醒。这些都是能从数据里直接推导出的可执行动作。
如果继续往下做,我会往三个方向扩展:一是接入用户浏览、加购、收藏等行为数据,做转化漏斗分析,找出流失环节;二是做留存队列分析,看不同渠道进店的用户质量差异;三是在积累足够长时间周期后,尝试用机器学习模型预测未来销售额或用户流失概率。
最后说一点个人体会:分析电商销售数据,最难的往往不是代码,而是把业务问题翻译成指标口径的过程。代码只是把口径稳定地执行出来,业务理解才是决定分析是否有效的关键。如果你现在正拿着订单数据不知道从哪里入手,先别急着跑代码,拿一张纸写下“我想回答哪三个业务问题”,再围绕这三个问题去清洗、计算、画图,你会发现自己做出来的分析报告比堆砌一堆图表有效得多。
