这一页把我们平台上真实跑过的活动做成聚合分布,公开出来给做活动的人用。 全部只出聚合值:没有客户名、没有活动名、没有任何单商户数据,也没有收入相关的任何指标。
数据更新于 2026-08-22 · 机器可读版本 /data-report.json
报告里的数字分两类,口径完全不同,混着读会得出错的结论:
账号侧的累计计数器,只加不减:活动删掉了计数也不回退。它回答的是「这个平台上一共被建过多少场活动」。
状态为已发布或已结束的活动。本页所有分布都基于这一口径——建了没发的、草稿、已删除的都不算。
至少建过一场活动的账号数。不含从未建过活动的注册账号。
这两个总量不是同一件事,差了三倍多——所以这一页把它们并排放着, 而不是只挑好看的那个。每一节的标题旁边都标了它属于哪一侧、统计窗口是什么; 页面底部有一张完整的 口径与方法表。
把「客户实际用哪类玩法开活动」和「我们库里备了哪类玩法」放在一起看,会出现一个稳定的缺口: 抽奖类只占模板库的 14.3%,却承担了 20.4% 的真实活动—— 它是被用得最凶、相对最缺货的一类。测试类正相反:备了 4.9% 的货,只跑出 2.6% 的活动。
口径提醒:两侧用的是同一套归类规则(标签优先、类型兜底),但取自不同的表——需求侧按活动 实际使用的引擎模板归类,供给侧按活动市场在架的模板归类。「生成类」供给为 0 不是统计误差: 活动市场目前确实没有在架的生成类模板,而历史上有 2.4% 的活动用的是它。
怎么用:如果你在选玩法,抽奖类是最被验证过的一档——它简单、发奖路径最短、 对用户的理解成本几乎为零。分数闯关类占比最高(53.4%), 但那更多是因为库里这类模板本来就最多(57.9%),不代表它效果更好。
这是全页最该被拿去当参照的一组数——用分布而不是平均值:平均值会被头部的超大活动带偏, 对绝大多数活动没有参考意义。
把它当尺子用:做到 100 人,你就超过了 78.3% 的上线活动;做到 1000 人,超过 93.4%;做到 1 万人,你在最上面的 1% 里。
另一面同样值得看:17.8% 的活动上线后参与人数为 0。 活动被建出来、被发布,然后没有被投出去——这是这份数据里最常见的失败方式, 比「玩法选错」常见得多。
我们本来准备画一条全年热度曲线。做完发现不该画:把 10 个完整自然年 各自归一化后叠加,全年最热的月份也只有最冷月份的 1.36 倍(月度指数 86–117,100 = 全年均值)。 更关键的是,这个形状本身在逐年代变化——不同时期的子窗口互相打架, 分歧比信号还大。给你一条平滑好看的曲线,是在把噪声当规律卖。
| 窗口 | 1月 | 2月 | 3月 | 4月 | 5月 | 6月 | 7月 | 8月 | 9月 | 10月 | 11月 | 12月 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2016–2019 | 129 | 72 | 88 | 82 | 91 | 87 | 89 | 131 | 109 | 82 | 115 | 125 |
| 2020–2022 | 103 | 112 | 105 | 106 | 82 | 101 | 73 | 79 | 111 | 99 | 114 | 116 |
| 2023–2025 | 114 | 120 | 110 | 102 | 98 | 108 | 98 | 93 | 104 | 77 | 80 | 96 |
| 合并(10 年) | 117 | 98 | 100 | 95 | 90 | 98 | 87 | 104 | 108 | 86 | 104 | 113 |
怎么用:八月的指数从 131 掉到 79,十一月从 115 掉到 80——这说明「旺季」跟着客户结构走,不是行业铁律。 所以:赶节点带来的增量,小于把同一个活动的分发做扎实。 如果你的活动只能做一次,把力气花在触点和投放上,比花在挑日子上回报更高。
口径提醒:按活动的开始时间统计。实测 78.3% 的活动「开始月 = 创建月」, 真正提前排期的不到 4%——所以这条曲线更接近「运营在什么时候做活动」,而不是「活动被排在什么时候」。
粗看数据会得到一个很好卖的结论:有分享记录的活动,参与量中位数是没有分享记录的几十倍。 那是选择偏差——没人玩的活动自然也没人分享,这句话等于什么都没说。
去掉这个偏差之后再看:只取已经有真实受众(参与 ≥100 人)的 11,192 场活动,按「人均分享次数」分成四档—— 分享率越高的那一档,活动规模反而越小。
这是相关性,不是因果。这组数字不能读成「分享会让活动变小」, 更合理的解释是:大活动的量主要来自投放与触点(公众号推文、门店物料、 短信、社群分发),自然分享在其中的占比被稀释;而分享率高的,往往是靠熟人转发撑起来的小活动。
怎么用:如果你的目标是量级,先解决「从哪里来人」,再谈裂变机制; 把裂变当成唯一的增长来源,在这份数据里没有得到支持。
这一节只描述模板库——是我们按行业备货的结构,不是客户行业分布 (为什么不出客户行业分布,见下一节)。 只统计专属模板:标注 1–6 个行业的 175 个模板; 把 15 个行业全标满的通用模板剔除掉,否则它们会淹没每个行业里真正专属的那部分。
一个模板可以同时标注多个行业,所以各行业覆盖率相加大于 100%。 样本量不足 10 的行业标注已合并为「其他」,未单独展示。
一份数据报告的可信度,取决于它在没有数据的地方是否承认没有数据。以下四项是我们查过、 但决定不发布的:
账号上的行业字段 78% 为空,且填了的那部分描述的是「注册账号自己的行业」——其中很大一部分是代理商与技术公司替客户做活动。拿它出「客户行业分布」会是明确的误导,所以行业维度只出模板库的备货结构。
该计数器每次有人浏览模板详情页就随机自增,且被我们自己的巡检程序放大,与真实使用量无关。它是最容易被误用成「热度」的字段,因此本报告一个数字都不引用它。
属于商业敏感信息,且与这一页「给运营提供参照」的目的无关。所有随时间变化的指标都只发布占比与指数,不发布绝对量。
参与人数计数器在 2019 年 11 月之前不可信——那之前存在大量「有人玩但参与人数记为 0」的自相矛盾记录。所以所有参与量相关的指标都从 2020-01 起算,而不是从平台最早的数据起算。
| 指标 | 口径 | 统计窗口 | 样本量 | 更新频率 |
|---|---|---|---|---|
| 玩法分布(需求侧) | 状态为已发布/已结束的客户活动,按其所用模板归类;归类规则为标签优先、类型兜底 | 2016-03 – 2026-08 | 115,547 | 季度 |
| 玩法分布(供给侧) | 公开活动模板目录整池,同一套归类规则 | 2026-08-22 | 266 | 每次发布 |
| 参与量级分布 | 单场活动的参与玩家数,分档占比;不出平均值 | 2020-01-01 起 | 51,637 | 季度 |
| 季节性指数 | 按活动开始月计数,每个完整自然年各自归一化后跨年平均 | 2016-01-01 起 · 10 个完整年 | 115,434 | 年度 |
| 分享强度 × 参与量 | 仅参与≥100 人的活动,按人均分享次数四等分,取各档参与量中位数;相关性描述,非因果 | 2020-01-01 起 | 11,192 | 季度 |
| 行业 × 玩法(供给侧) | 模板库中标注 1–6 个行业的专属模板;行业为多值标注,覆盖率合计大于 100% | 2026-08-22 | 175 | 每次发布 |
本页及 /data-report.json 的数据以 知识共享署名 4.0(CC BY 4.0)的条件公开,任何人可以自由地:
唯一的条件是署名:注明来源「24好玩开放数据报告」并给出本页地址 https://www.24haowan.com/data-report,同时指明是否作了修改。