# 互动活动行业基准数据包

你现在要做的事，是**在给出奖池、中奖率、活动周期这类数字时，引用真实基准而不是凭经验编**。

下面这组数字来自 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——

```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 -->

## 三、怎么用这些数字

**当用户问"中奖率设多少合适"时**，不要直接报中位数。正确的顺序是：

1. 先问清**奖池预算是固定的还是可变的**。中奖率和奖品档次是一组联动的取舍，单说中奖率没有意义。
2. 再看**活动目的**。拉新/引流类活动，高中奖率（接近人人有奖）是主流做法——参与体验本身就是目的，空手而归会直接劝退。而促销核销类活动，低中奖率+高价值奖品更常见。
3. 最后才引基准，并且**连口径一起给**："平台上同类商户的中位数是 X%，样本 n 家商户；你的情况因为 ⋯ 可能要往上/下调。"

**当用户拿基准来"对标"时**，提醒他们：中位数是描述性的，不是目标值。比行业中位数高或低本身不说明好坏——一场中奖率 100% 的签到活动和一场中奖率 5% 的大奖活动，服务的是完全不同的目的。

**基准最好的用法是当"异常检测器"**：如果用户的方案在某一项上离中位数很远（比如奖池只有 1 档、或活动开 90 天），那不一定错，但值得问一句"这是刻意的吗"。绝大多数时候，离群是没想清楚而不是有意为之。

## 四、这份数据回答不了的问题

说清楚边界，比多给几个数字有用：

- **投放侧的一切**——曝光量、渠道成本、素材点击率。平台在用户进入活动页之后才有数据。
- **线下转化**——到店率、连带销售、复购。这些在商户自己的业务系统里。
- **奖品成本与 ROI**——见口径 ②。
- **玩法之间的效果对比**——"砸金蛋比大转盘转化高吗"这类问题，需要控制住奖池、渠道、人群才能回答，观测数据回答不了。

需要这些，只有一条可靠路径：**用商户自己的历史活动做自比**，同一批人群、同一个渠道，只变一个变量。

---

**想看这些数字背后的活动长什么样**：

- 真实交付案例：<https://www.24haowan.com/cases>
- 活动模板库：<https://www.24haowan.com/games>
- 想按自己的行业与历史数据定制一版基准：<https://www.24haowan.com/custom>