购物篮分析01 / 18

复现 + 诊断 + 优化

商品零售购物篮分析

基于 GoodsOrder.csv 与 GoodsTypes.csv，严格复现书中 Apriori 案例的代码逻辑、参数设定和输出口径，再从数据、方法、模型和决策表达四个维度做诊断与优化。

BRDICD 汇报结构书本代码复现 FP-Growth 替换业务决策建议

小组分工

戴钟耀总体统筹与汇报主讲，负责整体逻辑把控与结论整合。

丘文豪数据整理与数据口径核对，负责原始表检查、字段理解与事务数据准备。

毛俊沣书本代码复现，负责 Apriori 流程运行、参数对齐与原始结果输出。

罗斯恩可视化制作，负责热销商品、品类结构与模型对比图表整理。

汪海涛问题诊断与规则解读，负责结果分析、偏置识别与业务含义提炼。

龚福涛模型优化，负责 FP-Growth 替换、阈值重设与品类级规则构建。

陈计任PPT 撰写与版面整合，负责页面组织、文字润色与最终材料汇总。

41080当前 CSV 商品记录数

9356购物篮笔数

158商品数量

9品类数量

结论导向问题：哪些商品该相邻陈列？哪些组合值得捆绑？仅有规则表为什么还不够支撑经营决策？

分析路径：先复现关联规则建模流程，再从结果解释、方法改进和经营应用三个层面展开。

汇报结构02 / 18

汇报围绕 BRDICD 六个环节展开

B

背景

书本案例目标
零售业务问题
数据来源与边界

R

复现

代码运行
流程解析
原始结果

D

诊断

数据问题
方法问题
模型问题

I

优化

方法改进
模型替换
阈值重设

C

对比

指标对比
规则数量
可视化对照

D

决策

哪个更好
业务建议
后续路径

背景03 / 18

书本案例要回答的，本质上是一个零售经营问题

书中目标

构建零售商品的 Apriori 关联规则模型，分析商品之间的关联性；再根据模型结果给出销售策略。

业务翻译

哪些商品经常一起出现，适合相邻陈列？
哪些商品组合适合捆绑、满减或联促？
如何从“规则很多”中挑出真正值得执行的规则？

分析范围

本次分析以既有零售案例为基础，先复现关联规则挖掘流程，再对结果进行诊断、优化与经营解释。

数据口径说明

书页中写的是 9835 个购物篮、169 个商品、43367 条记录；当前项目下实际 CSV 是 9356 个购物篮、158 个商品、41080 条记录。

所以：代码逻辑可以完全复现，结果口径可以完全复现，但具体数值会跟着当前 CSV 版本变化。

9835书中购物篮数

9356当前购物篮数

169书中商品数

158当前商品数

分析含义

这说明结果解读需要同时结合数据版本、参数设定与输出口径，不能孤立看待单张结果表。

复现流程04 / 18

购物篮分析复现可以概括为探索、转换、建模与解释四个环节

STEP 01数据探索

先确认数据规模、字段类型、商品热度和品类分布，避免直接建模但不了解数据。

STEP 02事务转换

把明细长表压缩成以订单为单位的事务列表，这是 Apriori 计算支持度的前提。

STEP 03规则生成

按最小支持度和最小置信度筛频繁项集，再以 lift>1 剔除随机共现。

STEP 04业务解释

把规则从“算法输出”翻译成“陈列、联促、补货与区域布局建议”。

流程中的三个关键点

为什么订单明细不能直接送入 Apriori。
支持度、置信度、提升度分别起什么约束作用。
为什么单品规则还需要再上升到品类级表达。

if __name__ == '__main__':
    dataSet = data_translation
    L, supportData = apriori(dataSet, minSupport=0.02)
    rule = gen_rule(L, supportData, minConf=0.35)

# 参数解释
# support = 0.02   保证规则不是极小概率噪声
# confidence = 0.35 保证前件对后件有解释力
# lift > 1          保证不是独立随机共现

复现 / 数据理解05 / 18

建模之前需要先明确数据对象、记录粒度和分析范围

原始数据表的含义

字段	含义	分析作用
id	购物篮或订单编号	用于把多行商品明细合并成一个事务
Goods	订单中购买的具体商品	用于统计销量、构造频繁项集
Types	商品所属品类	用于做品类结构分析和品类级关联规则

记录粒度

当前 CSV 是一行一件商品，不是一行一个订单。

