Python数据分析实战：电商订单数据清洗与可视化全流程

周一上午，运营同事在群里丢了一份Excel："这是我们过去一年的订单明细，你帮我看看到底哪儿涨哪儿跌。"这类需求在电商公司实在太常见了，看起来只是"算个数"，但真正用Python数据分析把这件事做扎实，要经历数据清洗、口径确认、指标拆解、可视化输出好几个阶段。我当时把一份六万多行的订单流水，从乱糟糟的原始表整理成管理层能直接看结论的报表，也顺手沉淀了一套可以反复复用的分析流程。这篇文章就完整记录整个项目的思路、代码和踩过的坑，适合刚接触Python数据分析、想拿真实项目练手的朋友。

这次分析使用的是一份电商平台订单流水表，覆盖2023年7月到2024年6月，字段包含订单编号、下单时间、支付时间、商品信息、销售额、成本、数量、用户ID、收货省份/城市、支付方式等。拿到需求后我没有马上写groupby，而是先和运营确认了三个问题：销售额按支付口径还是下单口径？退款怎么算？订单量是按订单号去重还是按商品行计数？这三个问题直接决定了后面所有指标对不对。事实证明，这一步省掉了后面大量的返工。

1. 为什么这份订单流水不能直接用来算GMV

很多人拿到数据的第一步就是df['sales_amount'].sum()，觉得总销售额出来了就完事。这个动作在干净的教学数据集上没问题，但在真实业务数据上几乎一定会出错，因为原始订单流水里藏着大量需要判断的业务语义。

1.1 先看清手上有哪些字段

我习惯先把数据字典列出来，字段含义不清楚就直接分析，后面一定会被业务方问住。这次拿到的表结构大概是这样：

先跑几行代码看数据形状、字段类型和缺失情况，比直接算指标重要得多：

python复制import pandas as pd

df = pd.read_excel('order_data.xlsx')
print(df.shape)
print(df.dtypes)
print(df.isna().sum())
print(df.head())

这一步能快速暴露问题。比如order_time是object不是datetime，sales_amount被读成了float还好，但城市列如果混入数字就会被读成异常类型。

1.2 藏在原始流水里的几个"地雷"

第一颗雷是日期格式混用。后台导出的时候不同时期用了不同格式，有的单元格是2024/1/5，有的是2024-01-05 10:23:11，还有极少数是20240105这种纯数字。如果直接按字符串处理，排序和按月聚合全是错的。

第二颗雷是销售额里出现了负值。这不是系统bug，而是退款单被记成了负金额。正常销售额和退款必须分开统计，否则加总起来会互相抵消，GMV严重低估。

第三颗雷是同一订单号重复出现。一种情况是用户一个订单买了好几个商品，每个商品占一行，这是正常的；另一种情况是后台报表重跑导致整行完全重复，这是要删掉的。不能简单用drop_duplicates('order_id')处理，否则会把多商品订单的明细全删掉。

第四颗雷是省份城市字段不够干净，比如"广东 省""浙江 省"这种中间带空格的情况，还有"广东""广东省""广东深圳"三种写法同时存在。如果不处理，按省份聚合时会被拆成好几个桶，分析结果完全没法看。

2. 清洗订单数据的四板斧：列名、日期、金额、重复

数据清洗没有想象中那么神秘，核心就四件事：让列名能写进代码、让日期能被Pandas识别、让金额正负有意义、让重复行和拆分订单各归各位。做完这四步，后面所有分析才站得住脚。

2.1 列名规范化

原始Excel导出的列名经常带着空格、换行和中文括号，比如"商品名称 "、"销售额（元）"这类。中文括号在pandas里访问会出问题，列名中的空格也会导致代码可读性很差。我统一做了一次清洗：

python复制def clean_col(name):
    name = str(name).strip()
    name = name.replace(' ', '_')
    name = name.replace('（', '(').replace('）', ')')
    return name

