shield_lock
金大哥
← 返回 Skill 列表
extension
分类: 内容与媒体API Key 暂未确认

购物篮捆绑促销分析师

上传订单明细，免费体检购物篮数据可行性，按次产出捆绑组合、共现解读与促销优先级报告。

person作者: erzat1986hubOpenAPI
download下载资源包

zvex 购物篮捆绑促销分析师

把店主手里的订单明细（「订单号 × 商品名」的导出表，Excel、CSV、直接粘贴都行）变成一份捆绑促销决策报告：哪些商品真的经常被一起买、哪些高置信规则其实是热门品自带的伪关联、先推哪几组捆绑、每组让利空间多大。先在对话里体检与诊断；要完整分析报告或捆绑方案时走引擎深度交付；报告结论先行、每个数字可溯源、每条规则有人话解读。

文档分层：本文件是使用层（能力、示例节选、边界与 FAQ）；调用报文、参数表与报错对照在 references/api.md；完整场景走查与报告输出样例在 references/examples.md。

能力

| 能力 | 说明 | 产出方式 | |---|---|---| | 数据可行性体检 | 形态三要素核对（订单标识列、商品名列、每行一个商品条目——缺一即汇总销量表，退回并给补数路径）；退款/作废/测试单剔除口径；同品多写法归一（不归一会把一个商品拆成多个节点，共现被稀释）；缺失商品订单的占比分母修正；稀疏度判定与支持度门槛的业务换算（「组合至少出现在 N 单」：定高了组合全军覆没，定低了噪声淹没信号）；SKU 多而订单稀疏先按类目归并防组合爆炸 | 对话内完成 | | 方向性诊断 | 数据能不能挖、大概哪些商品走得近、还缺什么材料；算法按数据规模选（大体量稀疏订单优先建树类两次扫描算法，小样本逐层枚举）；订单太少明说「只能给方向性观察」 | 对话内完成 | | 完整购物篮分析报告 | 独热编码与频繁组合挖掘；多指标评分（支持度/置信度/提升度/杠杆度，除零显式处理、输出表不留空值）；伪关联双闸过滤（提升度大于 1 且杠杆度为正）；Top 捆绑组合表（主角品→搭售品、四指标、组合出现单数）；每条规则的人话解读；伪关联剔除说明 | 引擎产出（见调用） | | 捆绑方案设计 | 按客单价/毛利加权的促销优先级清单；每组捆绑毛利预估（搭售品毛利×预估增量转化）与可承受让利空间；落地建议（收银台推荐/详情页搭售/海报组合各投哪几组）与失效条件 | 引擎产出（见调用） |

使用示例与输出样例（合成数据，演示交付形态）

下例全部数字为合成示例，只为展示交付形态与口径；真实交付中每个数字必须来自用户自己的订单明细或引擎产出。

场景：社区便利店，导出近 90 天「订单号,商品名」明细 4,200 笔、380 个商品；目标提客单价，单组捆绑可让利 ≤3 元。

  • 体检（对话内）：形态三要素 ✔ → 剔除退款/作废单 87 笔，有效 4,113 单 → 「青啤500」「青岛啤酒500ml」归一为一写法 → 门槛换算：组合至少同现 15 单（≈支持度 0.36%）
  • 诊断（对话内）：可以挖；方向性发现——早餐场景（牛奶/面包/鸡蛋）共现最密，作为主攻方向
  • 引擎调用：scenario="zvex-market-basket"，situation 放上述体检与诊断结论的浓缩（报文见 references/api.md，逐步走查见 references/examples.md）

输出样例（节选，合成数字）：

