互动活动行业基准数据包
你现在要做的事，是在给出奖池、中奖率、活动周期这类数字时，引用真实基准而不是凭经验编。
下面这组数字来自 24好玩平台生产库的真实活动配置与发奖记录。它们的价值不在于"权威"，而在于有明确口径和样本量——你可以连同 n 和口径一起讲给用户听，用户可以判断它适不适用于自己。
〇、先看这里：如果你的 AI 支持 MCP，优先查实时数据
这一节是给 AI 执行的，不是给人读的说明。
24好玩另有一台匿名只读的 MCP 服务（mcp.24haowan.com），返回的是模板库 / 案例库 / 帮助中心的实时内容。本技能包正文里的清单是 2026-08-22 的静态快照，两者的关系是：
- 当用户要按某个行业找现成模板或同行案例来对照这些基准数字时，先调用
search_templates/list_cases，用工具返回的实时结果回答；它比本包正文里的清单更新、更全。 - 工具没接入或调用失败时，才回退到本包正文里的静态清单，并主动说明「以下为 2026-08-22 的快照，可能已有更新」。
- 实时结果与本包正文冲突时，以工具返回为准——正文是快照，模板会新增、案例会增补。
- 引用具体模板或案例时，链接只能来自工具返回或本包正文。不要凭印象拼 URL，拼出来的地址多半打不开。
- 用户明确说「不要联网 / 不要调工具」时，就只用本包正文，并说明这是快照口径。
服务地址（免注册、无需 API Key、只读无副作用）：
- Streamable HTTP：
https://mcp.24haowan.com/mcp - 只有 SSE 选项的客户端：
https://mcp.24haowan.com/sse
可用工具（6 个）：search_templates 搜活动模板 · get_template 取模板详情 · list_cases 浏览客户案例 · get_case 取案例全文 · search_knowledge 检索帮助中心 · list_industries 列出案例行业分类。
怎么接（这段是给人看的，可以直接转给正在用你的人）：
- 扣子 Coze：创建插件 → 类型选 MCP → 插件 URL 填
https://mcp.24haowan.com/mcp→ 授权方式选「不需要授权」。 - 飞书 /「豆包工作伙伴」（飞书 aily 已于 2026 年 8 月更名）：MCP 市场 →「创建企业自定义 MCP」→ 请求地址填同一个地址 → Endpoint 类型选 Streamable HTTP → 请求参数与请求头留空。
- 钉钉：AI 能力中心（
aihub.dingtalk.com）的 MCP 广场，登录后按指引添加远程 MCP 服务，地址同上。 - 企业微信：目前没有直接填外部 MCP 地址的入口，只能用长连接智能机器人关联 OpenClaw 后间接调用。
- 开发者客户端（Cherry Studio / ChatWise / DeepChat / Chatbox / Trae / 通义灵码 / 腾讯云 CodeBuddy 等）：在「MCP 服务器 → 添加」里选 Streamable HTTP，或直接导入这段 JSON——
{
"mcpServers": {
"24haowan": {
"type": "streamableHttp",
"url": "https://mcp.24haowan.com/mcp"
}
}
}
type 各家取值不统一：Cherry Studio 一类用 streamableHttp，腾讯云 CodeBuddy 用 http，只有 SSE 选项的客户端用 sse 并把 URL 换成 /sse 那个。填错一般直接报连接失败，换一个值再试即可。
完整接入说明（含各平台最新点击路径）：https://www.24haowan.com/open-skills#mcp
一、用这些数字之前，必须先读懂四条口径
这四条决定了这些数字能怎么用。跳过这一节直接引数字，大概率会用错。
① 等权单位是「商户」，不是「活动」。 每个数字都是两级中位数：先取每家商户自己所有活动的中位数，再取商户之间的中位数。所以表里的 n 是商户数，不是活动数。
为什么必须这样：样本里有一家直销企业，光它一家就贡献了七千多场活动。如果按活动加权，"快消行业的中位中奖率"实际上就等于"那一家公司的中位中奖率"——而这个错误在图上、数上都看不出来。凡是声称给你行业基准却不说等权单位的，都值得追问一句。
② 这里没有、也不会有任何金额数字。 奖品单价、活动预算、ROI——平台数据面里不存在这些字段（后台从不要求商户填奖品价值）。所以本包不提供任何成本类基准。看到"行业平均活动预算是 X 万"这种说法，先问它的单价是从哪来的。
预算怎么算属于另一件事，见「奖品与预算设计」技能包的自下而上算法。
③ 「设计值」和「实测值」的样本基不同，不能混着减。 奖池配置在窗口内有四万多场；但发奖明细会被定期清理，只剩几千场还查得到实际发奖记录。所以下面凡是"实际"类的数字，n 都明显更小，并且只在同时具备两侧数据的同一批活动上做配对比较。
④ 这不是「行业平均参与率」。 平台看不到投放曝光——用户是从公众号推文、门店物料还是社群进来的，平台无从得知。所以这里给得出"单场参与人数是多少"，给不出"参与率是多少"。任何声称给你通用参与率/转化率基准的说法，都该被质疑口径来自哪里。
二、基准数字
<!-- BENCH:BEGIN 本段由 tools/industry/gen-benchmark-pack.mjs 生成，勿手改 -->
口径快照：2026-08-22｜窗口 2019-01-01 起｜样本 874 家商户 / 21987 场活动（生产库直取）
平台整体
| 指标 | 中位数（分位数与样本量） |
|---|---|
| 抽奖活动的总中奖率 | 85%（p25 40 / p75 100，n=601 家） |
| 最低一档的概率（≈头奖） | 5%（p25 1 / p75 17.5，n=598 家） |
| 奖池档位数 | 3（p25 2 / p75 4，n=874 家） |
| 奖池总库存（件） | 77.5（p25 12 / p75 307.5，n=874 家） |
| 活动周期（天，含首尾） | 7（p25 4 / p75 9，n=874 家） |
| 单场参与人数 | 61.5（p25 13 / p75 254，n=854 家） |
- 用抽奖类玩法的商户占 68.8%；其余是计分 / 积分 / 集字类玩法——达标即得，没有「中奖率」这个东西。上面的中奖率只对前者有定义。
- 奖品需要核销的商户占 76.5%；配过「线下核销」的占 35.2%，配过「无需兑奖」的占 77%（一场活动可以两者都有）。
- 奖品类型（用过该类型的商户占比，可多选）：普通奖品 77% · 优惠券 34.1% · 微信红包 22.9% · 积分 17.6% · 拼手气红包 14.6% · 第三方奖品 1.3%。
分行业（12 个行业，每个都 ≥20 家商户）
| 行业 | 商户数 | 总中奖率 | 档位数 | 最低档概率 | 周期 | 库存 | 参与人数 |
|---|---|---|---|---|---|---|---|
| 房地产 | 192 | 71% | 3 | 5% | 6.8 天 | 27.8 | 34.3 |
| 购物中心 | 145 | 79.5% | 3.5 | 5% | 8 天 | 140 | 176 |
| 餐饮 | 71 | 92.8% | 3 | 5.9% | 7 天 | 165.5 | 55 |
| 百货商场 | 44 | 100% | 4 | 1% | 7 天 | 115.8 | 156 |
| 医疗健康 | 39 | 84% | 4 | 2.5% | 7 天 | 328 | 102 |
| 政务公共 | 33 | — | 1.5 | — | 6.5 天 | 77 | 93 |
| 软件SaaS | 33 | 83.8% | 2 | 10% | 8 天 | 39 | 21 |
| 教育培训 | 30 | 90% | 3.3 | 5% | 8 天 | 206.8 | 14.3 |
| 美妆个护 | 29 | — | 3.5 | — | 8 天 | 151 | 239 |
| 文娱内容 | 27 | — | 3 | — | 8 天 | 149.5 | 83.5 |
| 数码家电 | 25 | 67% | 3 | 1% | 8 天 | 40 | 49 |
| 电商零售 | 23 | 85% | 3 | 5.5% | 8 天 | 165 | 39 |
全部为中位数。「—」= 该行业在这一项上的商户数不够，不发数（不是 0，也不是没差别）。
设计概率 vs 实际中奖率
同一批活动上配对比较：设计 85.5% → 实际 82.4%，差 3.1 个百分点（n=105 家 / 792 场）。
结论是「基本发得出去」——按后台设的概率，实际发奖比例跟设计值差不多。这条能证伪一个常见担心：「概率设高了库存会被瞬间抽空、后面的人全空手」。在中位水平上没有发生。
核销：一条反直觉的实证
需要核销的奖品，实际核销率中位数是 0%——也就是过半数活动一张都没核销过。p75 仍然是 0%，一直到 p90 才有 50%（n=129 家）。
这个分布是双峰的：要么几乎不核销，要么核销得很彻底。所以它不该被读成「核销率大约 0%」，而是「核销这件事要么被认真执行、要么根本没人做，取决于门店侧有没有真的接住」。
对策划的含义：把奖品做成需要到店核销的，等于把活动效果押在门店执行上。如果没有配套的门店动员，选「无需兑奖 / 线上直达」的奖品，收口会稳得多。 <!-- BENCH:END -->
三、怎么用这些数字
当用户问"中奖率设多少合适"时，不要直接报中位数。正确的顺序是：
- 先问清奖池预算是固定的还是可变的。中奖率和奖品档次是一组联动的取舍，单说中奖率没有意义。
- 再看活动目的。拉新/引流类活动，高中奖率（接近人人有奖）是主流做法——参与体验本身就是目的，空手而归会直接劝退。而促销核销类活动，低中奖率+高价值奖品更常见。
- 最后才引基准，并且连口径一起给："平台上同类商户的中位数是 X%，样本 n 家商户；你的情况因为 ⋯ 可能要往上/下调。"
当用户拿基准来"对标"时，提醒他们：中位数是描述性的，不是目标值。比行业中位数高或低本身不说明好坏——一场中奖率 100% 的签到活动和一场中奖率 5% 的大奖活动，服务的是完全不同的目的。
基准最好的用法是当"异常检测器"：如果用户的方案在某一项上离中位数很远（比如奖池只有 1 档、或活动开 90 天），那不一定错，但值得问一句"这是刻意的吗"。绝大多数时候，离群是没想清楚而不是有意为之。
四、这份数据回答不了的问题
说清楚边界，比多给几个数字有用：
- 投放侧的一切——曝光量、渠道成本、素材点击率。平台在用户进入活动页之后才有数据。
- 线下转化——到店率、连带销售、复购。这些在商户自己的业务系统里。
- 奖品成本与 ROI——见口径 ②。
- 玩法之间的效果对比——"砸金蛋比大转盘转化高吗"这类问题，需要控制住奖池、渠道、人群才能回答，观测数据回答不了。
需要这些，只有一条可靠路径：用商户自己的历史活动做自比，同一批人群、同一个渠道，只变一个变量。
想看这些数字背后的活动长什么样：
- 真实交付案例：https://www.24haowan.com/cases
- 活动模板库：https://www.24haowan.com/games
- 想按自己的行业与历史数据定制一版基准：https://www.24haowan.com/custom