df.columns = [clean_col(c) for c in df.columns]
df.rename(columns={
    '商品名称': 'product_name',
    '销售额(元)': 'sales_amount',
    '成本(元)': 'cost_amount'
}, inplace=True)

中文列名本身不影响pandas运行，但字段一旦多了，每次都要打中文很不方便。我建议统一转成英文小写加下划线，团队协作时不会出现"你用的是下单时间，我写的是order_time"这种混乱。

2.2 日期时间清洗

日期清洗的标准化做法是交给pd.to_datetime，让Pandas自动识别常见格式：

python复制df['order_time'] = pd.to_datetime(df['order_time'], errors='coerce')
df['pay_time'] = pd.to_datetime(df['pay_time'], errors='coerce')

注意一定要加errors='coerce'，否则遇到无法解析的值会直接抛异常，整个脚本中断。加了coerce之后，非法值会变成NaT，再用isna()统计出来，看看到底有多少行有问题。

这次清洗完发现有大约2%的order_time是NaT，大部分是明显录入错误，比如"2024-13-45"这种不存在的日期。处理逻辑不能一概删除，我先把这些行打印出来看分布，发现主要集中在某个月份，可能是当时导入工具出过问题。经过和运营确认，这部分订单用pay_time回填，实在回填不了的才剔除。

python复制# 下单时间为空但支付时间存在的，用支付时间回填
mask_missing = df['order_time'].isna() & df['pay_time'].notna()
df.loc[mask_missing, 'order_time'] = df.loc[mask_missing, 'pay_time']

日期这块最容易踩的坑是Excel里的日期被读成了数字，比如45000这种序列值。这种情况需要用pd.to_datetime(df['order_time'], origin='1899-12-30', unit='D')转换。判断方法很简单，打印dtypes，如果order_time是float或int，十有八九就是序列值。

2.3 金额字段的坑：负值不是bug，是退款

销售额这块我一开始差点搞错。看到负值的第一反应是数据异常，准备直接删掉，但仔细一想，电商订单流水里负销售额只有一个来源——退款。这类行记录的是用户退货后系统冲减的金额，必须单独拎出来统计，不能和正常销售额混在一起。

python复制df['is_refund'] = df['sales_amount'] < 0

refund_amount = df.loc[df['is_refund'], 'sales_amount'].sum() * -1
sales_amount = df.loc[~df['is_refund'], 'sales_amount'].sum()

print(f'正常销售额: {sales_amount:.2f} 元')
print(f'退款金额: {refund_amount:.2f} 元')
print(f'退款率: {refund_amount / sales_amount:.2%}')

另一种更隐蔽的情况是金额列被Excel存成了文本，比如单元格里有千分位符1,299.00或隐藏空格，此时dtypes会显示object，sum()会把所有数字拼接成字符串。我用了一个小技巧：先把这一列转成字符串，去掉千分位符和空格，再转float：

python复制df['sales_amount'] = (
    df['sales_amount']
    .astype(str)
    .str.replace(',', '', regex=False)
    .str.replace(' ', '')
    .astype(float)
)

这个操作在真实数据里出现的概率比想象中高得多，值得加到标准清洗流程里。

2.4 去重和订单拆分逻辑

去重是这次最绕的一个环节。完整重复行可以直接删：

python复制df = df.drop_duplicates()

删完之后发现行数少了两千多行，明显是系统重跑报表导致的重复。但同样的order_id仍然会出现多次，因为一个订单对应多个商品，每个商品一行。要区分"重复"和"多商品"很简单：完全重复的行，所有字段都一样；多商品订单，order_id一样但product_id或product_name不一样。

那订单量怎么算？必须到order_id级别去重：

python复制valid_orders = df.loc[~df['is_refund']]
order_cnt = valid_orders['order_id'].nunique()

但注意，如果用户下了单又整单退款，订单明细里可能只有一行负数，也可能正数负数同时存在。这时候算有效订单量最稳妥的做法是先排除is_refund为True的行，再对order_id去重。如果两个方向都出现过，说明这个订单退款过，那它就不应该算进"有效成交订单"。