分析单位

建模时真正的单位是购物篮，也就是一次购买行为。

核心风险

如果不先按 id 合并，支持度和置信度都会失真。

数据边界决定了能回答什么问题

能回答：哪些商品或品类经常一起出现。
暂时不能回答：哪些门店更明显、哪个时间段更突出、不同用户群差异如何。
因此本次输出更适合做共购关系识别，而不是做完整的精准营销分群。

关键理解

购物篮分析的前提是先确认“明细数据如何变成事务数据”。只有记录粒度一致，后续的支持度和规则才具备解释意义。

41080明细记录数

9356购物篮数

158商品数

9品类数

复现 / 数据探索06 / 18

先确认数据特征和热销中心，再决定后续从哪些层级解释结果

运行截图首先给出数据规模与规则总量，属于后续所有分析的基础口径。

流程解析

这一段先做数据读取、info 查看和商品销量聚合。目的不是预测销量，而是找出哪个商品在购物篮网络中最可能成为核心节点。

当前数据下，全脂牛奶、其他蔬菜、面包卷、苏打、酸奶是销量最高的五类商品。

结果含义

热销商品不等于强关联商品，但往往是后续规则的高频后件。
像全脂牛奶这样的中心商品，很容易在多条规则中重复出现。
这也解释了为什么后面需要做规则筛选，而不是只堆一张规则表。

复现 / 结构分析07 / 18

商品层和品类层要分开看，这决定了后续建议是“补货”还是“陈列”

品类层视角下，饮料、西点、果蔬三类销量最接近，是零售篮子中的核心结构。

流程解析

这一步将销量表与品类映射表合并，再对 Types 聚合。原本分散的单品销量被提升为品类结构，适合从经营资源配置角度解释。

在饮料内部，全脂牛奶占比最高，说明其既是热销商品，也可能成为后续联动销售的核心后件。

经营含义

商品级结论更适合做补货、单品促销和捆绑。
品类级结论更适合做货架区位和区域陈列。
因此后面加入品类级规则不是重复建模，而是补一个更接近经营动作的解释层。

复现 / 事务转换08 / 18

明细表必须先转换成事务表，这一步是 Apriori 建模真正的输入准备

转换前后的数据形态

id	Goods	Types
1001	全脂牛奶	饮料
1001	面包卷	西点
1001	黄油	米粮调料

按 id 聚合后，一个购物篮会变成：[全脂牛奶, 面包卷, 黄油]

为什么不能跳过这一步

因为频繁项集计算的是“同一个订单里共同出现了哪些商品”。如果仍然按明细行计算，算法会把同一购物篮拆散，导致共购关系被低估。

data['Goods'] = data['Goods'].apply(lambda x: ',' + x)
data = data.groupby('id').sum().reset_index()
data['Goods'] = data['Goods'].apply(lambda x: [x[1:]])
data_list = list(data['Goods'])

data_translation = []
for i in data_list:
    p = i[0].split(',')
    data_translation.append(p)

输入

订单商品明细长表

处理

按 id 聚合并拆分商品字符串

输出

每个订单对应一个商品列表

转换价值

这一步把算法之前的数据准备过程显式展开，说明频繁项集分析依赖的并不是原始明细表，而是按订单组织后的事务型数据。

复现 / 建模原理09 / 18

支持度、置信度和提升度共同决定了一条规则能不能被保留下来

频繁项集

先找在大量购物篮中反复出现的商品组合。没有达到最小支持度的组合，后面不会进入规则生成。

支持度

表示某组合在全部购物篮中出现的比例。支持度低，说明组合太稀疏，业务上不稳定。

置信度

表示买了前件商品后，再买后件商品的条件概率。置信度越高，规则的解释力越强。

提升度

表示前件出现后，后件出现的概率相对于随机购买是否被显著放大。只有 lift>1 才说明存在正向联动。

可以直接口头解释的例子

如果“其他蔬菜 ⇒ 全脂牛奶”的置信度为 0.3868，意思是买其他蔬菜的顾客中，大约 38.68% 也会买全脂牛奶。

如果该规则 lift 为 1.44，则说明这种共购概率比随机购买全脂牛奶高出 44% 左右，不是巧合。

为什么三个指标缺一不可

只有支持度，没有方向性。
只有置信度，容易被热门商品“抬高”。
只有提升度，可能保留过于稀疏的小众规则。

复现 / 规则输出10 / 18

