简介电商数据分析离不开高质量的真实数据但业务数据往往涉及隐私难以直接取用。脱敏数据集在去除敏感信息的同时保留了核心业务逻辑成为技术验证与算法练手的关键资源。通过国内B2C场景的脱敏订单、用户及行为数据可以深入理解用户生命周期、复购规律与消费偏好。基于此类数据集实践SQL优化、Python数据处理、RFM模型分层、留存分析及关联规则挖掘能系统提升从数据清洗到业务洞察的完整能力。本文围绕一份国内某电商平台的脱敏数据集解析其字段设计、预处理要点与典型分析场景帮助数据从业者快速上手真实业务分析为构建用户画像和实施精细化运营提供可行路径。 做电商数据分析这么多年手里没几份像样的数据集很多活儿根本没法干。我经常在后台收到私信问有没有那种既能练手、又足够真实的电商数据最好是国内B2C场景的别整一堆英文电商的字段看得脑壳疼。今天就把我最近在折腾的一份国内某B2C电子商务网站的脱敏数据集拿出来聊聊不含任何用户隐私但业务字段和真实场景的逻辑都保留了非常适合拿来做用户画像、留存分析、RFM模型甚至简单的销量预测。这份数据集最打动我的地方在于它不是那种 Kaggle 上被刷烂了的洋玩意儿而是更贴近我们日常运营节奏的国内电商结构。订单号、SKU、类目层级、支付渠道、地域分布这些字段一应俱全拿到手里你就能直接跑分析不用花大量时间在字段映射上。无论你是刚入行的数据新人还是被“数据缺失”折磨的算法工程师这份数据集都能让你少走很多弯路。1. 数据集的核心价值与整体设计先给这份数据集定个调它模拟的是国内一个综合类 B2C 电商平台的交易与行为数据快照时间跨度覆盖了某自然年的四个季度。之所以强调“国内”是因为它的字段设计、业务逻辑和数据分布特征都符合咱们这边电商平台的常见套路比如促销节点618、双11、支付方式支付宝、微信、银行卡、收货地址的省市区划分等这些在国外公开数据集里是很难见到的。1.1 为什么我需要这份数据集在实际工作中我们经常遇到“巧妇难为无米之炊”的尴尬。公司内部数据敏感不能外带网上开源数据集要么太老要么是国外电商的玩法类目和用户习惯都对不上。这份数据集恰好补上了这个缺口它给我的价值主要体现在三个层面业务理解层面通过订单与用户表的关联能直观感受国内 B2C 场景下的用户生命周期价值比如新客首次购买集中在哪些类目、复购周期普遍是多少天。技术练手层面数据量级适中约为几十万条订单记录不至于让你的电脑跑个模型卡死又能充分考验 SQL 优化能力和 Python 处理效率。算法验证层面因为字段齐全做用户分群、推荐系统召回、甚至销售预测模型都有足够的特征支撑不至于像某些清洗过度的数据集那样跑完模型都不知道业务含义是什么。1.2 数据集的基本构成与体积拿到压缩包解压后里面主要是几个 CSV 文件和一份数据字典说明。我当时直接愣住了因为它比我想象的要“干净”很多字段命名也相当规范全是小写加下划线没有乱七八糟的乱码。核心文件包括用户信息表、商品信息表、订单主表、订单明细表以及用户行为日志表。文件大概情况是这样的文件名记录量级主要作用users.csv约 5 万条用户基础信息ID、城市、注册时间、年龄段products.csv约 2 万条商品类目、品牌、价格、上下架时间orders.csv约 30 万条订单主表包含支付状态、支付金额、下单时间order_items.csv约 45 万条订单明细SKU 级维度包含数量、单价user_behavior.csv约 200 万条用户浏览、点击、收藏、加购行为日志这个量级设计得很有讲究。200 万条行为数据跑 Pandas 不会崩溃但如果你用纯 Python 循环去处理绝对能让你等到怀疑人生这就逼着你学会用向量化操作。30 万条订单数据做月度趋势分析、RFM 分层结果都非常稳定不会因为样本太少而出现极端波动。1.3 数据脱敏与隐私保护的思路因为这涉及“不含隐私”这个关键点我必须拆开来说说数据脱敏这件事。这份数据集里的用户手机号、真实姓名、详细地址都做了不可逆的替换处理。具体来说用户手机号统一变成了“138****”后四位随机数详细地址只精确到市级后面的街道和门牌号全部抹掉了支付账号的 token 也做了哈希处理。这种脱敏处理方式是国内企业对外提供数据的常见做法既保留了数据的真实分布特征又彻底切断了与真实个人的关联。比如分析地域购买力时我们只需要知道用户在哪个省、哪个市完全不需要知道他在哪条街。分析支付渠道偏好时只需要知道用的是微信还是支付宝不需要完整的交易流水号。2. 核心字段解析与业务含义很多新手拿到数据第一件事就是 head() 看一眼然后就开始跑模型这是不对的。我在拿到这份数据集时花了整整两个小时仔细研究数据字典因为字段里的每一个细节都隐藏着业务逻辑。2.1 用户信息表里的“隐藏财富”users.csv 里的字段看起来简单其实暗藏玄机。除了常规的 user_id、注册时间这里有个字段叫user_source它标记了用户是通过什么渠道注册的比如搜索引擎、直接访问、广告投放、朋友邀请等。很多人会忽略它但我在之前的项目里做过一个渠道质量的分析广告带来的用户虽然首单转化快但 30 天留存率明显低于搜索渠道。这说明什么说明广告拉新可能拉来了一批“羊毛党”或者体验型用户他们领完优惠券就走了。再来看age_group这个字段它把用户划分成了几个年龄段区间。这里有一个很坑的细节它用的是“20”、“20-25”、“26-30”、“31-40”、“40”这种左开右闭的划分方式。在做可视化时如果不注意这个边界很容易把 25 岁的人划到 26-30 组里去导致柱状图数据对不上。2.2 订单表里的金额与状态陷阱orders.csv 是这份数据集里我最常用的表。payment_amount是用户实际支付的金额这个字段千万要注意它不是商品原价的总和而是已经扣除优惠券、满减活动和积分抵扣后的最终金额。而total_amount是订单的原价总额。两者一对比就能算出这个订单的折扣力度。我刚开始分析时发现有一个订单的支付金额竟然是负数差点以为数据清洗出问题了。后来查了数据字典原来是“退款订单”。在退款订单里支付金额被记录为负数表示资金退回给用户。遇到这种情况做销售额统计时一定要加个过滤条件把支付状态等于“已完成”且金额大于 0 的订单才纳入统计口径。payment_status字段有多个枚举值待支付、已支付、已取消、退款中、已退款。做留存分析时只保留“已支付”的订单但做转化率漏斗分析时就得把所有状态都算上看从下单到支付成功到底流失了多少用户。2.3 商品表里的类目层级细节商品信息表里最有分析价值的字段是category_path它是那种“食品休闲零食坚果炒货”的完整路径用大于号分隔。这个设计太方便做类目汇总了在 SQL 里用SPLIT_PART或者 Python 里用split就能轻松提取一级类目、二级类目。另外product_rating和rating_count这两个字段分别代表商品平均评分和评价数量。注意数据里有很多商品的rating_count为 0这说明它们上架时间短还没积累起评价。这类新品的转化率往往不稳定做推荐模型时可以采用“冷启动”策略而不是直接把它们丢进协同过滤算法里。2.4 行为日志表的时间与行为类型user_behavior.csv 是文件体量最大的一个每行记录代表用户的一个行为。behavior_type的枚举值包括浏览1、收藏2、加购3、购买4。这个字段用整数来表示行为类型是业内常见做法但我在实际处理时踩过坑如果直接把这个整数字段作为特征丢给机器学习模型模型会误以为“4”比“1”重要 4 倍这是毫无逻辑的。正确做法是进行 One-Hot 编码。还有行为日志里的时间戳是标准的 Unix 时间戳格式精确到秒。处理时要先转换成北京时间因为原始数据可能是按 UTC 存储的。别问我怎么知道的曾经有一次我画用户活跃曲线发现凌晨 2 点有个诡异的峰值查了半天才发现是时区没转换把早上的活跃数据推后了 8 个小时。3. 数据预处理与质量校验实战说实话这份数据集的质量在开源数据集里算好的但离“拿来即用”还有一定距离。我在预处理阶段就发现了不少有意思的问题这些问题恰恰是最能锻炼人的地方。这里我把整个清洗流程和关键代码思路分享出来都是可以直接抄作业的级别。3.1 缺失值处理的判断逻辑不同字段的缺失值处理策略完全不同不能一概而论。比如用户的city字段有少量为空这是因为用户没有授权获取位置信息我选择的是填充为“未知”。但订单表的coupon_id优惠券 ID为空这是正常的因为大部分订单都没用券这不能算是缺失而是“无该属性”。判断缺失值是否严重影响分析我通常会算一个缺失比例import pandas as pd orders pd.read_csv(orders.csv) missing_ratio orders.isnull().mean().sort_values(ascendingFalse) print(missing_ratio[missing_ratio 0])结果执行后我发现coupon_id的缺失率高达 68%user_coupon_amount用户券金额缺失率也接近 60%。这两个字段缺失比例高很正常说明大部分订单没有使用优惠券。我选择保留这些缺失值并在做特征工程时用 0 来填充因为“没使用券”本身就是一种业务状态。真正需要警惕的是关键字段的缺失比如payment_amount如果缺失这一行订单就得直接剔除因为它是后续所有分析的核心指标。在我这份数据里这类严重缺失的记录占比不到 0.3%剔除后对整体分布几乎没有影响。3.2 时间字段的标准化处理时间字段的坑最多我专门花了一小节来说。orders.csv 里的created_at是 Unix 时间戳但 user_behavior.csv 里的timestamp也是 Unix 时间戳。两者格式统一这很好但需要统一处理成可读时间import datetime orders[created_at] pd.to_datetime(orders[created_at], units) orders[created_at_cn] orders[created_at] pd.Timedelta(hours8) orders[order_month] orders[created_at_cn].dt.to_period(M)为什么要加 8 小时因为这份数据集的原始时间是按 UTC 记录的。如果不加你统计出来的“每日订单量”和实际的业务日会对不上尤其在上午 8 点到中午 12 点这段时间里的订单会被算到前一天去。3.3 重复数据与异常账户的识别有些用户可能是刷单号或者测试号它们在短时间内在同一家店铺购买了异常多的同类商品。为了不影响用户价值的分析结果我做了两步清洗。先去除全字段完全重复的记录再对明显异常的账户进行标记而不是直接删除这样能保留数据完整性同时在后继分析中可按需过滤。我当时还用了一个非常有效的指标——订单金额/订单商品数量的单价如果算出来的单价低于 0.01 元基本可以断定是异常订单。正常商品的价格不可能低于一毛钱除非是赠品。这类订单在数据里有两百多个是明显的测试数据在做销售额分析时应该剔除。4. 基于该数据集的典型分析场景数据集是死的但分析思路是活的。我把这份数据集在手上转了几圈梳理出了三个最能体现其价值的分析场景。每个场景都兼顾了业务意义和可操作性。4.1 用户生命周期与留存分析留存分析是电商数据分析最硬核的指标没有之一。这份数据集的时间跨度足够长可以支撑完整的留存分析。我以用户首次支付日期作为基准日观察他们在后续第 1 天、第 7 天、第 30 天的回来购买情况。具体操作如下先找每个用户的首次支付日期用 min 聚合再计算每个订单的支付日期与首次支付日期之间的天数差。然后按首购日期分组统计各组的留存率。实际跑出来的结果非常有意思新用户的次日留存率在 18% 左右而 30 天留存率只有 3% 左右。这个数字很真实说明电商拉新容易留人难。如果你仔细分析不同user_source的留存差异会发现来自搜索渠道的用户虽然首日转化看起来一般但 7 日留存率比广告渠道高出一倍。这给运营的启示是不能光盯着获客成本更重要的是看长期用户价值不然就是花钱买了个热闹。4.2 用户价值分层RFM 模型实战RFM 模型是电商用户分层的经典玩法它从最近一次消费时间Recency、消费频率Frequency、消费金额Monetary三个维度刻画用户价值。这份数据集带有的订单字段刚好能够支撑起一个完整 RFM 分析。我直接用 Python 写了一段脚本基于已支付的订单数据计算每个用户的 RFM 值。最近一次消费时间用数据集中最大日期减去用户最后一次支付日期消费频率是用户的总支付次数消费金额是累计支付金额。然后用分位数法把每个维度分成高、中、低三档最终组合出 8 类用户从“重要价值客户”到“流失客户”。这里的实操小技巧在分箱时如果直接使用pd.cut按等距分箱会受极端值影响导致大部分用户被分到低价值组。我建议先对金额做log1p变换或者直接用四分位数切分。跑出来的结果中重要价值客户约占总用户数的 5%但贡献了约 40% 的销售额典型的长尾分布这跟业务的直觉完全吻合。4.3 商品类目与购物篮关联分析关联规则挖掘是购物篮分析的核心方法用来挖掘“买了啤酒的人还会买尿布”这类规律。这份数据集里有足够的类目信息很适合做类目级别的关联分析。预处理时要注意一个订单往往包含多个商品需要先按订单号聚合把同一个订单内的商品类目合并成一组然后再用mlxtend库的apriori算法计算频繁项集和关联规则。我跑出来的结果里有一条规则是“购买婴幼儿奶粉的人有较高概率同时购买纸尿裤”提升度超过了 3。这在业务上完全说得通说明数据质量靠谱。还有一点值得玩味的就是做类目关联时不要直接用叶子类目比如“贝因美奶粉”而是用二级类目比如“奶粉/辅食”进行聚合否则数据会太稀疏算出来的关联规则没有统计意义。这个经验是我尝试了三次才搞明白的分享出来给大家避坑。5. 常见问题与排查技巧实录用这份数据集做分析的时候我踩过不少坑。这些问题说出来可能你觉得简单但当我第一次遇到时真的差点怀疑人生。5.1 为什么用户数比订单数还多我第一次统计数据的时候发现用户总量是 5.2 万而订单总数只有 4.1 万。当时第一反应是数据出错了因为按理说每个用户至少应该有一个订单。后来一查才知道数据里的用户表包含的是全量注册用户其中将近 1 万人注册后从未下过单。这是很符合真实业务的情况但也提醒我做转化分析时不要把注册用户数当成总分母应该用“有登录行为”“有浏览行为”的用户数作为起点否则转化率会低得离谱。5.2 同一订单 ID 对应多条商品记录订单表 orders.csv 是一行一个订单而订单明细表 order_items.csv 是一行一个商品。做金额汇总时如果直接用两个表关联再对订单主表进行分组很容易把金额翻倍。比如一个订单包含 3 个商品关联后会有 3 行每行都保留着订单总额此时如果不小心把订单总额加起来就等于重复算了 3 次。正确的做法是先以订单明细表为基础用单价乘以数量算出每个订单的明细总金额然后单独去和订单主表的支付金额核对。如果两者对不上优先以订单主表为准因为那是用户实际支付的钱明细表只是用于计算 SKU 级别的统计。这个原则在写 SQL 时放在脑子里能帮你躲掉很多坑。5.3 时间段划分对统计结果的影响如果你把数据按自然月分组统计销售趋势可以但要注意促销节点的前置效应。我在实际数据里发现每次大促前一周订单量会有一个明显的下滑而大促当天会暴涨。这种“脉冲式”波动如果按月聚合会平滑掉很多信息掩盖真实规律。我的建议是做趋势分析时按“周”聚合并且把大促当周单独标记出来。这样才能看出大促前后的用户行为差异不会把数据特征磨平。另外一个非常关键的细节是大促期间的payment_amount往往低于平时因为用了大量优惠券和满减分析客单价时如果不区分活动单结果会失真。5.4 数据处理性能优化技巧如果有人用这份数据做特征工程200 万行行为日志可能有点压手。我第一次直接用groupby统计用户行为次数跑了两分钟没跑完后来换了个思路先过滤掉不需要的字段再在 groupby 之前用astype压缩数据类型速度提升了将近十倍。behavior pd.read_csv(user_behavior.csv, usecols[user_id, behavior_type, timestamp]) behavior[behavior_type] behavior[behavior_type].astype(int8) behavior[user_id] behavior[user_id].astype(int32)这样做的原理很简单int64 转成 int8 后内存占用降低到原来的八分之一数据加载和分组计算都会快很多。特别是你打算用这块数据跑机器学习模型时节省下来的内存可以让你多开几个特征工程实验。6. 数据集的局限性与扩展思考这份数据集的优点很明显但局限性也摆在那里。如果你能正视这些局限反而能在分析时做出更合理的判断。6.1 时间跨度的限制数据集只覆盖了自然年内的四个季度没有跨年数据。这导致我无法分析季节性周期变化比如春节前后消费习惯的差异。对于想要做时间序列预测的朋友来说这个长度刚好够做简单的月级别预测但想做更复杂的 SARIMA 模型数据量就略显不足。6.2 没有退货与售后服务数据订单数据里虽然有退款状态但没有退货原因、退货时效、客服介入记录等售后字段。这意味着我无法从这份数据中分析售后体验对复购率的影响而售后体验恰恰是国内电商平台留存率的重要影响因素。如果你在某个场景下需要分析“为什么用户流失”这份数据会显得有些单薄。6.3 如何扩展这份数据的分析价值我在实际使用中尝试把它和公开的节假日日历结合增加了一些“是否节假日”“是否促销日前一周”的特征字段然后预测每天的订单量效果提升了不少。另外也可以根据商品的价格带分布构建一些价格敏感度特征分析用户在不同价格区间的购买偏好。另一种扩展方向是把行为日志做成用户到商品的“行为序列”再用 Word2Vec 来学习商品的向量表示这样就能做简单的相似商品推荐或者直接喂给深度兴趣网络做召回。粒度虽然粗了点只有类目级没有 SKU 级但配合商品的类目特征在冷启动场景下依然有不错的参考价值。from gensim.models import Word2Vec # 构建每个用户的商品类目序列 user_seq behavior_df.groupby(user_id)[category_path].apply(list).tolist() model Word2Vec(user_seq, vector_size64, window5, min_count2, sg1)这一跑模型训练特别快效果意外地好。用相似类目做召回在离线评估里的召回率能达到不错的水准。所以说不管数据集是别人的还是自己的关键在于能不能挖掘出它的潜力。7. 实操总结与避坑清单这份数据集我前前后后用了大概一个星期从最开始的字段探索到中间的清洗和特征工程最后跑出用户分层和关联分析整个流程走下来确实比单纯的造数练习要有价值得多。最后把这几天踩过的坑和沉淀下来的经验整理成一个清单希望能帮第一次接触这份数据的朋友省点时间。7.1 上手必看的避坑清单金额字段别乱用total_amount是原价payment_amount才是实际支付统计业绩用后者分析折扣力度用两者差值。退款订单的金额是负数记得过滤。时间必须转时区原始时间戳是 UTC直接转 pandas 时间类型后要加 8 小时才是北京时间。不然后续所有按天、按小时的分析都会偏移。行为类型要 One-Hotbehavior_type的 1-4 是分类不是数值不能直接当特征喂模型必须转换成哑变量。类目字段用“”分隔category_path里是“一级二级三级”的结构用 split 就能拆出各级类目别自己手写正则去匹配。留存计算别用全量用户做分母应该用当日有活跃行为的用户数或者至少用当日有支付行为的用户数否则留存率会被严重稀释。7.2 值得一试的进阶玩法如果你已经把基础分析都做完了我建议可以试试下面这几个更有挑战性的方向。第一用行为日志里的时间间隔做“用户购买间隔预测”这个比单纯的复购预测更有业务价值能帮助运营确定用户触达的最佳时机。第二结合商品类目和地域分布分析不同省份的消费偏好差异。我在这份数据里发现南方省份在零食类目的消费占比明显高于北方而北方省份在家用电器类目的客单价更高。这种地域洞察对选品和区域化运营特别有用。第三把用户按首次购买类目分成不同的“首单标签”然后比较不同标签用户的 90 天留存。你会发现首次购买母婴类目的用户留存普遍高于首次购买数码类目的用户因为母婴是刚需高频品类数码是低频决策品类。这种分析对拉新投放的人群定向非常有参考价值。数据集的探索和分析方法在相当程度上是通用的掌握好这些思路换一批数据同样能打出漂亮的组合拳。这份数据集确实帮我把很多方法论从纸面变成了实战也让我在用户分层和类目挖掘上积累了不少可复用的脚本和代码。如果你手头正好缺一份国内电商场景的数据来练手认真把这套流程走一遍收获应该不会小。本文还有配套的精品资源点击获取 国内B2C电商脱敏数据集实战：用户画像、RFM模型与留存分析
简介电商数据分析离不开高质量的真实数据但业务数据往往涉及隐私难以直接取用。脱敏数据集在去除敏感信息的同时保留了核心业务逻辑成为技术验证与算法练手的关键资源。通过国内B2C场景的脱敏订单、用户及行为数据可以深入理解用户生命周期、复购规律与消费偏好。基于此类数据集实践SQL优化、Python数据处理、RFM模型分层、留存分析及关联规则挖掘能系统提升从数据清洗到业务洞察的完整能力。本文围绕一份国内某电商平台的脱敏数据集解析其字段设计、预处理要点与典型分析场景帮助数据从业者快速上手真实业务分析为构建用户画像和实施精细化运营提供可行路径。 做电商数据分析这么多年手里没几份像样的数据集很多活儿根本没法干。我经常在后台收到私信问有没有那种既能练手、又足够真实的电商数据最好是国内B2C场景的别整一堆英文电商的字段看得脑壳疼。今天就把我最近在折腾的一份国内某B2C电子商务网站的脱敏数据集拿出来聊聊不含任何用户隐私但业务字段和真实场景的逻辑都保留了非常适合拿来做用户画像、留存分析、RFM模型甚至简单的销量预测。这份数据集最打动我的地方在于它不是那种 Kaggle 上被刷烂了的洋玩意儿而是更贴近我们日常运营节奏的国内电商结构。订单号、SKU、类目层级、支付渠道、地域分布这些字段一应俱全拿到手里你就能直接跑分析不用花大量时间在字段映射上。无论你是刚入行的数据新人还是被“数据缺失”折磨的算法工程师这份数据集都能让你少走很多弯路。1. 数据集的核心价值与整体设计先给这份数据集定个调它模拟的是国内一个综合类 B2C 电商平台的交易与行为数据快照时间跨度覆盖了某自然年的四个季度。之所以强调“国内”是因为它的字段设计、业务逻辑和数据分布特征都符合咱们这边电商平台的常见套路比如促销节点618、双11、支付方式支付宝、微信、银行卡、收货地址的省市区划分等这些在国外公开数据集里是很难见到的。1.1 为什么我需要这份数据集在实际工作中我们经常遇到“巧妇难为无米之炊”的尴尬。公司内部数据敏感不能外带网上开源数据集要么太老要么是国外电商的玩法类目和用户习惯都对不上。这份数据集恰好补上了这个缺口它给我的价值主要体现在三个层面业务理解层面通过订单与用户表的关联能直观感受国内 B2C 场景下的用户生命周期价值比如新客首次购买集中在哪些类目、复购周期普遍是多少天。技术练手层面数据量级适中约为几十万条订单记录不至于让你的电脑跑个模型卡死又能充分考验 SQL 优化能力和 Python 处理效率。算法验证层面因为字段齐全做用户分群、推荐系统召回、甚至销售预测模型都有足够的特征支撑不至于像某些清洗过度的数据集那样跑完模型都不知道业务含义是什么。1.2 数据集的基本构成与体积拿到压缩包解压后里面主要是几个 CSV 文件和一份数据字典说明。我当时直接愣住了因为它比我想象的要“干净”很多字段命名也相当规范全是小写加下划线没有乱七八糟的乱码。核心文件包括用户信息表、商品信息表、订单主表、订单明细表以及用户行为日志表。文件大概情况是这样的文件名记录量级主要作用users.csv约 5 万条用户基础信息ID、城市、注册时间、年龄段products.csv约 2 万条商品类目、品牌、价格、上下架时间orders.csv约 30 万条订单主表包含支付状态、支付金额、下单时间order_items.csv约 45 万条订单明细SKU 级维度包含数量、单价user_behavior.csv约 200 万条用户浏览、点击、收藏、加购行为日志这个量级设计得很有讲究。200 万条行为数据跑 Pandas 不会崩溃但如果你用纯 Python 循环去处理绝对能让你等到怀疑人生这就逼着你学会用向量化操作。30 万条订单数据做月度趋势分析、RFM 分层结果都非常稳定不会因为样本太少而出现极端波动。1.3 数据脱敏与隐私保护的思路因为这涉及“不含隐私”这个关键点我必须拆开来说说数据脱敏这件事。这份数据集里的用户手机号、真实姓名、详细地址都做了不可逆的替换处理。具体来说用户手机号统一变成了“138****”后四位随机数详细地址只精确到市级后面的街道和门牌号全部抹掉了支付账号的 token 也做了哈希处理。这种脱敏处理方式是国内企业对外提供数据的常见做法既保留了数据的真实分布特征又彻底切断了与真实个人的关联。比如分析地域购买力时我们只需要知道用户在哪个省、哪个市完全不需要知道他在哪条街。分析支付渠道偏好时只需要知道用的是微信还是支付宝不需要完整的交易流水号。2. 核心字段解析与业务含义很多新手拿到数据第一件事就是 head() 看一眼然后就开始跑模型这是不对的。我在拿到这份数据集时花了整整两个小时仔细研究数据字典因为字段里的每一个细节都隐藏着业务逻辑。2.1 用户信息表里的“隐藏财富”users.csv 里的字段看起来简单其实暗藏玄机。除了常规的 user_id、注册时间这里有个字段叫user_source它标记了用户是通过什么渠道注册的比如搜索引擎、直接访问、广告投放、朋友邀请等。很多人会忽略它但我在之前的项目里做过一个渠道质量的分析广告带来的用户虽然首单转化快但 30 天留存率明显低于搜索渠道。这说明什么说明广告拉新可能拉来了一批“羊毛党”或者体验型用户他们领完优惠券就走了。再来看age_group这个字段它把用户划分成了几个年龄段区间。这里有一个很坑的细节它用的是“20”、“20-25”、“26-30”、“31-40”、“40”这种左开右闭的划分方式。在做可视化时如果不注意这个边界很容易把 25 岁的人划到 26-30 组里去导致柱状图数据对不上。2.2 订单表里的金额与状态陷阱orders.csv 是这份数据集里我最常用的表。payment_amount是用户实际支付的金额这个字段千万要注意它不是商品原价的总和而是已经扣除优惠券、满减活动和积分抵扣后的最终金额。而total_amount是订单的原价总额。两者一对比就能算出这个订单的折扣力度。我刚开始分析时发现有一个订单的支付金额竟然是负数差点以为数据清洗出问题了。后来查了数据字典原来是“退款订单”。在退款订单里支付金额被记录为负数表示资金退回给用户。遇到这种情况做销售额统计时一定要加个过滤条件把支付状态等于“已完成”且金额大于 0 的订单才纳入统计口径。payment_status字段有多个枚举值待支付、已支付、已取消、退款中、已退款。做留存分析时只保留“已支付”的订单但做转化率漏斗分析时就得把所有状态都算上看从下单到支付成功到底流失了多少用户。2.3 商品表里的类目层级细节商品信息表里最有分析价值的字段是category_path它是那种“食品休闲零食坚果炒货”的完整路径用大于号分隔。这个设计太方便做类目汇总了在 SQL 里用SPLIT_PART或者 Python 里用split就能轻松提取一级类目、二级类目。另外product_rating和rating_count这两个字段分别代表商品平均评分和评价数量。注意数据里有很多商品的rating_count为 0这说明它们上架时间短还没积累起评价。这类新品的转化率往往不稳定做推荐模型时可以采用“冷启动”策略而不是直接把它们丢进协同过滤算法里。2.4 行为日志表的时间与行为类型user_behavior.csv 是文件体量最大的一个每行记录代表用户的一个行为。behavior_type的枚举值包括浏览1、收藏2、加购3、购买4。这个字段用整数来表示行为类型是业内常见做法但我在实际处理时踩过坑如果直接把这个整数字段作为特征丢给机器学习模型模型会误以为“4”比“1”重要 4 倍这是毫无逻辑的。正确做法是进行 One-Hot 编码。还有行为日志里的时间戳是标准的 Unix 时间戳格式精确到秒。处理时要先转换成北京时间因为原始数据可能是按 UTC 存储的。别问我怎么知道的曾经有一次我画用户活跃曲线发现凌晨 2 点有个诡异的峰值查了半天才发现是时区没转换把早上的活跃数据推后了 8 个小时。3. 数据预处理与质量校验实战说实话这份数据集的质量在开源数据集里算好的但离“拿来即用”还有一定距离。我在预处理阶段就发现了不少有意思的问题这些问题恰恰是最能锻炼人的地方。这里我把整个清洗流程和关键代码思路分享出来都是可以直接抄作业的级别。3.1 缺失值处理的判断逻辑不同字段的缺失值处理策略完全不同不能一概而论。比如用户的city字段有少量为空这是因为用户没有授权获取位置信息我选择的是填充为“未知”。但订单表的coupon_id优惠券 ID为空这是正常的因为大部分订单都没用券这不能算是缺失而是“无该属性”。判断缺失值是否严重影响分析我通常会算一个缺失比例import pandas as pd orders pd.read_csv(orders.csv) missing_ratio orders.isnull().mean().sort_values(ascendingFalse) print(missing_ratio[missing_ratio 0])结果执行后我发现coupon_id的缺失率高达 68%user_coupon_amount用户券金额缺失率也接近 60%。这两个字段缺失比例高很正常说明大部分订单没有使用优惠券。我选择保留这些缺失值并在做特征工程时用 0 来填充因为“没使用券”本身就是一种业务状态。真正需要警惕的是关键字段的缺失比如payment_amount如果缺失这一行订单就得直接剔除因为它是后续所有分析的核心指标。在我这份数据里这类严重缺失的记录占比不到 0.3%剔除后对整体分布几乎没有影响。3.2 时间字段的标准化处理时间字段的坑最多我专门花了一小节来说。orders.csv 里的created_at是 Unix 时间戳但 user_behavior.csv 里的timestamp也是 Unix 时间戳。两者格式统一这很好但需要统一处理成可读时间import datetime orders[created_at] pd.to_datetime(orders[created_at], units) orders[created_at_cn] orders[created_at] pd.Timedelta(hours8) orders[order_month] orders[created_at_cn].dt.to_period(M)为什么要加 8 小时因为这份数据集的原始时间是按 UTC 记录的。如果不加你统计出来的“每日订单量”和实际的业务日会对不上尤其在上午 8 点到中午 12 点这段时间里的订单会被算到前一天去。3.3 重复数据与异常账户的识别有些用户可能是刷单号或者测试号它们在短时间内在同一家店铺购买了异常多的同类商品。为了不影响用户价值的分析结果我做了两步清洗。先去除全字段完全重复的记录再对明显异常的账户进行标记而不是直接删除这样能保留数据完整性同时在后继分析中可按需过滤。我当时还用了一个非常有效的指标——订单金额/订单商品数量的单价如果算出来的单价低于 0.01 元基本可以断定是异常订单。正常商品的价格不可能低于一毛钱除非是赠品。这类订单在数据里有两百多个是明显的测试数据在做销售额分析时应该剔除。4. 基于该数据集的典型分析场景数据集是死的但分析思路是活的。我把这份数据集在手上转了几圈梳理出了三个最能体现其价值的分析场景。每个场景都兼顾了业务意义和可操作性。4.1 用户生命周期与留存分析留存分析是电商数据分析最硬核的指标没有之一。这份数据集的时间跨度足够长可以支撑完整的留存分析。我以用户首次支付日期作为基准日观察他们在后续第 1 天、第 7 天、第 30 天的回来购买情况。具体操作如下先找每个用户的首次支付日期用 min 聚合再计算每个订单的支付日期与首次支付日期之间的天数差。然后按首购日期分组统计各组的留存率。实际跑出来的结果非常有意思新用户的次日留存率在 18% 左右而 30 天留存率只有 3% 左右。这个数字很真实说明电商拉新容易留人难。如果你仔细分析不同user_source的留存差异会发现来自搜索渠道的用户虽然首日转化看起来一般但 7 日留存率比广告渠道高出一倍。这给运营的启示是不能光盯着获客成本更重要的是看长期用户价值不然就是花钱买了个热闹。4.2 用户价值分层RFM 模型实战RFM 模型是电商用户分层的经典玩法它从最近一次消费时间Recency、消费频率Frequency、消费金额Monetary三个维度刻画用户价值。这份数据集带有的订单字段刚好能够支撑起一个完整 RFM 分析。我直接用 Python 写了一段脚本基于已支付的订单数据计算每个用户的 RFM 值。最近一次消费时间用数据集中最大日期减去用户最后一次支付日期消费频率是用户的总支付次数消费金额是累计支付金额。然后用分位数法把每个维度分成高、中、低三档最终组合出 8 类用户从“重要价值客户”到“流失客户”。这里的实操小技巧在分箱时如果直接使用pd.cut按等距分箱会受极端值影响导致大部分用户被分到低价值组。我建议先对金额做log1p变换或者直接用四分位数切分。跑出来的结果中重要价值客户约占总用户数的 5%但贡献了约 40% 的销售额典型的长尾分布这跟业务的直觉完全吻合。4.3 商品类目与购物篮关联分析关联规则挖掘是购物篮分析的核心方法用来挖掘“买了啤酒的人还会买尿布”这类规律。这份数据集里有足够的类目信息很适合做类目级别的关联分析。预处理时要注意一个订单往往包含多个商品需要先按订单号聚合把同一个订单内的商品类目合并成一组然后再用mlxtend库的apriori算法计算频繁项集和关联规则。我跑出来的结果里有一条规则是“购买婴幼儿奶粉的人有较高概率同时购买纸尿裤”提升度超过了 3。这在业务上完全说得通说明数据质量靠谱。还有一点值得玩味的就是做类目关联时不要直接用叶子类目比如“贝因美奶粉”而是用二级类目比如“奶粉/辅食”进行聚合否则数据会太稀疏算出来的关联规则没有统计意义。这个经验是我尝试了三次才搞明白的分享出来给大家避坑。5. 常见问题与排查技巧实录用这份数据集做分析的时候我踩过不少坑。这些问题说出来可能你觉得简单但当我第一次遇到时真的差点怀疑人生。5.1 为什么用户数比订单数还多我第一次统计数据的时候发现用户总量是 5.2 万而订单总数只有 4.1 万。当时第一反应是数据出错了因为按理说每个用户至少应该有一个订单。后来一查才知道数据里的用户表包含的是全量注册用户其中将近 1 万人注册后从未下过单。这是很符合真实业务的情况但也提醒我做转化分析时不要把注册用户数当成总分母应该用“有登录行为”“有浏览行为”的用户数作为起点否则转化率会低得离谱。5.2 同一订单 ID 对应多条商品记录订单表 orders.csv 是一行一个订单而订单明细表 order_items.csv 是一行一个商品。做金额汇总时如果直接用两个表关联再对订单主表进行分组很容易把金额翻倍。比如一个订单包含 3 个商品关联后会有 3 行每行都保留着订单总额此时如果不小心把订单总额加起来就等于重复算了 3 次。正确的做法是先以订单明细表为基础用单价乘以数量算出每个订单的明细总金额然后单独去和订单主表的支付金额核对。如果两者对不上优先以订单主表为准因为那是用户实际支付的钱明细表只是用于计算 SKU 级别的统计。这个原则在写 SQL 时放在脑子里能帮你躲掉很多坑。5.3 时间段划分对统计结果的影响如果你把数据按自然月分组统计销售趋势可以但要注意促销节点的前置效应。我在实际数据里发现每次大促前一周订单量会有一个明显的下滑而大促当天会暴涨。这种“脉冲式”波动如果按月聚合会平滑掉很多信息掩盖真实规律。我的建议是做趋势分析时按“周”聚合并且把大促当周单独标记出来。这样才能看出大促前后的用户行为差异不会把数据特征磨平。另外一个非常关键的细节是大促期间的payment_amount往往低于平时因为用了大量优惠券和满减分析客单价时如果不区分活动单结果会失真。5.4 数据处理性能优化技巧如果有人用这份数据做特征工程200 万行行为日志可能有点压手。我第一次直接用groupby统计用户行为次数跑了两分钟没跑完后来换了个思路先过滤掉不需要的字段再在 groupby 之前用astype压缩数据类型速度提升了将近十倍。behavior pd.read_csv(user_behavior.csv, usecols[user_id, behavior_type, timestamp]) behavior[behavior_type] behavior[behavior_type].astype(int8) behavior[user_id] behavior[user_id].astype(int32)这样做的原理很简单int64 转成 int8 后内存占用降低到原来的八分之一数据加载和分组计算都会快很多。特别是你打算用这块数据跑机器学习模型时节省下来的内存可以让你多开几个特征工程实验。6. 数据集的局限性与扩展思考这份数据集的优点很明显但局限性也摆在那里。如果你能正视这些局限反而能在分析时做出更合理的判断。6.1 时间跨度的限制数据集只覆盖了自然年内的四个季度没有跨年数据。这导致我无法分析季节性周期变化比如春节前后消费习惯的差异。对于想要做时间序列预测的朋友来说这个长度刚好够做简单的月级别预测但想做更复杂的 SARIMA 模型数据量就略显不足。6.2 没有退货与售后服务数据订单数据里虽然有退款状态但没有退货原因、退货时效、客服介入记录等售后字段。这意味着我无法从这份数据中分析售后体验对复购率的影响而售后体验恰恰是国内电商平台留存率的重要影响因素。如果你在某个场景下需要分析“为什么用户流失”这份数据会显得有些单薄。6.3 如何扩展这份数据的分析价值我在实际使用中尝试把它和公开的节假日日历结合增加了一些“是否节假日”“是否促销日前一周”的特征字段然后预测每天的订单量效果提升了不少。另外也可以根据商品的价格带分布构建一些价格敏感度特征分析用户在不同价格区间的购买偏好。另一种扩展方向是把行为日志做成用户到商品的“行为序列”再用 Word2Vec 来学习商品的向量表示这样就能做简单的相似商品推荐或者直接喂给深度兴趣网络做召回。粒度虽然粗了点只有类目级没有 SKU 级但配合商品的类目特征在冷启动场景下依然有不错的参考价值。from gensim.models import Word2Vec # 构建每个用户的商品类目序列 user_seq behavior_df.groupby(user_id)[category_path].apply(list).tolist() model Word2Vec(user_seq, vector_size64, window5, min_count2, sg1)这一跑模型训练特别快效果意外地好。用相似类目做召回在离线评估里的召回率能达到不错的水准。所以说不管数据集是别人的还是自己的关键在于能不能挖掘出它的潜力。7. 实操总结与避坑清单这份数据集我前前后后用了大概一个星期从最开始的字段探索到中间的清洗和特征工程最后跑出用户分层和关联分析整个流程走下来确实比单纯的造数练习要有价值得多。最后把这几天踩过的坑和沉淀下来的经验整理成一个清单希望能帮第一次接触这份数据的朋友省点时间。7.1 上手必看的避坑清单金额字段别乱用total_amount是原价payment_amount才是实际支付统计业绩用后者分析折扣力度用两者差值。退款订单的金额是负数记得过滤。时间必须转时区原始时间戳是 UTC直接转 pandas 时间类型后要加 8 小时才是北京时间。不然后续所有按天、按小时的分析都会偏移。行为类型要 One-Hotbehavior_type的 1-4 是分类不是数值不能直接当特征喂模型必须转换成哑变量。类目字段用“”分隔category_path里是“一级二级三级”的结构用 split 就能拆出各级类目别自己手写正则去匹配。留存计算别用全量用户做分母应该用当日有活跃行为的用户数或者至少用当日有支付行为的用户数否则留存率会被严重稀释。7.2 值得一试的进阶玩法如果你已经把基础分析都做完了我建议可以试试下面这几个更有挑战性的方向。第一用行为日志里的时间间隔做“用户购买间隔预测”这个比单纯的复购预测更有业务价值能帮助运营确定用户触达的最佳时机。第二结合商品类目和地域分布分析不同省份的消费偏好差异。我在这份数据里发现南方省份在零食类目的消费占比明显高于北方而北方省份在家用电器类目的客单价更高。这种地域洞察对选品和区域化运营特别有用。第三把用户按首次购买类目分成不同的“首单标签”然后比较不同标签用户的 90 天留存。你会发现首次购买母婴类目的用户留存普遍高于首次购买数码类目的用户因为母婴是刚需高频品类数码是低频决策品类。这种分析对拉新投放的人群定向非常有参考价值。数据集的探索和分析方法在相当程度上是通用的掌握好这些思路换一批数据同样能打出漂亮的组合拳。这份数据集确实帮我把很多方法论从纸面变成了实战也让我在用户分层和类目挖掘上积累了不少可复用的脚本和代码。如果你手头正好缺一份国内电商场景的数据来练手认真把这套流程走一遍收获应该不会小。本文还有配套的精品资源点击获取