2.5 增加辅助列

清洗完成后，我习惯一次性把后面分析要用的辅助列都建好：月份、季度、小时、星期几、是否已支付、是否退款。这样可以避免后面每个分析都重复写一遍时间转换逻辑。

python复制df['order_month'] = df['order_time'].dt.to_period('M')
df['order_hour'] = df['order_time'].dt.hour
df['order_weekday'] = df['order_time'].dt.weekday
df['order_date'] = df['order_time'].dt.date

to_period('M')比dt.month好用，因为月份直接带上年份，不会出现2023年1月和2024年1月混淆的问题。星期几这里用0到6表示周一到周日，后面画图再映射成中文标签。

3. 大盘到底涨没涨：GMV、订单量与客单价的三重校验

数据干净了，终于可以回答运营最初的问题。但"业务涨没涨"不能只看一个数，我习惯用三个指标互相验证：总销售额GMV、有效订单量、客单价。这三个数会讲出完全不同的故事。

3.1 月度趋势与环比变化

先做基础聚合：

python复制monthly = (
    valid_orders
    .groupby('order_month')
    .agg(
        gmv=('sales_amount', 'sum'),
        order_cnt=('order_id', 'nunique'),
        user_cnt=('user_id', 'nunique')
    )
    .reset_index()
)
monthly['unit_price'] = monthly['gmv'] / monthly['order_cnt']
monthly['gmv_ratio'] = monthly['gmv'].pct_change()
print(monthly)

跑完这段代码拿到的结果是下面这样（数据经过脱敏处理，仅示意结构）：

这里有个重要细节：计算客单价的时候分子和分母的口径必须一致。分子是销售额，分母是有效订单数（去重后的order_id数），不能拿订单明细行数当分母，否则多商品订单会被重复计算，客单价虚高。

另外，pct_change()给出的是环比，但如果数据跨度一年以上，建议补充同比。这次分析周期是12个月，我还额外做了同比：把去年的同月数据和今年的数据merge在一起，用(今年 - 去年) / 去年计算，这样能排除季节性因素。比如11月环比涨是因为大促，但同比才能真正看出今年大促比去年强还是弱。

3.2 工作日、周末与时段差异

大盘月度看完之后，我只做了两个维度的下钻：星期分布和小时分布。原因很简单，这两个维度直接对应广告投放和客服排班。

python复制weekday_order = (
    valid_orders
    .groupby('order_weekday')
    .agg(order_cnt=('order_id', 'nunique'), gmv=('sales_amount', 'sum'))
    .reset_index()
)

结果显示周末订单量比工作日高出约12%，但客单价反而略低，说明周末来的用户更多是冲动消费，购买的商品单价偏低。小时分布更明显：晚上20点到22点是全天高峰，订单量占全天的近三成；凌晨1点到5点订单量极低，但客单价很高，买的多是数码产品，可能是夜猫子用户直接下单不做比价。

这些结论对业务的价值是：广告预算可以重点投放在周四到周六的晚上，客服排班也要在晚高峰多配人手。数据分析如果只停在"涨了跌了"，业务方很难执行，拆到可落地的维度才算完成。

3.3 退款率：净收入才是真收入

销售额涨了不代表赚到钱，退款会把利润吃掉一大块。我按一级类目统计退款率：

服饰鞋包的退款率接近19%，远高于手机数码的6.8%。这让运营非常意外，因为只看销售额，服饰鞋包是第二大品类，但算上退款，它的净贡献可能还不如美妆个护。高退款通常和尺码不符、色差、质量有关，这个结论直接推动运营去优化商品详情页的尺码表和退换货规则。

4. 拆到品类和地域，才知道增长引擎在哪

大盘看趋势，但真正决定下一步动作的是"哪几个品类、哪几个地区、哪几个商品在拉动或者拖累大盘"。这一段我从三个切片做拆解：一级类目、Top单品、省份城市。

4.1 一级类目贡献：销售额不等于利润