在书本参数下，当前数据共输出 28 条有效规则，结果具有明显中心商品特征

当前 CSV 的复现结果

在 support=0.02、confidence=0.35、lift>1 的筛选下，最终得到 28 条规则。代表性规则如下：

lhs	rhs	support	confidence	lift
{其他蔬菜}	{全脂牛奶}	0.078666	0.386758	1.439915
{酸奶}	{全脂牛奶}	0.058893	0.401603	1.495186
{根茎类蔬菜}	{其他蔬菜}	0.049808	0.434701	2.137187

运行结果说明代码逻辑已经完整复现，并且输出数量可控，适合进一步解释。

现象 1

全脂牛奶多次作为后件出现，说明它是购物篮中的中心商品。

现象 2

蔬菜之间的规则 lift 更高，说明部分共购关系更像同场景采购。

现象 3

规则条数不算多，但已经足够说明商品之间存在稳定的共购结构。

复现 / 规则解读11 / 18

规则表不能只读数字，必须翻译成顾客场景和可执行动作

规则 A：其他蔬菜 ⇒ 全脂牛奶

support = 7.87%，confidence = 38.68%，lift = 1.44。

场景理解

果蔬购买与基础饮品采购具有明显重叠，接近家庭日常采购场景。

可执行动作

蔬菜区与冷藏饮品区形成顺路动线。
围绕蔬菜做牛奶搭售推荐。

规则 B：酸奶 ⇒ 全脂牛奶

confidence 达到 40.16%，说明乳制品内部存在稳定的连带购买。

场景理解

顾客并不是只买单一饮品，而是在同一消费场景下进行组合采购。

可执行动作

冷藏柜内部做乳制品相邻陈列。
设计“早餐饮品组合”促销主题。

规则 C：根茎类蔬菜 ⇒ 其他蔬菜

lift 超过 2.13，是当前展示规则中联动性最强的一类。

场景理解

顾客在购买蔬菜时更像是在完成一篮子食材采购，而不是单点补货。

可执行动作

蔬菜区按烹饪场景重组，而不是按单品孤立摆放。
推出“家庭做菜组合”联促。

诊断12 / 18

从结果可用性看，这个案例至少暴露出五个核心问题

问题 1：数据版本差异

书中统计规模与当前 CSV 不一致，说明案例结果会受到数据版本变化影响，不能机械照搬书页数值。

问题 2：数据维度不足

现有数据只有订单、商品和品类，缺少时间、门店、价格和用户属性，导致分析结论更偏共购识别，难以直接支撑精细运营。

问题 3：热门商品偏置

全脂牛奶等高频商品会在多条规则中反复出现，容易抬高置信度，使规则表看起来很多，但差异化信息有限。

问题 4：教学算法效率有限

Apriori 需要反复扫描候选项集，适合作为方法展示，但在更大规模数据上并不是效率最优的求解方式。

问题 5：规则可执行性不足

单品级规则可以说明共购关系存在，但不一定能直接转化为货架、区域和促销动作，业务解释层仍然偏薄。

数据层

版本差异、维度不足

模型层

热门商品偏置、算法效率

应用层

规则解释力和落地性不足

诊断13 / 18

上述问题之所以重要，是因为它们会直接影响结果稳定性和决策质量

稳定性风险

当支持度和置信度阈值发生变化时，规则数量可能快速膨胀或收缩，说明模型输出对参数较敏感。

筛选成本

若规则过多而且大量指向同一热门商品，业务方很难判断哪些规则值得优先执行。

解释断层

从单品到经营动作之间缺少中间层，导致“看得懂结果”与“用得上结果”之间仍然存在距离。

价值偏差

当前指标只衡量共购强弱，没有结合毛利和场景价值，因此高频规则不一定就是高价值规则。

对本次案例的直接影响

需要把“是否与书本一致”和“是否适合经营解释”分开评价。
需要压缩规则数量，提高结果可读性和可筛选性。
需要从单品规则补充到品类规则，增强经营表达。

因此优化目标可以明确为三点

提高求解效率。
提高结果层级的解释力。
提高规则结果的可执行性。

优化14 / 18

优化的第一层，是把“能跑”升级为“更高效、结构更清楚”

优化 1：Apriori 替换为 FP-Growth

在商品级阈值保持不变的情况下，FP-Growth 仍输出 28 条规则，说明更换求解方式后，核心结论不变，但实现效率更高。

