接手过一个零售连锁的数据分析需求对方运营负责人拉出来几千张小票开门见山问我哪些商品放在一起会互相带动这问题背后就是关联分析。想把关联分析做扎实绕不开三个指标支持度、置信度、提升度。说句实在话网上聊关联规则的文章十个有八个拿啤酒与尿布当开场段子是好记可真到项目里你会发现故事只能帮你理解大概是怎么回事完全没法指导你定阈值、筛规则、给业务解释结论。这篇文章就围绕这三个指标把关联规则从公式含义、手算过程、踩坑经验到落地姿势完整讲一遍适合刚接触数据挖掘、或者已经在做购物篮分析但总觉得指标算出来了却不会用的读者。1. 一张小票藏着的购物篮关联分析到底在回答什么问题1.1 把一起买翻译成数学规则先说清楚关联分析在整个数据分析体系里的位置。它不是预测模型不回答下个月销量多少这个顾客会不会流失这类问题它回答的是什么东西经常一起出现。这个经常一起出现的模式在零售场景里就是购物篮一张小票对应的是一次购买行为小票里所有商品的集合就是一个事务全部小票汇总起来就构成了一个事务数据库。关联分析要做的就是在这个事务数据库里找出高频共现的商品组合并用规则的形式表达出来。一条关联规则长这样A → B读作买了A的人也倾向于买B。比如咖啡 → 鲜奶意思是买咖啡的顾客里有相当比例的人同时买了鲜奶。注意这里箭头不代表因果只代表共现层面的前后关联。这个区分很重要后面讲提升度的时候你还会感受到它的分量。为了能严谨地讨论这个问题需要先统一几个术语。项集就是商品的集合{咖啡, 鲜奶}是一个2-项集事务就是单张小票里的商品集合事务数据库就是全体小票。一条规则 A → B 里A 叫前件B 叫后件。接下来所有计算都是在这几个概念上展开的。1.2 三个指标的分工逻辑先圈范围、再看强度、最后定方向假设你在海量的商品组合里找值得看的规则。直接看结论会让你眼花缭乱因为咖啡和鲜奶一起出现和咖啡和保险单一起出现完全是两码事前者一年发生几千次后者可能只是某个大客户的一次巧合。所以需要一道一道过滤。支持度负责第一道过滤它衡量一个组合在全部事务里占多大比例。比例太低说明这个组合只是零星巧合不值得投入分析资源。置信度负责第二道过滤它衡量当前件出现时后件跟着出现的概率。这个概率高说明规则靠得住。但光靠这两道还不够——一种商品本身就可能是个高频商品买什么都可能带上它这时候置信度高是沾光不是规则本身有价值。这就需要提升度出场它把后件的全局购买率作为基准看当前件出现时后件的概率是明显高于、持平还是低于这个基准从而判断这条规则是正向拉动、无关还是反向抑制。打个比方三个指标就像筛选合作伙伴支持度看候选人池子够不够大置信度看合作后的成功率提升度看跟你合作是不是真的比跟别人合作强。只看前两个可能选中一个本来就自带流量的人提升度才是判断你对他有增量贡献的关键。2. 三个指标逐个拆解公式、含义与常见误区2.1 支持度这个组合到底多常见支持度的定义式support(A → B) 同时包含A和B的事务数 / 事务总数 count({A, B}) / N用一个具体的场景说话。假设一家店有1000笔小票其中180笔同时包含咖啡和鲜奶那么规则咖啡 → 鲜奶的支持度就是180/100018%。直观理解每100笔交易里有18笔会出现这两个商品同时结账的情况。这里有个符号上的坑要先拆掉。公式里那个 count({A, B}) 或者写成 count(A∪B)指的是同时包含A和B的小票数。不少资料为了书写方便会写成 A∪B但它跟集合论里的并集不是一回事。你只要记住它是把一个项集 {A, B} 当作整体去事务里匹配就行用概率论的语言说它对应的是 P(A∩B)。符号上容易绕实际含义很朴素数一数哪些小票里两样东西都出现了。支持度的作用在于过滤。最小支持度是挖掘时第一个参数低于它的组合直接淘汰。为什么因为支持度太低意味着支撑规则的样本太少哪怕置信度算出99%也可能只是三张小票里的巧合经不起波动。2.2 置信度前件出现时后件有多大概率跟着出现置信度的定义是条件概率confidence(A → B) count({A, B}) / count(A) P(B | A)还是用上面的数据买咖啡的小票有400笔其中180笔同时买了鲜奶那么咖啡 → 鲜奶的置信度是180/40045%。换句话说买了咖啡的顾客里接近一半的人也会买鲜奶。这个数字直接回答了业务上最关心的一个问题如果我想给买咖啡的人推荐鲜奶成功率大概多少。注意置信度的不对称性。反过来看鲜奶 → 咖啡买鲜奶的小票有300笔其中180笔同时买了咖啡置信度是60%。也就是说从鲜奶导流到咖啡的成功率反而更高。同一个共现事实换个方向置信度就变了。这在推荐动作设计里非常关键你应该把顾客从置信度更高的前件往后件方向引导。后面3.3会专门演示这个方向差异。但置信度有个结构性的盲区它没有参照后件的自然发生率。假设店里60%的小票都有面包那么随便找一条规则什么X → 面包置信度都可能接近60%。看起来买了X的人也买面包很稳可这跟X根本没关系顾客本来就大概率会买面包。要识别这种沾光规则必须引入提升度。2.3 提升度判断正向拉动、彼此独立还是反向抑制提升度的公式有两种等价写法lift(A → B) confidence(A → B) / support(B)lift(A → B) count({A, B}) × N / (count(A) × count(B))第一种写法最好记也最能体现三个指标的关系提升度就是置信度除以后件在整个数据库里的支持度。它本质上是把买A的前提下买B的概率和不讲究前提时买B的概率做比较。还是用数据说话。咖啡 → 鲜奶置信度45%鲜奶的整体支持度是300/100030%提升度45%/30%1.5。意思是买了咖啡的人购买鲜奶的概率是全体顾客平均水平的1.5倍相当于多出了50%的购买概率。这是明确的正向拉动。提升度的判读规则lift 1前件出现时后件概率高于全局水平正向拉动lift ≈ 1前件对后件没影响两者独立规则没有增量价值lift 1前件出现时后件概率反而低于全局水平反向抑制提升度还有一个容易被忽略的性质——它是对称的。lift(A→B) 和 lift(B→A) 永远相等因为公式分母是 count(A)×count(B)分子是 count({A,B})×NA和B对调后数值不变。这与置信度的不对称形成鲜明对比。很多刚入门的同学会疑惑为什么同一个提升度不同方向都能用其实就是这两个性质叠加的结果。2.4 一张表把三个指标的关系钉死指标公式取值范围回答的问题最小阈值一般怎么设支持度count({A,B})/N0~1这个组合常见吗1%~10%看商品总数和数据量置信度count({A,B})/count(A)0~1前提出现时结论有多稳20%~60%提升度confidence/support(B)0到∞1为基准是拉动、独立还是拖累1实践中常取1.1~1.5表格最后一行是重点三个指标不是并列关系而是递进关系。支持度筛掉太罕见的组合置信度筛掉不稳定的规则提升度筛掉没增量的伪规则。任何一个环节不过关规则都算不上好用。3. 手工演算一组交易数据把三个指标算到能背下来3.1 示例数据把1000笔交易压缩成几张计数表为了让你能跟着算一遍我构造一份模拟的便利店交易数据总共1000张小票先从单品的购买频次看起。商品购买次数购买率咖啡40040%鲜奶30030%面包60060%薯片25025%这张表告诉你四件商品的基本盘。面包是店里最热门的商品60%的小票都会出现薯片和鲜奶是中等偏下的频率咖啡的购买率是40%其实也不算低。接下来看两两同时出现的频次。注意咖啡鲜奶的180笔是已经包含在咖啡400笔和鲜奶300笔之内的千万不要把单品的计数加起来再用。商品组合同购次数咖啡鲜奶180咖啡面包240咖啡薯片120鲜奶面包150鲜奶薯片40面包薯片150为什么不直接甩出1000行原始小票因为关联规则的核心计算依赖的是这些聚合计数。只要事务数据库够大你完全可以先通过数据库查询或者清洗脚本统计出单品频次和组合频次再在这个基础上计算所有指标。这也是后面第5节代码实现的基本思路。3.2 三个典型规则的手算全过程先算第一条咖啡 → 鲜奶支持度 180 / 1000 18%置信度 180 / 400 45%提升度 45% / 30% 1.5这条规则三个指标全部过关18%的支持度说明组合不算罕见45%的置信度说明导流成功率接近一半提升度1.5说明咖啡对鲜奶有明确的正向拉动。如果做交叉销售买咖啡时推荐鲜奶会是第一批上线的高潜规则。再看第二条咖啡 → 面包支持度 240 / 1000 24%置信度 240 / 400 60%提升度 60% / 60% 1.0这条最容易让人误判。置信度60%比咖啡 → 鲜奶还高猛一看是好规则。但面包本身的购买率就是60%买不买咖啡买面包的概率都是60%。提升度1.0说明咖啡和面包只是在同一家店共存的独立高频商品互相没有增量。如果把这条规则交给运营让他们给买咖啡的人推荐面包效果约等于随机推荐——因为面包本来就会出现在六成小票里。再看第三条鲜奶 → 薯片支持度 40 / 1000 4%置信度 40 / 300 ≈ 13.3%提升度 13.3% / 25% ≈ 0.53这条是反向抑制的典型。买鲜奶的顾客里只有13.3%会买薯片而整体顾客里有25%会买薯片。提升度0.53说明鲜奶顾客买薯片的倾向被明显压低。这个信息对货架设计很有用鲜奶和薯片不适合放在一起做凑单推荐它们更像是替代型或场景冲突型商品。3.3 箭头方向不是摆设置信度不对称提升度对称把咖啡 → 鲜奶翻个方向算鲜奶 → 咖啡支持度 180 / 1000 18%不变置信度 180 / 300 60%提升度 60% / 40% 1.5和刚才完全一样看到差异了支持度不变好理解因为同时包含咖啡和鲜奶的小票数量没变提升度不变是因为提升度本质是度量两个商品的关联强度和谁当前件无关但置信度从45%变成了60%原因只是把分母从买咖啡的人数换成了买鲜奶的人数。这个性质在落地时特别有用。如果你要给某个场景设计推荐链路比如收银台扫码后推荐你肯定希望从置信度更高的方向去引导。数据里鲜奶 → 咖啡的置信度60%高于咖啡 → 鲜奶的45%那就优先考虑买鲜奶后给咖啡券而不是反过来。而判断两个商品到底有没有关联、关联强度多大就直接看提升度不用分方向。4. 阈值设定最容易踩的坑指标够高结论却可能完全相反4.1 最小支持度一刀切低频高价值组合被误杀很多人做关联分析第一件事就是设一个全局最小支持度比如5%。这在小而全的超市或许行得通但放到SKU过万的大型零售里问题立刻就来了绝大多数商品的支持度都不到1%你设5%等于直接把大部分商品都排除在外最后挖出来的规则永远集中在少数爆款之间。更要命的是低频商品里往往藏着高毛利、高客单的利润型商品。举个例子高端咖啡机一个月只出现在2%的小票里但它和精选咖啡豆的共现可能非常稳定置信度70%提升度3.0。如果按5%的最小支持度一刀切这条高价值规则根本进不了候选集。我现在的习惯做法是分层级、分类目地设阈值先把商品按类目拆开比如咖啡设备零食日用品在各个类目内部计算支持度分布再按各自的分位数设最低支持度。另一种更省事的方案是多最小支持度——给高利润商品单独一个更低的支持度门槛。总之支持度是过滤工具不是道德标准低频不等于没价值。4.2 高置信度低提升度最典型的伪强规则前面说的咖啡 → 面包就是这类坑的活教材。置信度60%看起来很强但提升度只有1.0说明没有增量。类似的情况在热门商品上特别普遍店里最畅销的十款商品天然会出现在大量规则的后件里把任何前件搭配上去置信度都不会太低。这个坑为什么常见因为很多分析工具默认只展示支持度和置信度报表里排在前面的规则往往就是这种伪强规则。业务方不懂提升度的话会误以为热门商品规则都是宝贝。要避开它规则很简单设最小提升度而且不要只设1.0。建议设1.1甚至1.5具体看数据噪声水平。更严格一点的做法是要求置信度必须明显高于后件的自然支持度也就是 confidence(A→B) / support(B) ≥ 1.1这个条件等价于 lift ≥ 1.1。这比单独看置信度放在报表里直观得多。4.3 提升度远小于1的负相关规则可能是金矿大家习惯性地认为只有提升度大于1的规则才有价值其实小于1的反向规则在不少场景里同样重要甚至更稀缺。还是用鲜奶 → 薯片举例。提升度0.53意味着鲜奶顾客里买薯片的人只有随机顾客的一半。如果你在做促销套餐设计这个信息能帮你避开雷区——别再给鲜奶薯片做捆绑折扣了优惠只会被用来买本来就是刚需的鲜奶。如果你在做替代品分析负相关则直接指向这两种商品服务的场景互斥可以顺势去排查是不是鲜奶偏好人群更注重健康从而主动避开膨化食品判断负相关规则是否值得看不能只看是不是小于1。样本量小的时候提升度0.9、0.8基本都是噪声。我更关注的阈值是0.7以下而且要结合支持度如果支持度只有0.5%那就算提升度0.4也没意义样本太少经不起复购验证。低支持度的方向性结论是统计上最站不住脚的一类。4.4 样本量不够时三个指标都会失真最后补一个很多人忽视的前提三个指标都是基于历史事务的统计量样本量直接决定它们的可信度。举个例子某小店月销售只有500张小票其中养生壶 → 花茶出现了40次支持度8%置信度50%提升度2.0看起来很漂亮。但如果这40笔里有20笔来自同一个企业客户的单次团购这条规则就完全是虚假繁荣。零售分析里的大单、团购、补货单都会污染计数第一道预处理一定是把异常大单单独拎出来或剔除分析正常零售小票。另外1000笔和100万笔数据量下支持度1%的含义完全不同。1000笔里支持度1%只是10笔100万笔里是10000笔后者做出来的规则稳定得多。所以小样本场景建议把最小支持度适当调高或者干脆不设固定值而是约定组合至少要出现50次以上这种绝对频次门槛保证每条规则背后都有足够多真实顾客行为支撑。5. 从三个指标到完整挖掘流程频繁项集、剪枝与代码落地5.1 为什么不能把商品组合全都枚举一遍如果只有4个商品两两组合只有6个手算就行。但现实里一家超市几千个SKU三三组合、四四组合的数量会爆炸。直接枚举所有规则再计算指标计算量是不可接受的。这里有一个重要的剪枝性质叫向下闭包性如果一个项集不频繁支持度低于最小支持度那么包含它的所有超集也一定不频繁。原因很简单{咖啡, 鲜奶, 面包} 同时出现的小票数量不可能超过 {咖啡, 鲜奶} 的小票数量所以超集的支持度只可能更低。基于这个性质标准的挖掘流程分两步找频繁项集从1-项集开始保留支持度达标的再用频繁k-项集拼接候选(k1)-项集逐层扩展直到找不到新的频繁项集为止。生成规则对每个频繁项集枚举所有前件后件的切分计算置信度和提升度留下过滤后仍达标的规则。第一个阶段的过滤依据是支持度第二个阶段的过滤依据是置信度和提升度。三个指标正好各管一段这也解释了为什么它们是关联分析的三大核心概念。5.2 用Python手写一个三指标筛选流程这里给一个极简的实现思路不依赖重量级框架核心就是前面两张计数表。实际项目里这些计数可以从数据库里按条件聚合出来思路完全一致。N 1000 item_counts {咖啡: 400, 鲜奶: 300, 面包: 600, 薯片: 250} pair_counts { (咖啡, 鲜奶): 180, (咖啡, 面包): 240, (咖啡, 薯片): 120, (鲜奶, 面包): 150, (鲜奶, 薯片): 40, (面包, 薯片): 150, } min_support 0.10 min_confidence 0.40 min_lift 1.05 for (a, b), cnt_ab in pair_counts.items(): sup_ab cnt_ab / N if sup_ab min_support: continue conf_ab cnt_ab / item_counts[a] if conf_ab min_confidence: continue lift_ab conf_ab / (item_counts[b] / N) if lift_ab min_lift: continue print(f规则 {a} - {b}: 支持度{sup_ab:.1%}, 置信度{conf_ab:.1%}, 提升度{lift_ab:.2f})按代码里的阈值跑一遍你会发现只有咖啡 → 鲜奶通过支持度18%达标置信度45%达标提升度1.5达标。咖啡 → 面包和面包 → 薯片死在提升度小于1.05咖啡 → 薯片死在置信度30%低于40%鲜奶 → 薯片死在支持度4%低于10%。这个结果很能说明问题三个阈值同时过滤会把候选规则压到一个很小的范围留下来的才是真正值得业务投入验证的。如果你要扩展到三商品、四商品的规则只需要把 pair_counts 换成更大项集的计数表再对每个频繁项集枚举所有前后件切分。数学原理没有任何变化变化的是候选集膨胀的速度这时候才需要认真用向下闭包性做剪枝或者直接用现成的频繁项集算法。5.3 三个指标在业务场景里的落地姿势指标算出来之后不同业务动作对指标的偏好不一样我说三个最常见的。交叉销售。做买了A之后推荐B的场景首先要求规则满足最小支持度保证样本量和较高置信度保证推荐成功率用提升度排序决定优先级。给业务解释的时候就把提升度翻成人话与咖啡同购概率提升50%。捆绑套餐。设计AB组合优惠时更看重支持度和提升度的乘积。高支持度意味着目标人群大高提升度意味着两者确实存在协同套餐才能带动原本不会买B的人下单。如果只是两个本来就都卖得好的商品拼在一起那只是让利不是捆绑。货架与陈列。高提升度的商品尽量近场陈列比如咖啡和鲜奶放在一条动线上低提升度甚至负相关的商品保持距离避免一个商品的促销流量被另一个商品抢走。这类调整通常先在小范围试点再看销量变化是否与提升度方向一致。最后再强调一遍提升度只证明统计共现不证明因果。咖啡和鲜奶如果都在早餐时段被购买真正的驱动因素是早餐场景把它们放在一起也许能提高顺带购买率但这不代表咖啡导致了鲜奶的购买。验证因果只能靠线下实验选几家店调整陈列拉同期对照组用销量差说话。6. 项目里真正决定成败的是阈值调法和规则筛选口径6.1 阈值是试出来的不是拍出来的很多教程会给你一个默认配置比如支持度0.5%、置信度50%、提升度1。这只适合练手不适合真实数据。我的做法分三步走。先理解数据形状。跑一下所有商品的单品支持度分布看看中位数在哪里、长尾有多长。如果90%的商品支持度都低于1%你就知道最低支持度绝对不能按感觉随便定个5%。再定规则数量目标。跟业务方确认他们希望最终看多少条规则——一般50到200条是运营消化的极限。然后反向调参先把支持度定到某个值统计生成的频繁项集数量再调置信度和提升度控制规则总量。最后小步验证。任何阈值组合产生的规则先挑排名前20的给业务看问一句这些规则里有没有明显不符合常识的。如果多数规则业务一眼就能解释通说明阈值方向对了如果频繁出现咖啡 → 卫生纸这种莫名组合大概率是阈值太低或者数据里有异常单。6.2 规则数量爆炸时的收敛策略真实数据里随便跑一下就可能生成几十万条规则。绝大多数规则没有业务价值如何收口有几个实用手段。限制规则的形态。比如只保留单前件规则或者前件最多两个商品这会大幅压缩规则空间。对零售来说两件商品的关联已经覆盖了绝大多数可执行的销售动作三件以上的规则很难变成一句话的营销话术。去掉冗余规则。如果 A → B 和 A, C → B 同时具有相近的置信度和提升度保留更短的那条。判断标准可以约定为加入C之后置信度没有显著提升比如提升不超过5个百分点就认为C没有贡献。否则规则列表会被同一组事实的各种花式切分刷屏。按业务权重排序。光按提升度排序也有问题提升度容易被低频商品带飞。我常用一个综合口径先按提升度降序取Top然后看支持度是否达到业务最低销量要求最后人工复核前50条。如果想让排序更稳健可以把置信度也纳入比如按提升度乘以置信度排序兼顾强度和可靠性。再进阶一点还可以用杠杆率、确信度这类衍生指标做二次排序它们本质上都是对三个核心指标的组合应用。6.3 我的一点项目经验和习惯最后聊几个我在项目里反复遇到、但文档里很少写的点。第一一定先清洗异常大单。一键过滤单笔超过50件商品的订单能替你挡掉一大半虚假规则。之前在某零售项目里一条香薰机 → 精油的规则支持度异常高排查后发现是公司采购团购刷出来的真实散客根本没这个习惯。第二关联关系会随时间漂移。节假日、季节、促销周期都会改变共现结构。今天挖出来的规则下个月可能完全失效。所以关联分析最好是周期性重跑而不是做一次就存档。第三规则要跟着业务口径走。同样是咖啡 → 鲜奶在新品上市会员日晚市打折这几个场景下的表现可能完全不同。更合理的做法是按场景切片数据分别跑规则而不是把一年的事务混在一起出一个大锅饭结果。第四落到动作之前先做小范围验证。挖规则只完成了分析的一半另一半是设计实验选8到10家门店一半调整陈列或推荐一半维持原样跑两到四周看增量。数据上说提升度高的规则只有经过这一关才真正有资格进入运营手册。结构和指标其实都不难难的是把这三件套用进真实业务时的那份谨慎。我自己这几年最大的感受是支持度、置信度、提升度帮你把几百万条候选压到几十条但真正决定规则价值的是清洗数据的那点耐心、验证实验的那点投入还有把规则讲给业务听时的那点人话。希望这篇能让你少走我走过的弯路。