按类目聚合要同时看销售额、销量、毛利率、订单量四个指标。这次用的代码：

python复制cat_analysis = (
    valid_orders
    .groupby('cat1')
    .agg(
        gmv=('sales_amount', 'sum'),
        quantity=('quantity', 'sum'),
        order_cnt=('order_id', 'nunique'),
        cost=('cost_amount', 'sum')
    )
    .reset_index()
)
cat_analysis['gross_profit'] = cat_analysis['gmv'] - cat_analysis['cost']
cat_analysis['gross_margin'] = cat_analysis['gross_profit'] / cat_analysis['gmv']
cat_analysis = cat_analysis.sort_values('gmv', ascending=False)

结果很有意思：手机数码销售额排第一，但毛利率只有15%左右，属于典型的高流水低利润类目；美妆个护销售额虽然不是最高，毛利率却超过45%，是真正赚钱的品类。这意味着如果公司要冲利润，美妆个护值得加码；如果要冲规模，手机数码是主力但不能指望它赚钱。

这里还有个小坑：cost_amount在原始数据里有很多空值，直接sum()会忽略空值，但如果全品类缺失率不一致，毛利率对比就会失真。我的处理是：先按类目统计缺失率，缺失超过30%的类目在毛利率分析里单独标注，不参与对比。

4.2 Top单品：合并规格变体再排名

单品排名看起来简单，实际做起来有个坑：同一个商品有多个规格，比如"某某手机 128G"和"某某手机 256G"，它们的product_id不一样，但本质上是一个产品。如果不合并，Top榜会被同一产品的不同规格刷屏，业务方根本看不出该重点备货哪个品类。

我做了两步处理：先把product_name去掉颜色、容量等规格关键词，再做聚合：

python复制import re

def normalize_product(name):
    name = re.sub(r'[（(].*?[)）]', '', str(name))  # 去掉括号里的规格
    name = re.sub(r'\d+(G|GB|ML|L|KG|g|ml)', '', name)  # 去掉容量
    return name.strip()

df['product_base'] = df['product_name'].apply(normalize_product)

top_products = (
    valid_orders
    .groupby('product_base')
    .agg(gmv=('sales_amount', 'sum'), order_cnt=('order_id', 'nunique'))
    .sort_values('gmv', ascending=False)
    .head(10)
)

Top10商品里，三个是手机数码，四个是美妆个护，两个家用电器，一个运动户外。这验证了类目层面的结论：美妆个护单品销量虽然不如某些数码爆款，但毛利高，是利润支柱。

4.3 地域维度：省份和城市的差异

省份字段清洗我先做了标准化，把空格、后缀、简写统一：

python复制df['province_clean'] = (
    df['province']
    .astype(str)
    .str.replace(' ', '', regex=False)
    .str.replace('省', '', regex=False)
    .str.replace('市', '', regex=False)
)

province_data = (
    valid_orders
    .groupby('province_clean')
    .agg(gmv=('sales_amount', 'sum'), order_cnt=('order_id', 'nunique'))
    .sort_values('gmv', ascending=False)
)

地域分析发现一个问题：销售额前五的省份贡献了超过55%的营收，但其中有三个省份的订单量排名和销售额排名并不匹配。比如某个省份订单量排第七，但销售额排第三，说明这个地区的客单价很高，用户更愿意买贵的东西。与之相反，另一个省份订单量很大，但客单价只有平均水平的七成，整体产出效率偏低。

城市维度进一步看，Top10城市里除了北上广深，还有几个新一线城市，这些城市的客单价甚至超过一线城市。这说明投放策略不能只盯着超一线，下沉市场的消费力在某些品类上已经显现出来。

5. 用户分层：复购率与简化RFM模型怎么落到业务动作

类目和地域回答的是"什么商品在卖、在哪里卖"，但电商生意本质是人的生意。同样的GMV，靠一万个新客还是靠三千个老客，背后的运营策略完全不同。所以我还做了用户维度的分析。

5.1 先算复购率