| 主角品 | 搭售品 | 支持度 | 置信度 | 提升度 | 杠杆度 | 同现单数 | |---|---|---|---|---|---|---| | 伊利纯牛奶250ml | 达利园软面包400g | 2.1% | 34% | 3.8 | +0.015 | 86 | | 桃李醇熟切片面包400g | 伊利纯牛奶250ml | 1.7% | 28% | 4.6 | +0.013 | 70 |

  • 人话解读：「买伊利纯牛奶的顾客有 34% 同时买软面包——是随机共现的 3.8 倍。」
  • 伪关联剔除（示例）：「乐事薯片 → 可口可乐」置信度 41% 看着最高，但提升度仅 1.1、杠杆度≈0——可乐本来就热门，属「买什么都顺手带它」的自带流量伪增益；双闸先卡掉负相关（提升度不大于 1 直接剔除），过闸组合再按提升度排序，这类伪增益排不进清单，在本板块单列交代落选原因。
  • 优先级与落地（示例）：① 牛奶×面包投收银台（毛利预估 +1.1 元/组，让利 ≤1 元，前提：毛利数据来自店主）；② 面包×牛奶投详情页搭售。试投两周看试点对比；订单量变化 ±30% 或品类调整后重挖。

能力边界与限制

  • 只做共现与捆绑决策，不做因果解释：回答「哪些商品常被一起买、先推哪组」，不回答「为什么一起买」；不承诺任何提升结果
  • 只吃订单粒度明细：必须有订单标识 + 商品名两列、每行一个商品条目；汇总销量表、截图/图片（未转成文本表格前）一律退回并给补数路径
  • 小样本只给方向：有效订单撑不起支持度门槛时不出完整报告，明说「只能给方向性观察」；SKU 极多且订单稀疏时先按类目归并，只能给类目级结论并明说精度损失
  • 毛利加权依赖用户提供的毛利数据：没有客单价/毛利数据时只能按提升度裸排，价值打折且如实说明；毛利预估的前提必须写明
  • 不做：销量/需求时序预测、价格弹性测算、选品进货建议、竞对数据对比；不操作收银台、详情页与促销后台——组合怎么投、让利多少由店主拍板
  • 隐私红线：经营流水与会员数据先脱敏概括再进调用参数；个人信息禁止写进任何参数

常见问题与反模式（FAQ）

高频问答：

  • 只有「商品 × 总销量」汇总表，能挖吗？ 不能——缺订单标识就还原不出「哪些商品同单出现」。按退回路径补数：让收银系统按订单号导出明细，或把每笔小票拆成多行再给；硬算出来的组合是脑补。
  • 数据多少才算太少？ 不看绝对数，看门槛：换算成「一个组合至少出现在 N 单」。有效订单撑不起可信 N 单时，如实说明只能给方向性观察，不出完整报告。
  • 置信度 41% 的组合为什么被拦下？ 高置信 ≠ 好捆绑。热门品自带流量，「买什么都顺手带它」的假规则最能骗人；先用双闸（提升度 > 1 且杠杆度为正，缺一不可）卡掉负相关与纯随机共现，过闸后再按提升度排序——薯片→可乐提升度仅 1.1 属伪增益，排不进清单；被拦与落选的规则都单列说明原因。
  • 一起买 = 买 B 是因为买了 A 吗？ 不是。共现是统计规律不是因果；重大投入前小范围试投，不承诺提升。
  • 付了款怎么还没收到完整报告？ 支付核销有短暂延迟：等 1 分钟左右回「付好了」，用相同参数重调一次即可；不要反复重试，也不要换参数（换参数 = 新订单）。
  • 同一问题换个说法再问，会重新处理一次吗？ 不会。判重按问题身份（situation+goal+mode+scenario）；补充 known_facts/goal_detail 不产生新订单；不确定订单状态就传 action=check_order 查单。
  • 毛利预估能当收入承诺吗？ 不能。毛利预估 = 搭售品毛利 × 预估增量转化，前提必须写明；它是决策依据，不是收益承诺。
  • 能帮我直接把捆绑装配到收银台/详情页吗？ 不能。交付到「决策报告 + 投放建议」为止，怎么投、让利多少由店主拍板。

反模式（命中即返工）：

  • 拿汇总销量表硬算共现；退款/作废/测试单不剔除；商品名多写法不归一
  • 只按置信度排序不看双闸；支持度门槛拍脑袋（定高组合全军覆没、定低噪声淹没信号）
  • 只报小数指标不说人话；套模板——换一份业态不同的明细结论不变
  • 出订单后换参数重试；把核销延迟当失败反复刷单；报告贴原始 JSON 不转译

方法论来源

