简介这份资源面向数据挖掘初学者与商业分析方向的学习者围绕Apriori关联规则展开市场购物篮分析实战帮助读者从零理解频繁项集发现、支持度与置信度度量、强关联规则生成及规则评估的完整流程。压缩包共4个文件约20.36MB包含csv与xlsx两种格式的原始交易数据集便于直接读取与预处理同时提供ipynb代码笔记与html导出文件方便对照运行、复现结果并理解每一步实现逻辑。资源已有270人学习下载适合作为课程作业或自学练手案例。通过这份资料读者可以亲手完成数据清洗、参数调整与结果解释掌握从数据准备到规则筛选的完整链路并体会关联规则在货架摆放、商品推荐与促销策略中的实际价值为后续更复杂的数据挖掘项目打下基础。1. 购物篮里翻出真金白银Apriori 关联规则到底在挖什么超市收银台每天吐出几千条流水绝大多数人只把它当账本可有人靠它发现「买尿布的人顺手拎啤酒」这种反直觉组合把堆头一挪两个品类销量一起涨。这背后就是市场购物篮分析而 Apriori 是干这活最经典、最容易上手的算法。它要解决的问题很朴素从一堆「一次交易里同时出现的商品集合」中找出频繁共现的组合再量化成「买了 A 的人有多大比例会买 B」。适合谁手里有订单流水、想找交叉销售机会的运营和数据分析师以及刚学完 Python 基础、想拿一个完整数据集跑通数据挖掘全流程的入门者。这篇不聊虚的从数据集长什么样、代码怎么跑、参数怎么调一路讲到结果怎么读、坑在哪。2. 先把数据喂对购物篮分析的输入长什么样2.1 交易数据的两种形态与转换逻辑购物篮分析吃的是「事务型数据」最原始的样子就是一行一条交易记录同一单里的多个商品挤在一个字段里用逗号或分号隔开。这种格式人看着舒服算法却读不了Apriori 要的是「每行一个商品、同一单共享一个订单号」的清单式结构或者直接是「每行一个项集」的列表。常见做法是先把原始流水整理成两列订单号、商品名一个订单有几个商品就占几行。这一步看着简单却是后面所有结果的地基订单号错一位整个关联网络就歪了。我一般会先做三件事去重、去空、统一商品名。同一商品写成「可口可乐 330ml」和「可乐330」在算法眼里是两个东西频繁项集会被硬生生拆散。商品名里的空格、大小写、全半角也要统一否则统计出来的支持度全是碎片。2.2 用 Python 把流水整理成事务列表import pandas as pd # 读取原始订单明细假设两列order_id, product_name df pd.read_csv(orders.csv, encodingutf-8) # 基础清洗去掉商品名为空的行统一去空格 df df.dropna(subset[product_name]) df[product_name] df[product_name].str.strip() # 按订单号聚合把同一单的商品收成一个列表 baskets df.groupby(order_id)[product_name].apply(list).tolist() # 看一眼前 3 单长什么样 for b in baskets[:3]: print(b)这段代码的核心是groupby(order_id)加apply(list)把散落的商品行重新捏回一单一单的篮子。dropna和strip是防脏数据的后悔药别省。如果你的原始数据是一行一单、商品用逗号隔开那就换成df[items].str.split(,)再逐行转成列表效果一样。跑完这一步baskets就是一个二维列表每个子列表代表一次交易后面直接喂给 Apriori。2.3 稀疏问题的预处理别让长尾商品拖垮结果真实流水里往往有大量只出现过一两次的商品它们进不了频繁项集却会白白拉长计算时间。常见做法是先统计单品出现频次把低于某个阈值的商品过滤掉。这个阈值不用拍脑袋可以先看频次分布砍掉明显的长尾。注意过滤太狠会丢掉潜在组合过滤太松又慢我一般先按总订单数的 0.5% 到 1% 试一版看结果再微调。3. Apriori 怎么跑支持度、置信度、提升度三个旋钮3.1 三个指标到底在衡量什么支持度Support说的是「这个组合在所有交易里出现的比例」比例太低说明只是偶然没有推广价值。置信度Confidence说的是「买了 A 的人里有多少也买了 B」它衡量规则的可靠程度。但置信度高不代表有价值因为如果 B 本身就是爆款谁买什么都容易带上它。这时候就要看提升度Lift提升度大于 1说明 A 的出现确实让 B 更容易被买等于 1 说明两者独立小于 1 说明 A 反而抑制了 B。三个指标要一起看单看置信度是最容易翻车的地方。3.2 最小可运行代码从 baskets 到关联规则from mlxtend.preprocessing import TransactionEncoder from mlxtend.frequent_patterns import apriori, association_rules # 把二维列表转成 one-hot 编码的 DataFrame te TransactionEncoder() te_ary te.fit(baskets).transform(baskets) df_encoded pd.DataFrame(te_ary, columnste.columns_) # 跑 Apriorimin_support 先设 0.01即至少 1% 的订单包含该组合 frequent_itemsets apriori(df_encoded, min_support0.01, use_colnamesTrue) # 生成关联规则min_threshold 用置信度 0.3 起步 rules association_rules(frequent_itemsets, metricconfidence, min_threshold0.3) # 按提升度降序看最有价值的规则 rules rules.sort_values(lift, ascendingFalse) print(rules[[antecedents, consequents, support, confidence, lift]].head(10))TransactionEncoder负责把商品列表转成算法认识的 0/1 矩阵apriori负责挖频繁项集association_rules再把项集变成「A 推 B」的规则。min_support0.01是支持度下限min_threshold0.3是置信度下限这两个数直接决定输出多少条规则。跑完先看lift排序提升度高的规则才是真正值得摆堆头、做捆绑的组合。3.3 参数怎么调从宽到窄的三轮筛法第一轮把min_support设低一点比如 0.005先让算法把可能的组合都吐出来看看数据里到底有多少频繁项集。如果项集数量爆炸说明支持度太低往上调到 0.02 或 0.03。第二轮固定支持度调置信度从 0.2 开始往上加观察规则数量断崖式下跌的位置那个位置附近就是比较稳的阈值。第三轮只看提升度大于 1.2 的规则把明显独立的组合剔掉。三轮下来剩下的规则通常几十条以内足够业务侧一条条过。提示支持度和置信度没有标准答案同一份数据在不同业务目标下最优参数不同。先跑通再调参别一上来就追求「最优」。4. 结果读不懂等于白跑规则解释与业务落地4.1 从规则表到可执行动作跑出来的规则表里antecedents是前件consequents是后件support是这条规则覆盖的交易比例confidence是前件出现时后件也出现的概率lift是提升倍数。业务侧最关心的是「我该做什么」。提升度高、支持度也过得去的规则可以直接拿来做捆绑促销、货架相邻陈列、满减凑单推荐。支持度太低但提升度很高的规则适合做小范围测试别一上来就全店推。4.2 用散点图快速筛出值得看的规则import matplotlib.pyplot as plt plt.scatter(rules[support], rules[confidence], crules[lift], cmapviridis) plt.colorbar(labellift) plt.xlabel(support) plt.ylabel(confidence) plt.axhline(y0.5, colorr, linestyle--) # 置信度参考线 plt.axvline(x0.02, colorr, linestyle--) # 支持度参考线 plt.show()这张图把支持度、置信度、提升度三个维度压在一张平面上颜色越亮提升度越高。右上角区域是「支持度和置信度都不错」的规则优先看左上角是「置信度高但支持度低」的规则适合小范围试右下角支持度高但置信度低说明组合太普遍没什么区分度。画一次图比翻十页表格快得多。4.3 规则去重与冗余处理Apriori 容易产出大量冗余规则比如「A→B」和「A,C→B」可能同时出现后者只是前者的加强版。常见做法是看规则的前件和后件长度优先保留短规则因为短规则更容易执行。另外如果两条规则前件后件互换但提升度接近说明是双向强关联可以合并成一条「A 与 B 强关联」的结论不用重复看。5. 避坑与排查Apriori 实战里最容易翻车的五件事5.1 支持度设太高一条规则都跑不出来现象代码跑完frequent_itemsets是空的或者只有零星几个单品。原因min_support设得比数据里最频繁组合的出现比例还高。解决先算一下总订单数和单品最高频次把min_support设成「最高频次除以总订单数」的一半左右再逐步往上调。5.2 商品名不统一频繁项集被拆散现象明明经常一起卖的两个商品死活不出现在同一条规则里。原因同一商品存在多个写法比如带规格和不带规格、中英文混写。解决在预处理阶段做一次商品名映射表把同义名归并再跑算法。这一步花十分钟能省后面两小时排查。5.3 订单号重复或缺失篮子边界错乱现象规则结果里出现明显不合理的组合比如生鲜和五金强行关联。原因订单号有重复不同订单被合并成一个篮子或者订单号为空多单商品被塞进同一单。解决预处理时检查订单号唯一性去掉空订单号必要时用「订单号时间戳」做联合主键。5.4 提升度小于 1 的规则被当成宝贝现象置信度很高业务侧兴冲冲拿去推结果销量没变化。原因后件本身就是高频商品前件对它没有额外拉动作用。解决排序时先按提升度过滤只保留lift 1的规则再按支持度和置信度排序。提升度小于 1 的规则直接丢别舍不得。5.5 数据量太大内存直接爆掉现象跑 Apriori 时程序卡死或报内存错误。原因商品种类太多one-hot 矩阵维度爆炸。解决先做商品频次过滤砍掉长尾或者改用 FP-Growth 算法它在稠密数据上比 Apriori 快很多mlxtend里直接换成fpgrowth就行参数含义一致。6. 进阶技巧把关联规则和业务指标绑在一起看跑通 Apriori 只是第一步真正让结果值钱的是把规则和利润、复购率绑在一起。我一般会在规则表里加两列商品毛利率和组合历史销量然后算一个简单的「预期收益」——提升度乘以组合历史销量再乘以平均毛利率。这样排序出来的规则不再是纯统计意义上的强关联而是「改了之后真能多赚钱」的候选。另一个技巧是分时段跑把工作日和周末、白天和晚上的流水分开跑 Apriori经常能发现不同时段的最优组合完全不一样白天推咖啡面包晚上推啤酒零食比全量跑一版通用规则精准得多。验证方法也简单挑三条提升度最高的规则做两周小范围测试A/B 对比捆绑陈列前后的组合销量。如果提升度确实转化成销量增长再扩大范围如果没动静回头检查是不是支持度太低导致样本太小或者商品本身季节性太强。我自己的习惯是每次跑完 Apriori先不急着汇报把规则表丢进业务群让一线店员看一遍他们一眼就能指出哪些组合「确实经常一起买」哪些是数据巧合。算法给方向人给判断这个顺序别反。希望帮到你。本文还有配套的精品资源点击获取