复购率的口径要先定清楚。这里我用的是"截至分析期结束，购买次数大于等于2次的用户数 / 全部有成交记录的用户数"。

python复制user_stats = (
    valid_orders
    .groupby('user_id')
    .agg(
        order_cnt=('order_id', 'nunique'),
        total_amount=('sales_amount', 'sum'),
        last_order_time=('order_time', 'max')
    )
    .reset_index()
)

repurchase_rate = (user_stats['order_cnt'] >= 2).mean()
print(f'复购率: {repurchase_rate:.2%}')

这里统计订单数时一定要用nunique而不是count，因为一个订单多个商品会生成多行明细，count会把一次购买算成多次。这次跑下来的复购率是31.7%，也就是说大约三分之一的用户买过两次以上。这个数字在电商里算中等偏上，但还有提升空间。

5.2 简化版RFM分层

复购率只有一刀切的感觉，我想进一步把用户分成几类，方便运营做差异化触达。这次没有上复杂的聚类模型，而是用了经典的简化版RFM。

RFM三个维度：

• R：最近一次购买距今的天数，衡量用户活跃度
• F：购买次数，衡量用户粘性
• M：累计购买金额，衡量用户价值

我分别给三个维度打1到3分，阈值根据业务情况定：

python复制from datetime import timedelta

now = valid_orders['order_time'].max()

def score_r(days):
    if days <= 30:
        return 3
    elif days <= 90:
        return 2
    else:
        return 1

def score_f(cnt):
    if cnt >= 3:
        return 3
    elif cnt == 2:
        return 2
    else:
        return 1

def score_m(amount):
    if amount >= 1000:
        return 3
    elif amount >= 300:
        return 2
    else:
        return 1

user_stats['R'] = user_stats['last_order_time'].apply(lambda x: score_r((now - x).days))
user_stats['F'] = user_stats['order_cnt'].apply(score_f)
user_stats['M'] = user_stats['total_amount'].apply(score_m)
user_stats['rfm_seg'] = user_stats['R'].astype(str) + user_stats['F'].astype(str) + user_stats['M'].astype(str)

分层之后，我把结果映射成业务语言：333、332、323这类用户是高价值核心用户；R是3但F和M是1的用户是"近期活跃新客"，有潜力但还没建立购买习惯；R是1但曾经F和M很高的用户属于"流失预警"，需要重点召回。

各分层的销售额贡献差距非常明显：高价值核心用户只占用户总数的6.4%，却贡献了接近32%的销售额。这说明运营最应该做的事情不是海量拉新，而是把预算花在高价值用户维护和新客二次转化上。

5.3 用户生命周期视角

我还简单看了新客和老客的月度结构：每个月的新客数量相对稳定，但老客的复购订单占比在逐步上升。这说明平台的服务体验在变好，用户的忠诚度在积累，而不是单纯靠投放换流量。这个结论放在汇报里很有说服力，因为它说明增长不是一次性的，而是有复利效应。

6. 用图片讲结论：中文字体和图表输出的实战细节

分析做了一大堆，最后要变成业务方看得懂的图。这一步最容易翻车，尤其是中文字体问题。我在第一次画图时就踩过，图表里全是方块，标题全是乱码，被同事笑了一下午。

6.1 中文字体和负号显示

matplotlib默认字体不支持中文，必须手动指定。标准的配置方式：

python复制import matplotlib.pyplot as plt

plt.rcParams['font.sans-serif'] = ['SimHei']  # Windows用黑体
# plt.rcParams['font.sans-serif'] = ['Arial Unicode MS']  # macOS用这个
plt.rcParams['axes.unicode_minus'] = False  # 让负号正常显示

axes.unicode_minus这个参数很容易被忽略，设完中文字体之后，如果不加这一行，坐标轴上的负号会显示成一个方块，非常难看。

如果换了字体还是乱码，大概率是系统里没有对应字体。可以先跑一下：

python复制import matplotlib.font_manager as fm
font_list = [f.name for f in fm.fontManager.ttflist]
print(sorted(set(font_list)))

