用Apriori做面包店购物篮分析：从数据清洗到业务落地

1. 为什么拿面包店做关联分析关联分析这个技术搞数据的人多少都听过经典的“啤酒与尿布”被讲烂了但真正自己动手跑一遍完整流程的机会并不多。前阵子我拿到了一份真实的面包店交易数据——BreadBasket数据集顺手做了一轮完整的购物篮分析从数据清洗、算法选型到规则解读走了一遍收获不少踩坑也不少。这篇文章就是把整个过程整理出来给想练手关联分析的朋友一份可以跟着跑的实战参考。先简单交代一句这数据集是干嘛的。BreadBasket是UCI公开的一个面包店交易数据集里面存着某家面包店一段时间的每笔订单明细。说白了就是一张购物小票流水表每行是一条购买记录有交易编号、商品名称、日期时间、时段和是否周末这些字段。原始数据量不算大两万多条记录十几个商品品类但做关联分析练手非常合适——数据真实、脏数据明显、业务含义直观比那种干净的示例数据有挑战多了。这篇文章适合谁看呢。如果你是刚接触关联分析、想把Apriori算法真正落到代码上跑一遍的人或者是你已经会用算法但没想清楚“支持度、置信度、提升度算完之后到底怎么指导业务”的人这篇都能给你一点实际的东西。我会把每一步的逻辑讲清楚包括数据清洗为什么必须做、参数为什么这么调、结果怎么解读而不是只丢一段能跑的代码。2. 数据长什么样先摸清楚再动手做数据分析的第一步永远不是建模是看数据。拿到BreadBasket之后先别急着跑关联规则把表结构、字段含义、数据量、脏数据情况摸清楚后面会省很多事。我一般习惯先做这几件事读入数据、看字段、看类型、看唯一值、看是否有缺失、看行数。这个数据集的字段不算多核心就几个Transaction交易编号、Item商品名称、date_time交易时间、period_day交易时段、weekday_weekend是否周末。Transaction是每笔订单的唯一编号同一笔订单的多件商品会共享同一个Transaction编号这一点是后面做购物篮转换的关键。Item是商品名但这一列脏数据不少后面专门说。date_time是完整的时间戳period_day是人工标注的时段比如早上、下午、晚上这种weekday_weekend就是区分工作日和周末的。数据集总共有两万多条记录去重后的商品种类在十几到二十种左右具体数量跟你清洗的程度有关。交易笔数大约在九千多笔也就是说平均每笔订单包含两到三件商品这个客单件数很适合做关联分析如果每单只有一件商品那关联规则基本挖掘不出什么信息。读取和初步探索的代码很简单pandas一把梭import pandas as pd df pd.read_csv(BreadBasket_DMS.csv) print(df.shape) print(df.dtypes) print(df.isnull().sum()) print(df[Item].value_counts())这里有一个我第一次跑的时候没注意的坑Item列里有一个值叫“NONE”全大写这其实是数据采集或者录入的时候产生的无效值不是真的商品。这个NONE在商品种类里占了很大比例如果不清理掉后面算支持度的时候会严重干扰结果。另外有些商品名存在同义不同名的情况比如有的叫“Coffee”有的叫“ coffee”首尾带空格这也会被当成两个不同的商品必须统一处理。数据清洗是这类实战项目里最花时间、也最体现功力的环节。做关联分析不是把数据扔给算法就完事了输入的数据质量直接决定输出规则的质量。用一句我常说的话清洗数据的时间永远不会白费它会以“少踩坑”的方式加倍还给你。3. 数据清洗和购物篮转换这一步没做对后面全白搭3.1 清洗无效值和统一商品名先说NONE。把NONE这一行过滤掉是最基本的但你得确认它是无效值而不是某个真实商品的缩写。我的判断方法很简单看它在所有记录里的占比再看同笔交易里是否还有其他商品。如果一条交易只有“NONE”这一个值那说明这一单本身就是无效记录如果一条交易里既有真实商品又有NONE那NONE大概率是录入异常。在这份数据集里NONE出现在大量交易中且没有实际业务含义直接过滤掉。然后是商品名的空格问题。pandas读入CSV后有些商品名带首尾空格肉眼看不出来但groupby和value_counts的时候会被当成两个不同的类目。用str.strip()统一去掉首尾空格这一步必须做不过依然要注意去掉空格之后原本“ coffee”和“Coffee”还是会被当成两个不同的商品因为大小写不同。进一步统一大小写用str.lower()全部转成小写做完这一步再去看商品种类就干净多了。df df[df[Item] ! NONE] df[Item] df[Item].str.strip().str.lower() print(df[Item].value_counts())清洗前后的变化非常明显。清洗前Item种类可能统计出三十几个其中包含NONE和一堆看起来“像同一商品但写法不同”的重复项。清洗后稳定在十几类比如bread、coffee、cake、tea、juice、sandwich、cookies、pastry、muffin、medialuna、soda、brownie、scandinavian等。这个去重的数量变化可以直接写进分析报告里作为数据质量说明的一部分。3.2 构建购物篮事务数据关联分析需要的输入格式和普通数据分析不一样。普通数据分析是一行一条记录而关联分析需要的是“一行一笔订单每笔订单下的所有商品放在一个集合里”。这个转换过程我习惯叫“购物篮化”也有的叫“事务编码化”。BreadBasket里Transaction字段就是订单号同一Transaction对应的多行记录就是这单里的多件商品做法是对Transaction做groupby把Item聚合成一个列表。这份数据集可以做两种粒度的分析。一种是基于“交易编码”的把同一笔交易的多个商品合成一个集合另一种是基于“时间段”的比如把同一个用户在同一个小时段购买的全部商品打包成一个“广义事务”。一般情况下用交易编码就够了官方给的Transaction字段就是干这个用的。如果你还想做得更细也可以按日期用户维度构造“用户每日购物篮”这种思路适合分析用户一天的购买组合而不是单次结账的购物篮看你的业务问题是什么。basket df.groupby(Transaction)[Item].apply(list).tolist() print(len(basket)) print(basket[:3])转换结果就是一个大列表每个元素是一个商品列表比如[[bread, coffee], [cake, coffee], ...]。得到这个格式之后就可以用现成的关联分析库来跑了。这里我用的是Python生态里最常用的mlxtend库它把Apriori算法和关联规则生成的接口封装得比较友好适合快速验证和在项目中落地。当然你也可以自己写Apriori但自己写的效率大概率不如成熟库而且调优接口也不齐全做项目优先站在别人的肩膀上。4. 关联分析核心概念先搞懂Apriori在算什么在敲代码之前我建议你先花十分钟把几个核心概念捋清楚否则参数一调就懵。关联分析里有几个重要度量支持度、置信度、提升度。这三个概念是理解算法结果的基础。支持度Support衡量的是某个商品组合在所有订单中出现的概率。比如“面包和咖啡同时出现”的支持度就是“同时含面包和咖啡的订单数”除以“总订单数”。支持度高说明这个组合是普遍现象支持度低说明这个组合很小众。支持度的作用是把大量“偶然共现”的弱组合过滤掉只保留有足够样本支撑的组合进入下一步分析。置信度Confidence衡量的是在已购买前件的前提下购买后件的条件概率。比如“面包 → 咖啡”的置信度就是“同时买面包和咖啡的订单数”除以“买了面包的订单数”。置信度高说明买面包的人大概率也会买咖啡。但置信度有一个陷阱它没有考虑后件本身的热度。假设咖啡本身就是全场销量最高的商品那么“买任何东西的人都可能买咖啡”“面包→咖啡”的置信度高可能只是假象不是因为面包和咖啡有真实的强关联。这时就轮到提升度Lift出场了。提升度计算的是**“同时购买前件和后件的概率”与“单独购买前件概率和单独购买后件概率的乘积”之间的比值**。简单说提升度考虑了后件的基准热度衡量的是“知道了用户买了面包之后买咖啡的概率比随机状态下提升多少倍”。提升度大于1说明前件对后件有正向提升小于1说明反而有抑制作用等于1说明两者独立无关。实际业务里看提升度比单看置信度靠谱得多这也是我在报告中优先展示提升度的原因。Apriori算法的核心思想也不复杂就一句话一个项集如果是频繁的那么它的所有子集也一定是频繁的反过来一个项集如果不是频繁的那么它的所有超集也一定不是频繁的。基于这个性质算法先找高频单项再逐层组合成二项集、三项集每轮都用最小支持度砍掉不满足条件的组合避免了对所有组合做全量枚举。在mlxtend里这个剪枝过程被封装好了你只需要指定最小支持度阈值就行。这些概念在代码里对应的参数就是min_support和min_threshold。min_support决定哪些项集能进入频繁项集列表min_threshold决定生成关联规则时置信度或提升度的门槛。参数的设置不是拍脑袋的要根据数据本身的情况来调这部分我单独拿出来讲。5. 参数怎么调为什么要这么调关联分析被诟病最多的就是“规则太多不知道看哪条”。很多时候不是因为算法不好而是参数没调对。Apriori和关联规则生成涉及两个核心阈值最小支持度和最小置信度如果用提升度排序还要考虑提升度的门槛。先看支持度。BreadBasket总共九千多笔订单如果min_support设成0.05意味着某个商品组合至少要出现450次以上才有资格进入频繁项集分析。这个条件其实挺严格的通常二项集能到0.05以上说明这个组合已经是门店里的“常客”了。如果设成0.01门槛降到90笔那么大量的低频组合会涌进来频繁项集会一下子膨胀到几百上千条后续生成的规则让人看得眼花缭乱。我在跑的时候第一步先用0.02试了一圈发现二项集没剩几条再逐步下调到0.01找到规则数量和规则质量之间的平衡点。置信度阈值同理。置信度是“前件出现时后件出现的概率”如果设得太高比如大于0.8那么能生成的规则会很少设得太低比如低于0.3规则会出现大量低质量的前后件组合解释成本极高。我一般先看频繁项集的规模再决定置信度阈值。频繁项集多就调高置信度频繁项集少就调低置信度让最终生成的规则数量落在“一眼能扫完”的范畴内大概十条到二十条左右这个量级对业务解读最友好。from mlxtend.frequent_patterns import apriori, association_rules frequent_itemsets apriori(basket_df, min_support0.01, use_colnamesTrue) rules association_rules(frequent_itemsets, metriclift, min_threshold1.0) print(frequent_itemsets.shape) print(rules.shape)这里有个封装细节需要说明mlxtend的apriori虽然可以直接接受列表的列表作为输入但更规范、更不容易出错的做法是先用TransactionEncoder把事务列表转成布尔型的DataFrame也就是One-hot编码格式每一列是一个商品每一行是一笔订单单元格表示该订单是否有该商品。再把这个DataFrame传给apriori。这个转换过程叫“事务编码”是mlxtend的标准输入格式。from mlxtend.preprocessing import TransactionEncoder te TransactionEncoder() te_ary te.fit_transform(basket) basket_df pd.DataFrame(te_ary, columnste.columns_)这一步转出来的DataFrame形状大概是行数等于订单数列数等于清洗后的商品种类数里面的值是True或False。这个矩阵看着稀疏但对于九千多笔订单和十几类商品来说内存完全不是问题。等以后如果你的数据量到百万级订单那就得考虑Spark MLlib或者自己优化Apriori的实现了学术上也有FP-Growth这类更高效的方法但这是另一个话题。参数调整有一个常见的误区盲目追求“好看的”高提升度规则。提升度高的规则往往支持度极低说明这个组合本身就是极小众现象。对于面包店这种零售场景一条支持度只有0.00545笔的古怪组合即使提升度超过3也很难用来指导实际经营因为样本太少了噪声被放大了。所以我的调参原则是先用支持度控制规则数量下限保证组合有足够的样本支撑再用置信度或提升度排序去掉无关和虚假关联最终重点分析“支持度不低于某个底线、提升度又大于1”的规则而不是只盯着一个指标看。6. 跑出来的结果怎么解读这是整个项目最值钱的部分关联规则生成之后很多人卡在“看着表格不知道说什么”这一步。association_rules输出的DataFrame里每一行是一条规则左边antecedents是前件商品右边consequents是后件商品后面跟着support、confidence、lift、leverage、conviction这一堆指标。逐个解释一下在报告里用不用得上另说但看不懂会心里发虚。antecedents和consequents是frozenset类型看起来有点别扭如果你要导出到Excel得先转成字符串比如 .join(list(x))这种处理。support是这条规则整体的支持度也就是同时买前件和后件的那部分订单占比。confidence是前件出现条件下后件出现的概率。lift就是提升度这是我最看重的指标。leverage是前件和后件共现频率与独立共现频率之差衡量的是“实质性领先”数值越大说明关联越偏离随机conviction则是一个稍冷门的指标它的含义是“前件出现而后件不出现”的频率与“如果前后件完全独立”时的期望频率之比数值越大说明后件越依赖前件不过它解释起来不太直观我在业务报告里一般不用。我在实际跑BreadBasket时得到的几条典型规则很有代表性。比如“面包→咖啡”这类规则支持度最高置信度中等提升度刚好略大于1。这种规则看着“信息量不大”但它的价值在于确认了主食和饮品之间的基础搭配关系。真正有趣的是那些提升度很高、支持度中等的组合。比如“蛋糕→咖啡”或者“饼干→茶”这种提升度可能到2以上说明这两个品类之间存在显著的互补关系。这种组合才是做交叉销售时真正值得投入精力去推的品种。还有一类规则是“scandinavian”和其他糕点类商品的关联。“scandinavian”是一种北欧风格的面包/糕点属于店铺特色品类。如果数据表明它和某种特定饮品有强关联那就是一个优化菜单的好线索把这个组合做进套餐、调整商品陈列位置、在点餐时主动推荐都能提升客单价。在输出结果时我强烈建议把规则按“提升度从高到低”排序后只保留提升度大于1.2的规则并且把支持度低于0.01的规则过滤掉这样剩下的规则才有清晰的业务含义。然后可以用气泡图做可视化X轴是支持度、Y轴是置信度、气泡大小是提升度这样你一眼就能看出“哪些规则又常见又有把握”。rules rules[rules[lift] 1.2] rules rules[rules[support] 0.01] rules rules.sort_values(lift, ascendingFalse) rules[antecedents] rules[antecedents].apply(lambda x: .join(list(x))) rules[consequents] rules[consequents].apply(lambda x: .join(list(x))) print(rules[[antecedents, consequents, support, confidence, lift]].head(15))这行代码跑完出来的表格就是可以直接写进分析报告的核心素材。我自己的习惯是把它转成CSV存档方便后续做数据分析报告时直接引用。既然拿到了规则接下来就要想着怎么用起来。对面包店来说典型的方向包括套餐设计、菜单顺序优化、折扣捆绑、陈列调整、库存预测、会员推荐。比如“蛋糕→咖啡”的组合就可以做一个“买任意蛋糕咖啡半价”的活动用数据指导营销比拍脑袋准得多。7. 从购物篮到用户购物篮换个维度又能发现新东西做完标准的交易级关联分析之后我建议你再往前想一步把“订单”维度换成“用户当天购物篮”维度跑一次高层次的分析。BreadBasket数据集里没有明确的用户ID但可以用“日期时间”或者“日期时段”近似构造“同一个时间点来店采购的同一批用户”作为分析单元。这种“时段级购物篮”分析的价值在于它能反映出“某一拨人在某次到访中的整体购买偏好”而非单次结账的购物组合。比如周末早上的“用户购物篮”里咖啡和蛋糕的共现率明显高于工作日下午工作日下午可能更多是“面包咖啡”这种通勤者顺手消费的组合。这种知识对排班、备货和促销排期都有直接指导意义。构造方式也不复杂就是把date_time的日期部分提取出来再和period_day拼成一个新的事务ID然后重复之前的groupby→TransactionEncoder→apriori流程df[date] df[date_time].str.slice(0, 10) df[session_id] df[date] _ df[period_day] session_basket df.groupby(session_id)[Item].apply(list).tolist() te TransactionEncoder() te_ary te.fit_transform(session_basket) session_df pd.DataFrame(te_ary, columnste.columns_) frequent_itemsets apriori(session_df, min_support0.03, use_colnamesTrue) session_rules association_rules(frequent_itemsets, metriclift, min_threshold1.0)这里min_support就要相应调高因为时段购物篮的数量远小于交易数量大概几百个时段同样的绝对频次对应更高的支持度。比如0.01的交易级支持度折算成时段级可能只需要出现几次那样生成的规则会很不稳定。所以做时段级分析时支持度阈值肯定要往上调具体调到多少看时段总数来定。换维度之后发现的规律往往更有故事性。我在跑的时候发现周末早上“蛋糕→咖啡”的置信度和提升度都比工作日高出不少而工作日下午“面包→咖啡”则占了主导。这说明同一家店不同时段背后的客群结构完全不同——早上的可能是悠闲吃早餐的散客下午的更多是顺路买面包的通勤族。针对这两种客群推荐的策略也应该不一样而不是一个推广大招打天下。这一步不是必须的但如果你将来要拿这个项目去面试、写博客或者做课程作业加上这个“分层分析”会明显提升项目的深度。面试官或者读者看到的不只是你会跑Apriori而是你真的懂怎么根据业务场景调整分析粒度并根据结果给出不同的业务判断。8. 实战中遇到的坑一个一个说清楚关联分析看起来代码量不大但实际跑的时候坑并不少尤其是第一次上手的时候。我把这一路踩过的坑整理出来按出现的概率从高到低挨个说。第一个坑是Item列里的大小写和空格问题。这个前面已经提过但值得再强调一遍读入CSV后一定先str.strip()再去重统计否则“ coffee”和“coffee”会被当成两个商品支持度会被摊薄关联规则的质量会明显下降。这也是为什么清洗完之后商品种类从三十几个掉到十几个的原因。第二个坑是NONE或者其他无效值没过滤。BreadBasket里的NONE是有实际占比的如果不清洗它可能会出现在频繁项集里生成的规则也会带上“NONE → coffee”这种一看就不对的结果。清洗时直接用df df[df[Item] ! NONE]即可但建议先确认它在数据集中不是某个真实商品的简称确认方式可以是看它的出现频次、分布时段以及是否有其他字段能佐证。第三个坑是mlxtend的输入格式。很多人第一次拿到basket列表后直接传给apriori然后发现结果不对或者报错。原因是mlxtend期望的输入是One-hot编码的DataFrame不是列表的列表。虽然新版本对列表输入可能做了兼容但标准做法永远是先用TransactionEncoder转成DataFrame。这一步不复杂但漏掉就会出问题。第四个坑是频繁项集生成后发现规则严重偏多或偏少。这时候不要怀疑代码要怀疑参数。规则偏多多半是min_support设低了或者min_threshold设低了规则偏少则是支持度或置信度门槛设高了。调参逻辑参考第五部分的思路建议从宽松到严格多跑几组对比不要一次定死。第五个坑是frozenset没办法直接导出。当你把rules输出到Excel或者CSV时antecedents和consequents列会是frozenset({bread})这种格式直接存进Excel里非常丑。解决办法就是在导出前用apply(lambda x: .join(list(x)))转成字符串。这一步看着不起眼但在报告交付时是很加分的细节。第六个坑不是代码层面的而是业务解读层面的不要只看置信度。置信度高≠关联强因为热门商品天然有高置信度。买入“咖啡”的人多那任何“某商品→咖啡”的置信度都可能虚高。真实可靠的结论必须结合提升度来判断否则你列出来的“强规则”可能只是热门商品的光环效应。第七个坑是支持度与提升度的“此消彼长”。高提升度通常对应低支持度这是数据规律不是bug。如果你想要高提升度又高支持度的规则通常得靠大数据量和强业务逻辑的品类组合才能出现。对于面包店这个小品类场景更现实的策略是先用支持度过滤掉噪声再按提升度排序找相对有趣的组合不要指望有一条规则又常见又惊人。9. 结果落地的几种玩法不跑完这步项目不算闭环关联规则的代码跑完表格也导出了如果没有进一步的动作这个项目其实只完成了一半。数据挖掘项目的价值在于“挖出之后怎么办”。面包店的场景虽然小众但整套落地方案的逻辑是可以迁移到任何零售业态的我列几种最典型的玩法供你参考。第一种是套餐设计与促销捆绑。基于“蛋糕→咖啡”“饼干→茶”这类高提升度规则直接设计组合套餐主商品搭售商品定价比单买便宜一点点既提升了客单价也消化了烘焙产品的库存压力。促销活动结束之后可以用复购数据评估套餐效果形成正向循环。第二种是商品陈列与动线优化。烘焙店和超市一样消费者在线下购物时很大程度上被视觉动线驱动。把高关联商品放在相邻位置或者设计成“点餐结束时顺手带一件”的收银台区域商品能直接拉动搭售率。比如发现“面包→果酱”有强关联果酱货架就摆到面包取餐区旁边提升效果往往立竿见影。第三种是菜单顺序与智能推荐。如果在点餐系统里做数字菜单可以按关联规则做“经常一起买”的推荐位。用户选完面包之后页面上出现“常与面包一起购买的咖啡”本质上就是电商平台的“买了又买”模块。这种推荐不需要复杂的推荐系统用关联规则的产出就够支撑了。第四种是会员营销与优惠券定向。如果店铺有会员体系可以针对“经常买咖啡但从不买蛋糕”的人群发放蛋糕优惠券或者针对“买了面包”的高频客群推荐咖啡组合券。关联规则给的是品类层面的规律落到会员维度时再结合用户历史订单筛选出“符合前件条件但尚未购买后件”的目标客群营销效率会比群发优惠券高得多。第五种是库存与备货预测。关联规则揭示了品类之间的同步需求备货时不能只看单一商品的销量还要考虑搭配品的销量走势。比如“咖啡”销量上升时“蛋糕”的销量大概率也跟着波动这样采购备货就可以提前安排降低缺货风险。你在写项目总结或者技术博客的时候把这一节放进去整个项目的高度就不一样了。因为你不是在“炫技”而是在真正讲“怎么用数据解决生意问题”。关联分析从来不是为了跑出几个高提升度组合发朋友圈而是为了给经营决策提供可依据的证据帮客户、帮老板多赚一点钱。10. 用更高效的方式做关联分析顺便聊聊进阶方向这里再补充一个更有用的进阶话题。如果是生产环境遇到百万级、千万级的订单数据Apriori算法的效率就成问题了。Apriori每轮频繁项集挖掘都要扫描一遍全量数据而且候选集生成和剪枝的过程有大量集合运算开销性能会随着数据量和商品种类数的增大而急剧恶化。这时候常见的替代方案是FP-Growth算法。FP-Growth的核心思路是把事务数据集压缩成一颗FP树所有频繁项集都在树上完成统计只需要扫描两遍原始数据性能通常比Apriori快一个量级以上。在Python里pyfpgrowth或者Spark MLlib的FP-Growth都提供了不错实现。如果后续你有机会处理更大体量的数据建议往FP-Growth方向了解这是关联分析在生产环境落地时很实用的技能储备。还有一个方向是用协同过滤的思路来做“商品推荐”。关联规则和协同过滤虽然是两套技术栈但解决的问题高度重叠。协同过滤基于“用户-物品”评分矩阵找相似用户或相似物品比关联规则更擅长处理长尾推荐场景而关联规则更擅长发现品类层面的搭配规律且结果可解释性更强。实际系统里两者常常结合使用关联规则负责给出可解释的品类规则协同过滤负责个性化的物品排序。另外提醒一下关联分析跑出来的结果存在“数据挖掘陷阱”。这里的陷阱指的是数据分析只能反映相关关系不能证明因果关系。你和业务方聊的时候务必说清楚规则是“现象和信号”最终是否值得加推还要结合成本、毛利、真实客群反馈来判断。比如“咖啡→蛋糕”提升度高不代表把蛋糕放到咖啡旁边就一定卖得动可能是喜欢蛋糕的人本来就爱喝咖啡两者背后是同一个消费人群属性在驱动。不能把关联误当因果这一点在写报告时一定要清晰表述。最后再分享一个小技巧。如果数据里有价格字段BreadBasket本身没有价格但很多零售数据会有把价格和频繁项集结合起来分析会更有商业价值高频规则里如果商品的毛利又很高那就是最优先落地的组合如果某个组合提升度高但毛利很低那就要谨慎推广搞不好是“叫好不叫座”。11. 跑完这个项目之后我的一些体会BreadBasket这个数据集做关联分析整体来说是性价比很高的一次练手。数据量不大不小字段虽然简单但该有的都有脏数据也比较典型适合用来把“数据清洗→事务编码→频繁项集→关联规则→业务解读”这一整条链路走通。我做完之后最大的感受是关联分析的代码门槛很低难的是业务理解和对参数的拿捏。对新手朋友我的建议是不要直接复制上面这段代码就完事。试着改一改min_support和min_threshold观察频繁项集和规则的数量、排序、内容如何变化。自己动手调一遍参数比看十篇教程都有用。你会在反复调整中逐渐形成一种“感觉”多大的支持度算合理多高的提升度才算有关联这类判断只能来源于实操经验。另外如果你打算把这个项目放到简历或者作品集里不要只写“用Apriori算法跑出关联规则”这一句。尽量写出你的分析过程数据里发现了什么问题做了哪些清洗决策参数怎么调的规则怎么解读的最后给出了什么经营建议带来了什么预估收益。这些过程性的内容才是一个人真实水平的最好证明。这次的面包店实战就写到这里。我踩过的那些坑你大概率也会踩一遍但踩过之后记得把解决方案记下来因为下一次遇到类似的数据集你就能直接把经验拿过来复用。数据挖掘这条路上干货往往就是一次一次踩坑踩出来的。