啤酒与尿布背后的关联分析：真相与Apriori实战

讲一个我这些年反复咀嚼过的行业老梗吧。如果你在数据、BI、零售、电商任何一个领域待过两年以上“啤酒与尿布”这五个字基本不可能没听过。这是关联分析最著名的江湖传说沃尔玛发现每逢周五晚上啤酒和尿布这两类商品的销量会同时冲高进一步深挖后确认是年轻的爸爸们出门给孩子买尿布时会顺手犒劳自己一打啤酒。于是沃尔玛把啤酒和尿布在货架上放在一起啤酒销量直接飙升。这个故事被印在无数本数据挖掘教材里被写进无数份咨询报告的PPT里被无数个数据人当作“入坑初心”挂在嘴边。但你有没有想过一个问题这个故事是真的吗我认真查过、也栽过跟头。今天想把这件事从头到尾掰开聊一聊——故事最经典的版本长什么样它是怎么被讲出来的有没有实锤证据以及真正重要的这背后的关联分析到底是怎么运作的为什么能火这么多年。如果你只是想把它当成一个谈资那随便听听就行。但如果你想真正理解关联分析的价值和边界那这个故事的真伪考证恰好是最好的一把钥匙。1. “啤酒与尿布”的经典版本与它背后的核心逻辑1.1 流传最广的故事版本先说最标准的那个版本市面上讲关联分析的资料十有八九都是这个路子。上世纪90年代美国零售巨头沃尔玛Walmart对自己的海量交易数据做分析。数据仓库里有数亿条购物小票记录分析人员用数据挖掘工具扫描这些记录时发现了一个违反直觉的规律啤酒和尿布这两样八竿子打不着的商品经常出现在同一张小票上。进一步的挖掘显示这个关联现象在周五的傍晚最为明显。分析人员给出了一个非常“人性化”的解释家里有婴儿的年轻父亲在下班路上或周末傍晚被太太叮嘱“去买尿布”他们在超市里拿起尿布之后心理上会觉得自己“完成了一件带娃的大事”于是顺手拿上一打啤酒犒劳自己。这个解释太有画面感了一下子把冷冰冰的销售数据变成了一个生活场景。故事的后半段还有一个经典的操作细节沃尔玛决定把啤酒和尿布两个品类在货架上摆到一起。据说这个简单的调整之后啤酒销量出现了显著增长。有的版本说增长了20%有的版本说增长了30%甚至还有更夸张的说法。数字随着传播不断变化但“摆在一起就涨”的结论始终没变。这个故事之所以传得开是因为它完美地集齐了流行故事的三个要素大公司沃尔玛、反直觉的发现啤酒和尿布、简单有效的解决方案调整货架。它把一个复杂的分析模型变成了一句人人都能复述的话这让它成为数据挖掘课程里“购物篮分析”这个专题永恒的镇场之宝。1.2 故事的本质购物篮分析与关联规则把故事里的商业外壳剥掉里面真正的东西叫“购物篮分析”Market Basket Analysis。它的核心问题非常朴素顾客在结账时购物篮里同时出现了哪些商品这些商品之间的“同时出现”关系能不能用数据量化出来假设一家便利店一天有1000笔交易其中80笔同时包含了面包和牛奶。那么这个“同事现象”就可以被量化。关联分析要做的就是从海量交易记录里找出那些“一起出现”的频率显著高于随机水平的商品组合再把这种组合表示成一条规则。这条规则的标准写法是尿布 → 啤酒 意思是“买了尿布的顾客也倾向于买啤酒”。在这个箭头符号里“尿布”叫前项antecedent“啤酒”叫后项consequent。箭头不代表因果只代表“统计上的关联倾向”。“啤酒与尿布”这个故事之所以能成为经典是因为它把购物篮分析这个看似枯燥的概念变成了一个任何人一听就懂的场景。从这个角度看它作为教学案例的传播力是无可替代的。哪怕它是假的它也在过去的二十多年里确确实实地为数据挖掘行业输送了无数个“入坑”的人——包括我自己。我入行时听的第一个数据挖掘案例就是它。2. 追溯“啤酒与尿布”的来源从学术论文到商业传说2.1 学术源头1993年的那篇Apriori论文要考证“啤酒与尿布”的身世得先从关联分析这个领域本身的学术源头说起。关联分析这个研究方向公认的起点是1993年IBM阿尔马登研究中心的Rakesh Agrawal等人发表的论文《Mining association rules between sets of items in large databases》。这篇论文提出了“关联规则”的基本概念给出了支持度Support和置信度Confidence的正式定义并提出了后来被称为Apriori的经典算法。这篇论文研究的数据场景就是超市购物篮数据——记录每个顾客一次性购买的商品集合然后寻找商品组合之间的关联规则。这篇论文直接奠定了关联分析的理论基础。也就是说“从超市小票里找商品规律”这个思路确实是学界正经研究的问题而且就是在1990年代初期开始的。但在这篇论文里并没有提到“啤酒与尿布”这个具体案例。论文里用的示例数据都是抽象商品ID比如商品1、商品2而不是真实的啤酒和尿布。这说明“啤酒与尿布”并不是诞生在学术论文里。2.2 商业文献里的线索Osco Drug和Teradata目前能找到的、最早把“啤酒和尿布”放在一起说的商业文献多数考证指向1998年。那一年美国《Sales Marketing Management》杂志上刊登了一篇文章内容涉及连锁药店Osco Drug的一个数据分析案例。文章提到Osco Drug的分析人员发现在傍晚5点到7点这个时间段啤酒和婴儿尿布的销量呈现同时上升的走势。注意这个版本和经典版本有显著不同不是沃尔玛是Osco Drug不是周五晚上是每天傍晚5点到7点。这个时间点更符合“下班顺路购物”的场景。另外还有一个流传说法的源头指向Teradata。沃尔玛当时是Teradata数据仓库系统的大客户拥有规模惊人的交易数据库。Teradata在市场宣传材料里对沃尔玛的数据分析能力做了不少背书“啤酒与尿布”的故事也出现在某些Teradata相关的资料和演讲中。由于Teradata本身的权威性故事的主角被安在沃尔玛头上也就顺理成章。2.3 故事是如何“版本越传越统一”的真正让“啤酒与尿布”变成标准版本的是教材和课程的普及。1990年代末到2000年代初数据挖掘开始成为大学课程一批经典教材相继出版。《数据挖掘概念与技术》Jiawei Han和Micheline Kamber著等教材在介绍关联规则时把“啤酒与尿布”作为开篇案例写进了章节。到了这个阶段故事已经在多次转述中被加工成了一个“完美版本”从Osco Drug变成了更具代表性的沃尔玛从“傍晚5点到7点”变成了更有记忆点的“周五晚上”从“发现规律”延伸到“调整货架带来销量增长”。这就是典型的“都市传说”演化路径一个基于真实但很小的事件在口耳相传中被不断删减细节、补充细节最终形成一个比原始事件更工整、更符合大众预期的故事。每一个转述者都在无意识中朝“更合理”的方向修改故事——大公司比小药店更有说服力“周五晚上”比“每个傍晚”更有记忆点“摆一起就涨”比“发现了高度关联”更有行动指引性。所以考证这个故事的过程本质上是在和一个信息传播学现象打交道你追查得越深越发现源头不是一个点而是一团模糊的、交织的、不断变化的叙述。这一点恰恰也解释了为什么“啤酒与尿布”是真是假如此难定论。3. 真实性质证为什么说这个故事“查无实据”但“精神真实”3.1 沃尔玛官方从未证实我查过不少公开资料结论是沃尔玛官方从来没有正式承认过“啤酒与尿布”这个分析案例的真实性。沃尔玛的公开技术分享、案例研究、管理层访谈里谈得更多的是他们的数据仓库规模、供应链效率、动态定价系统但“啤酒与尿布”这个具体案例从未出现在官方的正式发布内容里。如果这是一个真实发生并取得显著商业效果的项目按理说会成为零售数据化转型的标志性案例被反复引用。但它没有。多位数据挖掘领域的学者和从业者也做过考证。比较一致的结论是没有找到任何沃尔玛内部的原始分析报告、项目文档或知情人的一手访谈能够直接证明这个案例的真实性。比较公允的判断是这个故事更可能是数据挖掘早期阶段厂商或咨询顾问为了向客户解释“关联分析到底能干什么”而创作的一个示例化教学案例。它讲了一个好故事但并不一定是一次真实复盘的商业案例。3.2 故事的内核在现实中确实存在虽然“沃尔玛官方证实”这个环节缺失但也不能就此断言故事纯属虚构。因为故事描述的现象在零售业的真实数据里是完全可能出现的。我自己做过零售数据项目可以负责任地说跨品类的“反直觉关联”是真实存在的。在母婴用品门店的销售数据里婴儿纸尿裤的购买者确实会同时购买成人啤酒、碳酸饮料等“犒劳型”消费品在超市的周末数据里烧烤食材和啤酒、一次性餐具经常强关联在中式餐饮店某种主菜锁定某几种酒水……这类现象的共同逻辑是购买行为背后的“角色场景”决定了购物篮内容的组合方式。“啤酒与尿布”故事里的核心链条——年轻父亲承担育儿采购任务时会存在“补偿性消费”行为——在消费行为学上是站得住脚的。所以哪怕这件事没有真实发生在沃尔玛它也真实发生在某些零售企业的数据里只是没有被打造成教科书级案例而已。3.3 看待这个故事的正确姿势综合各方面信息我自己对“啤酒与尿布”真实性的判断可以分三层。第一层作为“新闻报道”它是不严谨的目前没有实锤证据支持“沃尔玛做过这个分析并取得XX增长”的说法。第二层作为“教学案例”它是极为成功的用一种几乎无法被超越的简练方式让一个零基础的人也能秒懂关联分析的核心思想。第三层作为“行业现象”它是真实存在的——购物篮里确实能挖掘出反直觉的、有价值的商品关联这一点已经被无数商业实践验证过了。所以我的建议是不用纠结于它真不真但一定要搞清楚它为什么能成为经典。它背后的关联分析逻辑才是真正值得花时间弄明白的东西。4. 关联分析的三大核心指标支持度、置信度、提升度讲清楚来龙去脉接下来要正式进入技术环节。关联分析这套体系如果你只记三个词那就是支持度、置信度、提升度。我们用一个具体的场景来算一遍。假设一家便利店记录了5笔交易分别是交易编号购物篮内容T1啤酒、尿布、薯片T2啤酒、面包、尿布T3牛奶、尿布、面包T4啤酒、尿布、牛奶T5啤酒、可乐、尿布现在我们要挖掘的规则是尿布 → 啤酒也就是“买尿布的顾客倾向于买啤酒”。首先看支持度Support。它衡量的是“尿布和啤酒同时出现”在所有交易中的占比。5笔交易里同时包含尿布和啤酒的交易是T1、T2、T4、T5一共4笔所以支持度 4/5 80%。支持度解决的是“这个规则覆盖面广不广”的问题。如果支持度太低比如只有0.1%说明这个规则只适用于极少数交易商业价值有限。其次看置信度Confidence。它衡量的是在所有包含尿布的交易里有多少比例同时包含啤酒。5笔交易里包含尿布的有T1、T2、T3、T4、T5一共5笔这5笔里同时包含啤酒的有T1、T2、T4、T5一共4笔。所以置信度 4/5 80%。置信度解决的是“规则可靠性高不高”的问题相当于条件概率P(啤酒|尿布)。最后看提升度Lift。这个指标最容易被人忽略但它恰恰是判断“关联是否真实”的关键。先计算啤酒在所有交易中的占比5笔里有4笔包含啤酒T1、T2、T4、T5所以P(啤酒) 80%。如果“买尿布”和“买啤酒”是两件独立的事那么买尿布的人里买啤酒的比例也应该大致等于80%。但实际置信度也是80%和基准水平一样说明这个关联并没有比随机水平更好——提升度 置信度 / P(啤酒) 80% / 80% 1。这里就引出了提升度的判读规则提升度 1正相关前项出现会提升后项出现的概率有商业挖掘价值。提升度 1相互独立没有关联价值。提升度 1负相关前项出现反而会抑制后项出现。回到“啤酒与尿布”的故事为什么它值得被当成商业案例讲因为正常来说啤酒在所有交易里的占比不会太高可能只有10%左右。但如果买尿布的人里有30%买了啤酒置信度30%提升度就是3。说明在你拿起尿布的那一刻你买啤酒的概率是普通顾客的三倍。这种“显著高于随机水平”的关联才是值得商业上做出反应的信号。明白了这三个指标就能看懂整个关联分析是怎么回事先设定最低支持度过滤掉低频组合再设定最低置信度筛选出足够可靠的规则最后用提升度确认这种关联是否真的高于随机水平。5. Apriori算法与“啤酒尿布”式发现的操作内幕5.1 Apriori算法的核心机制知道了三个指标还不够。真正做分析时面对的是成千上万的商品、几百万笔交易如果穷举所有商品组合计算量会爆炸。比如1000种商品所有两两组合就有近50万种三三组合超过1.6亿种根本算不完。Apriori算法的聪明之处在于它利用了一个简单却极其有力的性质叫做“先验原理”如果一个项集是频繁的那么它的所有子集都是频繁的。反过来如果一个项集不是频繁的那么它的所有超集任何包含它的更大组合也一定不是频繁的。这个性质的推理逻辑很直白假设“尿布”单独出现的支持度只有2%没有达到5%的最低支持度阈值。那么任何包含尿布的组合比如“尿布啤酒”“尿布薯片”出现频率必然不会高于2%因为“尿布啤酒”出现的次数不可能超过“尿布”本身出现的次数。既然连尿布单独出现都不达标那所有包含尿布的组合也一定不达标可以整个剪掉不用计算。Apriori算法的标准流程分三步扫描所有交易记录统计每个单一商品的支持度滤掉支持度低于阈值的商品得到频繁1项集。在频繁1项集的基础上组合出频繁2项集再次扫描统计支持度、过滤然后组合出频繁3项集循环往复直到不能生成新的频繁项集为止。在全部频繁项集上生成候选规则用置信度和提升度筛出有效强规则。这里就有一个实操心得为什么教材里都用Apriori来教但生产环境里很多团队改用FP-Growth算法因为Apriori每发掘一轮频繁项集就要全表扫描一次交易数据数据量一大I/O开销非常可观。FP-Growth则在第一轮扫描时把数据压缩成一棵FP树后续挖掘都在这棵树上完成速度会快很多内存占用也更可控。实际业务里如果数据量超过百万级交易建议直接上FP-Growth别在Apriori上死磕。5.2 一个完整计算示例拿刚才那5笔交易继续往下推。设最小支持度为60%最小置信度为80%。第一步统计所有单品的支持度啤酒4/5 80%尿布5/5 100%薯片1/5 20%面包2/5 40%牛奶2/5 40%可乐1/5 20%支持度达到60%的单品只有啤酒和尿布所以频繁1项集就是{啤酒}和{尿布}。第二步组合生成频繁2项集。啤酒和尿布的组合“啤酒尿布”支持度刚才算过是4/5 80%达标。所以这个组合进入候选规则生成阶段。第三步生成规则并计算置信度和提升度。规则1尿布 → 啤酒。置信度 支持度(尿布∪啤酒) / 支持度(尿布) 80% / 100% 80%刚好达标。提升度 80% / 80% 1说明没有提升。规则2啤酒 → 尿布。置信度 80% / 80% 100%也达标。提升度 100% / 100% 1同样是独立关系。这两个规则虽然置信度很高但提升度都是1并没有比随机水平更好。这个例子恰好说明了一个关键问题置信度高不代表关联有效。如果只盯着置信度看很容易把日常高频商品之间的“假关联”当成宝贝。5.3 参数怎么定才靠谱实际跑关联分析最头疼的问题是支持度和置信度的阈值怎么设。我的经验是最小支持度不是拍脑袋定的要先看数据分布。先跑一个单品支持度排行看看绝大多数商品的单品支持度是多少。如果80%的商品单品支持度都在1%以下那把最小支持度设成5%就意味着一开始就放弃了大部分商品最后只能挖出矿泉水、可乐这类人人都买的“大众单品”之间的关联毫无业务启发。反过来如果最小支持度设成0.1%会挖出几千条规则大部分都是噪声。一个相对稳的起点是最小支持度设为单品支持度分布的中位数或略低最小置信度设为60%-70%首先用提升度排序重点看提升度大于2的规则。然后针对筛选出来的规则回到原始交易里人工抽样验证确认这个关联在业务逻辑上说得通。这个方法不适合做自动化生产但用来做前期探索性分析非常高效。6. 关联分析的常见误用与真金白银的避坑心得6.1 三大经典误用场景关联分析看着简单实际应用中翻车的概率极高。很多团队兴致勃勃跑完一次购物篮分析得到了几百条规则结果一落地就发现没用问题基本出在以下三个方面。第一个坑是把“相关”当作“因果”来解读。关联分析只能告诉你“尿布和啤酒一起出现的频率高于随机”它不能告诉你“尿布导致啤酒销售增长”或“啤酒导致尿布销售增长”。真实的原因是第三变量——年轻父亲这一角色场景——同时驱动了两者的购买。如果在解读时忽略隐藏变量很容易把一种统计关联当成可操作的业务因果从这个错误认知出发做出的决策大概率会打偏。第二个坑是忽略时间窗口和外部节律的影响。很多商品存在明显的季节性啤酒在夏季和世界杯期间销量暴涨尿布是全年稳定的刚需品。如果在年度数据里挖“啤酒尿布”的关联很可能这个“关联”主要是夏季几个月贡献的。在一年的其他时间段这个关联根本不存在。做关联分析一定要把时间维度拆开看至少按季度或按“节假日/工作日”来拆分别建模否则挖出来的规则可能是季节叠加的幻觉。第三个坑是商品粒度与业务粒度不匹配。在分析之前要想清楚“啤酒”指的是一个单品还是整个啤酒品类“尿布”指的是一个SKU还是整个尿布区如果颗粒度不一致有些关联是品类的有些关联是品牌的混在一起挖掘规则会很难落地。通常是先做品类级分析找到方向再做SKU级别分析确定执行细节。6.2 三个你在教材里学不到的实操心得第一个心得频繁项集≠重要规则。支持度高的组合像“面包牛奶”几乎是每个家庭早餐的标配挖出来毫无惊喜。真正有商业价值的往往是支持度不高、但提升度很高的长尾组合这时候要敢把支持度阈值调低用提升度来把关。这个操作有点反直觉因为教材上默认以支持度优先但业务上真正能带来增量的往往是那些“少数人强烈关联”的商业场景。第二个心得关联规则一定要做样本外的稳定性验证。用前三个月的数据挖出的强规则拿到后三个月的数据上看置信度的衰减程度。如果衰减非常大说明这条规则只是偶然波动不能用。我在实际项目里至少有一半的规则过不了这道关卡。所以给业务方展示规则时我会同时给出训练期和验证期的指标让业务方自己判断规则的可靠性这个做法在推进落地时阻力小得多。第三个心得强关联规则落到业务动作上不一定非得是“摆在一起”。把啤酒和尿布放一起只是众多选择之一。更精细的玩法是在尿布区张贴啤酒优惠券、在啤酒货架做“奶爸专区”的主题陈列、在会员小程序给近期购买过尿布的用户推送啤酒券。这叫做“不做货架物理调整也能完成跨品类联动”。物理调整往往是最贵的、最不可逆的方案数字化的关联推荐反而更便宜、更好做AB测试。7. 在自己的数据上复现一次“啤酒与尿布”式分析如果想上手试一次我建议别在理论里兜圈子直接拿自己手头的数据跑一遍。最顺手的路径是用Python的mlxtend库代码量非常小。准备的数据结构就是三列交易ID、商品名称、数量。如果只有订单表和商品明细表先做一个去重把同一个订单里的重复商品合并成一行。然后做两步预处理把数据透视成“交易ID × 商品”的布尔矩阵某笔交易包含某商品记1不包含记0。用TransactionEncoder把原始数据转成Apriori可用的格式。核心代码就是三段。第一段选品过滤掉出现频次过低的商品比如只保留出现在至少1%的交易里的商品。第二段用apriori扫描出所有满足最小支持度的频繁项集。第三段用association_rules生成规则并指定metriclift按提升度排序查看输出结果。这里要提醒一个新手的坑生成关联规则的时候mlxtend默认输出的规则数是相当惊人的如果不设min_threshold直接跑报表会直接卡死。最好先按提升度大于1.5或2这个条件筛再按置信度70%以上筛能把几百条规则压缩到二十来条可人工审阅的范围内。至于业务上怎么落地我再补一个思路。关联分析建出来的模型比你想象中更适合“推荐系统冷启动”环节。一个没有历史行为的新用户刚登录你的APP时系统不知道给他推荐什么。但只要你识别出他刚下单了纸尿裤就能依照关联规则立刻推啤酒、推湿巾、推奶粉——这种“基于购物篮的即时推荐”往往比基于用户历史的协同过滤在冷启动阶段表现更好。我自己做项目时这个场景的落地效果远比“改货架”直观得多。另外如果你想做更贴近“啤酒与尿布”经典故事的复现可以选择一个特定的气候窗口来跑数据。我做过的一个案例是把烧烤季春夏之交和非烧烤季的数据拆开分别建购物篮模型结果发现“羊肉串料一次性烤架冰啤酒”这个组合只有在烧烤季才会出现高提升度关联。这种数据驱动下发现的“当季组合”比凭经验拍脑袋做的季节陈列准确得多。这个操作本质上就是把“周五晚上”那个故事的思路用现代数据工具还原了一遍——与其去考证沃尔玛是否真的发现了尿布配啤酒不如在自己手头的数据里寻找属于你的那个“周五晚上”。先说这么多直接拿数据跑一遍比读十篇文章都管用。