看一下自己的系统里有哪些可用字体，再替换配置。

6.2 画哪几张图，怎么画

这次汇报用了四张核心图，每张图对应一个维度：

第一张：月度GMV趋势折线图加订单量柱状图，双Y轴展示。管理层第一眼就能看到"全年节奏"。

python复制fig, ax1 = plt.subplots(figsize=(12, 5))

ax1.bar(range(len(monthly)), monthly['gmv'], color='#4472C4', alpha=0.6, label='GMV')
ax1.set_ylabel('GMV（万元）')
ax1.set_xticks(range(len(monthly)))
ax1.set_xticklabels(monthly['order_month'].astype(str), rotation=45)

ax2 = ax1.twinx()
ax2.plot(range(len(monthly)), monthly['order_cnt'], color='#ED7D31', marker='o', label='订单量')
ax2.set_ylabel('订单量')

plt.title('月度GMV与订单量趋势')
plt.tight_layout()
plt.show()

这段代码看似简单，有两点要提醒：第一，x轴刻度不要直接用月份字符串当坐标，因为Pandas的Period对象转成字符串后旋转角度要设置，否则标签会重叠；第二，双Y轴的图要注意左右刻度各自独立，在两边的数值范围差异很大的时候，折线和柱子的趋势对比才有效。

第二张：一级类目销售额和毛利率的对比柱状图，两个子图并排。左边是销售额占比，右边是毛利率，很容易看出"高收入低毛利"和"中收入高毛利"的对比。

第三张：Top10商品的水平条形图。我特意用了水平条形图，因为商品名称通常很长，垂直柱状图放不下。用barh之后，Y轴标签再手动调整字体大小，可读性会好很多。

python复制plt.figure(figsize=(10, 6))
top10 = top_products.reset_index().sort_values('gmv')
plt.barh(top10['product_base'], top10['gmv'], color='#2E75B6')
plt.xlabel('销售额（元）')
plt.title('Top10商品销售额')
plt.tight_layout()
plt.savefig('top10_products.png', dpi=150, bbox_inches='tight')

第四张：RFM各人群的销售额贡献占比柱状图。用groupby('rfm_seg')聚合后，只画销售额占比最高的前8个分层，剩下的合并成"其他"，避免图太碎。

6.3 图表设计的心得

做图的时候我坚持几个原则：颜色不超过三种，越多越乱；标题必须是一句人话，不要只写"各品类销售额"，而是写成"手机数码销售额最高，但美妆个护毛利率领先"；数值标签只标关键位置，不要一张图上全是数字。

还有一个小技巧：分析完先导出Excel结果表，再画图。PPT汇报时，业务方经常会对某个数字追问细节，这时候直接打开Excel透视表，比现场改Python代码快得多。数据结果和图形分开交付，等于给自己留了后路。

7. 这些坑我替你先踩了：清洗与统计中的高频事故清单

最后的最后，把这次项目里遇到的高频问题整理成一个清单。这些问题单独看都不大，但每一个都可能让整个分析结果出错，而且出错的地方往往很隐蔽，不仔细检查根本发现不了。

这十个坑里，最危险的不是技术问题，而是"数据看起来正常"的时候。比如金额列如果是文本，sum()不报错，但结果完全错误；日期如果是序列值，折线图的横轴看着也是连续的，但月份对不上。每一张图、每一个数字出来之后，我建议都用业务常识做一次校验：这个月销售额大概是多少、客单价在什么范围、退款率是否合理。只有通过常识校验的数据，才敢往外发。

分析完成之后，我把整套流程整理成了脚本，每月月底自动跑一次，输入后台导出的Excel，输出一份带图表的HTML报告。运营同事再也不用每月喊我"看下数据"，他们自己打开报告就能看到GMV、订单量、品类结构、退款率和用户分层的变化。这个自动化脚本的质量，完全取决于当初清洗逻辑是否扎实——数据干净，后续一切才顺。