唇釉大促价格错位致22%退款率
一、数据集说明
1.数据集
通过网盘分享的文件:唇釉大促价格错位致22%退款率
链接: https://pan.baidu.com/s/1hSxJdvEPQMF3zJ-wjqVVPQ?pwd=dcji 提取码: dcji
2.数据字段说明
订单表 sales_detail_generated.csv
| 字段名 | 中文含义 | 说明 |
| order_id | 订单编号 | 唯一标识一笔订单 |
| order_time | 下单时间 | 用户提交订单的时间 |
| promo_name | 活动名称 | 参与的促销 / 优惠券活动名称 |
| product_name | 商品名称 | 购买的商品名 |
| item_url | 商品链接 | 商品详情页地址 |
| quantity | 购买数量 | 该商品下单件数 |
| original_unit_price | 原价单价 | 商品未优惠前单价 |
| coupon_amount | 优惠券金额 | 该商品分摊的优惠金额 |
| order_gmv | 订单 GMV | 订单交易总额(通常为原价口径) |
| avg_actual_unit_price | 实际平均单价 | 优惠后实际支付的单件价格 |
查询表 beauty_data_all.csv
| 字段名 | 中文含义 | 说明 |
| user_id | 用户 ID | 唯一标识一个用户 |
| inquiry_time | 咨询时间 | 用户发起咨询的时间 |
| category | 咨询分类 | 问题类型,如售后、物流、商品、活动、投诉等 |
| content | 咨询内容 | 用户提问的具体文本 |
退款表 refund_detail_generated.csv
| 字段名 | 中文含义 | 说明 |
| refund_id | 退款单号 | 退款记录唯一标识 |
| order_id | 订单编号 | 关联原订单 ID,可与订单表关联 |
| promo_name | 活动名称 | 原订单参与的促销活动 |
| product_name | 商品名称 | 退款对应的商品 |
| order_time | 下单时间 | 原订单下单时间 |
| refund_time | 退款时间 | 发起 / 完成退款的时间 |
| original_quantity | 原购买数量 | 该商品原下单件数 |
| refund_quantity | 退款数量 | 本次退回商品件数 |
| avg_actual_unit_price | 实际单价 | 商品优惠后实际成交单价 |
| refund_amount | 退款金额 | 本次实际退回给用户的金额 |
| refund_reason | 退款原因 | 如质量问题、不想要、发错货、物流问题等 |
二、业务说明
1. 业务现状
本次唇釉大促主推“第2件半价,第3件低至20元”的阶梯降价策略,旨在提升客单价与连带率。
但底层结算系统受财务规则限制,采用的是“总价打折,均价分摊”逻辑
(例如:买3件实付240元,订单明细显示单件80元,而非第3件20元)。
2. 核心痛点
前端转化受损:宣导的边际低价与结算页的均价展示无法对齐,引发消费者强烈的“被欺骗感”,推高了流失率。
后端客服承压:大量用户因“价格算不明白”涌入客服链路,引发无效进线激增,严重挤占人工座席资源。
3. 分析目标
验证“均价分摊”逻辑是否被严格执行。
量化“复杂营销规则”带来的真实退款率波动与 GMV 损失。
挖掘核心客诉原因,输出产品与运营侧的降本增效优化方案。
三、数据处理
将订单数据 sales_detail_generated.csv 和退款数据 refund_detail_generated.csv 进行去重等处理。
1.加载两个表的数据,分别查看数据总长度
![]()
2.对订单表进行去重处理
![]()
由此可知,该表没有重复值
3.手动计算单价,验证数据准确性
计算验证单价(calculated_avg_price):订单实付金额 (order_gmv) / 购买件数 (quantity)
抽取前5行比对系统均价与我们计算的均价

由表可知,系统均价和我们计算均价一样(最后多看几个,确保数据准确性)
四、探索性数据分析(EDA):流失量化与归因
核心假设探究:
凑单门槛越高,是否退款率也越高?
造成退款的致命原因究竟是什么?
1.统计各购买件数的
针对订单表,以购买件数分组,查看不同分组的订单数量分别是多少
'order_id': 'total_orders'
'quantity': 'buy_quantity'

2.统计各购买件数的退款订单量
针对退款表,以原始购买件数分组,查看不同分组的退款订单数量分别是多少
'refund_id': 'refund_orders'
'original_quantity': 'buy_quantity'
| calculated_avg_price | 计算验证单价 |

3.合并以上两表便于后面计算

计算退款率并将其插入上表
退款率 = 退款订单 / 总订单数

4.数据表现分析
发现一:

由此可知,不同的购买件数的退款率表现也不同
发现二:
按退款原因分组,统计对应原因导致的退款订单数和该原因导致的退款总金额
| refund_reason | 退款原因 |
| refund_count | 退款订单数 |
| lost_gmv | 退款总金额 |

五、数据可视化分析


六、分析结果
📌 核心结论
数据明确证实,虽然“第3件低至20元”的阶梯策略拉动了用户凑单,
但前端营销宣导与后端结算“均价分摊”逻辑产生了严重的预期错位。
这直接导致 3件凑单退单率飙升至 22.13%,引发近一半的退款单量,并造成直接经济损失近 25万元。
🚀 业务优化方案
为实现降本(降客诉)增效(保转化),强烈建议多部门实施以下联动改造:
1. 🎨 产品与前端 UI 侧:隐藏均价,强化全局减免视觉
由于底层财务分摊逻辑短时间内不可逆转,必须在前端订单确认页打补丁:
禁止展示单价:在购物车和结算页,绝对隐藏“单价80/件”的字眼。
重构计费视觉:采用全局算账逻辑,即 商品总价 ¥330 ➖ 大促立减 -¥90 🟰 实付金额 ¥240。
2. 📢 营销运营侧:摒弃边际报价,转为直给型承诺
停止引发歧义的“单件低至X元”话术,转为所见即所得的整单报价,消除用户的心理算账落差。
❌ 优化前:“第2件半价,第3件低至20元”
✅ 优化后:“买3件,立省90元” 或 “买3件,到手仅需240元”。
3. 🤖 客服服务侧:拦截防御体系前置
商品页(PDP)防御:在商品主图区增加一张明确的“凑单算账一览表”。
AI 意图拦截:为智能机器人配置专属的【大促价格计算器】卡片,
一旦识别到用户询问“金额、凑单、不一致”等问题时优先下发图文阻断,释放人工客服资源处理高价值进线。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。
更多推荐
所有评论(0)