优化 2：结果层级从商品扩展到品类

品类级规则能够把“酸奶带出牛奶”提升为“饮料与果蔬共同带动其他品类”，更适合转换为经营动作。

优化 3：重新设计筛选口径

品类级规则如果沿用商品级阈值，结果会过多，难以阅读，因此必须重新设置支持度和置信度来控制输出规模。

# 路线 A：商品级 FP-Growth
goods_freq = fpgrowth(goods_matrix, min_support=0.02)
goods_rules = association_rules(goods_freq, metric='confidence', min_threshold=0.35)

# 路线 B：品类级 FP-Growth
type_freq = fpgrowth(type_matrix, min_support=0.15)
type_rules = association_rules(type_freq, metric='confidence', min_threshold=0.55)
type_rules = type_rules[type_rules['lift'] > 1]

这一层优化解决的问题

求解过程更轻，适合扩大数据规模。
规则层级更高，更接近经营语言。
输出数量可控，便于展示与筛选。

优化15 / 18

优化的第二层，是回答“为什么阈值要这样调整”

商品级阈值保持不变

保留 support=0.02、confidence=0.35 的原因，是为了与书本案例在结果口径上保持一致，便于完成复现验证。

品类级阈值必须上调

品类数量远少于商品数量，若继续沿用低阈值，会产生大量共现规则。把阈值提高到 0.15 / 0.55，可以过滤掉弱规则和泛化规则。

为什么还要保留 lift > 1

即使置信度较高，如果提升度不超过 1，也可能只是热门品类带来的自然高频共现，不足以说明正向联动关系。

调参前

品类级规则 1269 条，信息过载，难以筛选。

调参后

压缩到 28 条，数量与商品级结果相当。

直接效果

规则更集中，更容易形成经营重点。

阈值调整的实际意义

不是为了让结果“好看”，而是为了提高结果稳定性与解释密度。
让每条留下来的规则都更有可能对应明确场景。
避免把大量弱关联关系带入经营决策。

对比16 / 18

对比的重点不是算法名字，而是三种方案分别适合回答什么问题

商品级 FP-Growth 与书本 Apriori 在当前阈值下都得到 28 条规则；品类级只有在重新设阈值后才具备可读性。

方案评价

书本一致性95

运行效率88

经营解释力92

三种方案适用场景

方案	优势	更适合回答的问题
书本 Apriori	最接近教材流程	是否完成原案例复现
FP-Growth 商品级	效率更高，结果一致	哪些单品存在稳定共购
FP-Growth 品类级	解释层级更高	哪些品类组合值得陈列与联促

对比结论

若目标是课程复现，应保留商品级结果作为基线。
若目标是经营解释，应优先使用品类级规则进行表达。
二者不是互相替代，而是分别服务于“验证”和“决策”。

经营约束17 / 18

当前模型已经能够支持基础陈列建议，但经营应用仍受数据维度限制

当前局限

没有时间字段，无法判断工作日、周末或节庆场景差异。
没有门店字段，无法比较不同门店陈列策略是否一致。
没有价格与毛利字段，无法把规则直接转化为利润导向决策。
没有用户标签，无法识别不同客群的共购差异。

当前可支持的决策边界

现阶段更适合输出通用陈列、基础联促和补货优先级，而不适合直接下沉到门店差异化运营和会员个性化推荐。

进一步应用方向

加入时间维度，识别早餐、晚餐、周末家庭采购等场景规则。
加入门店维度，判断社区店与商圈店的差异化组合。
加入金额和毛利，优先保留高价值而非仅高频的组合。
加入会员与客群标签，形成差异化推荐策略。

短期

优化陈列和联合促销。

中期

增加时间与门店维度。

长期

形成精细化推荐体系。

决策18 / 18

综合结论：商品级结果用于复现验证，品类级结果用于经营决策

模型选择结论

商品级 Apriori / FP-Growth 适合用于验证书本案例、说明单品共购关系。
品类级 FP-Growth 更适合用于支持货架布局、区域陈列和组合促销等经营动作。

综合结论

已完成关联规则建模流程的完整复现。
识别出数据版本差异及结果表达层级的局限。
通过 FP-Growth 与品类级规则提升了结果的经营解释力。

优化版终端输出展示了改进模型在当前参数下的结果表现。

结论总结

购物篮分析的核心价值在于从共购关系中识别稳定消费场景，并将其转换为可执行的陈列、联促和补货策略。