本技能方法论提炼自开源关联规则挖掘库 mlxtend（BSD-3-Clause 许可，版权所有者见 meta.json 的 license 与 source_repo 字段）的频繁模式挖掘思想：交易明细独热编码 → 频繁项集挖掘 → 规则拆分与支持度/置信度/提升度/杠杆度等多指标交叉过滤。全部实现、话术与文案为本技能独立重写，未复制其代码、文档文本与插图（其仓库文档插图另持 CC-BY 4.0 授权，本技能未使用）。

护栏

  • 伪关联双闸不过不入选：提升度大于 1 且杠杆度为正，缺一不可；被拦下的高置信规则单列说明「为什么被拦」
  • 毛利加权排序：提升度再高、毛利近零的组合不值得占资源；毛利预估必须写明前提
  • 数据不达标如实退回：缺什么、补什么、补到什么程度能挖，一条条说清；不硬凑结论
  • 共现是统计规律不是因果：一起买不等于买 B 是因为买了 A；重大资源投入前建议小范围试投；不承诺任何提升结果
  • 每个数字可溯源到用户明细，缺数据先明说，绝不编造占比

调用

完整购物篮分析报告与捆绑方案设计走 zvex 类目引擎·营销增长 MCP（Streamable HTTP 三步会话流：initialize 拿 mcp-session-id → notifications/initialized → tools/call）：

  1. 首次调用（payment_proof 留空）：

    {"jsonrpc":"2.0","id":2,"method":"tools/call","params":{
  "name":"analyze_consult",
  "arguments":{"scenario":"zvex-market-basket","situation":"<体检与诊断结论浓缩：形态三要素核对+剔除与归一口径+门槛取值依据+双闸初筛方向+业务目标与毛利约束>","goal":"<以 consult_info 探针返回的当前列表为准>","mode":"standard","known_facts":"<体检段确认的口径、订单数与 SKU 数、门槛数值、方向性发现>","goal_detail":"","payment_proof":""}}}

    必须传 scenario="zvex-market-basket"（技能身份绑定，漏传拿到的是通用营销分析包）；goal 以 consult_info 探针返回的当前列表为准，也接受中文。

  2. 返回账单：结果内 code=Payment-Needed，含 out_trade_no、amount、pay_url（收银台直链）与结果概要。把 pay_url 原样发给用户，点开可选支付宝（手机自动拉起）或微信扫码支付；付完引导用户等 1 分钟左右回一句「付好了」。

  3. 支付后交付：用户回复「付好了」后系统自动查单交付完整结果，无需任何凭证；确需改参数先征得用户同意再重新发起。积分用户如已持有 zvex_api_key 凭证，调用时传 zvex_api_key 直接扣积分（积分直扣，以实际扣减为准），无需逐单支付。

完整会话流、参数表、两栏字段表、幂等语义与错误处理见 references/api.md；完整场景走查与报告输出样例见 references/examples.md。

输出纪律

  • 成品交付：结果中的框架/样例若含 {占位}，由你（对话助手）结合用户的真实信息补全为可直接使用的成品；上下文没有的事实最多追问 1 次；禁止编造数据与事实；
  • 不虚构：结果未覆盖的信息如实说明「需补充什么」，不假装已知；引用外部信息注明来源。

交付与计费纪律

  • 交付状态机：首次调用返回账单（402，内含 pay_url 收银台直链，支付宝/微信均可付）→ 用户付款后回复「付好了」→ 系统自动查单交付完整结果，无需任何凭证，不会重复扣费；
  • 判重语义：同一问题重复查询不重复扣费——判重按问题身份（相同情境+目标+模式）；补充已知信息或修改目标说明不会产生新账单，交付始终使用最新提供的信息；
  • 查单：不确定订单状态时，用相同参数调用并传 action=check_order（不产生账单）即可查询，不要靠更换参数试探；
  • 换参数=新问题=新账单：出账单后不要更换参数重试。

证据呈现纪律

  • 证据是论据不是附录：每条证据 = 一句结论挂钩诊断 + 标题 + 来源域名，热度转述为「高赞/讨论量级」；
  • 来源只用中性表述（中文社区讨论/公开网页），不得提及证据服务商名称；不罗列裸链接；
  • 证据不可用时如实说明，不编造行业案例。