版更与活动节奏
这篇回答什么问题： 多久发一次版、每次发版该带什么、活动排在哪；以及「发版」这个动作在两个平台上各自还绑着什么免费的召回资源——哪几种顺手就做的排期会把它们白白浪费掉。
一、先分清：IAA 的版更不是「加内容」
内容型产品的版更逻辑很直白：加关卡、加角色、加剧情 → 用户有理由回来 → 留存涨。
IAA 不能照搬，因为收入只有三个乘数：
日收入 = DAU × IPU × eCPM / 1000
版更对 DAU 是间接作用（要经过留存），对 IPU 是直接作用（改广告位、改触发节奏）。而 IPU 一动，eCPM 也跟着动——复盘范例那张分类型表就是证据：插屏 +1.5 次，同时激励视频 −0.3 次、Banner −0.4 次，加权 eCPM 从 27.8 掉到 22.7。
你加进去的不是一个广告位，是一组新的广告占比。 所以 IAA 的版更很少是「加东西」，多半是「改结构」。改结构的风险不是做不出来，是你根本判断不了它有没有用——如果观测窗口没走完就又发了一版。
1.1 版更间隔的下限：14 天
这个数字是从结论窗口倒推的，不是拍脑袋：
| 你要的结论 | 最短观测天数 | 依据 |
|---|---|---|
| 收入有没有变好 | 7 | 曝光当天产生，7 天覆盖工作日与周末两种流量结构 |
| 7 日留存有没有变差 | 7 | 新用户满 7 天才算得出 7 留 |
| 分群之后有没有差异 | 14 | 分群后单组样本变小，波动要两周才压得下去（C，判断） |
| 30 日 LTV | 30 | 通常等不到，改用 7 日与 14 日外推 |
一次版更至少留 14 天。 7 天发一版不是「迭代快」，是永远在看没走完的窗口；而没走完的窗口系统性偏乐观——第 3 天看到的收入上升里，还包含没被留存下降抵消掉的那部分。
每周发版的团队，通常在第 6 周得出一个结论：「我们试了 6 个方向，都没用。」
实际情况是6 次实验互相污染。第 3 版的收入上升，可能来自第 2 版改的广告位到第 3 版才进入稳态；第 4 版的留存下降，可能来自第 3 版没改完的路径。这种数据看起来很丰富，信息量接近零。
版更次数不是资产，可归因的版更次数才是。
1.2 发版日是风险日，不是增长日
发版当天同时发生三件事，全是负向的：
- 版本冻结。提审到发布之间线上代码不可动（微信审核正常 1 个自然日，抖音首发要 QA 回归 1–3 个工作日）
- 数据不可比。灰度 / 分阶段期间用户被切成两个版本，后台报表默认混在一起（见 2.3）
- 崩溃率上升。任何新版本都有一小段崩溃高峰，而崩溃导致的卸载不可逆
由此得出一条硬规矩：发版和加买量预算，永不同周。
这一条不是为了技术稳定，是为了归因。复盘模板 基本信息里那栏「同期还有什么变了」就是为这件事留的位置。如果版更和加预算撞在同一周，事后永远分不清收入变化是哪一边带来的，而这一次的结论会被后面所有决策继承。
1.3 发版窗口怎么选
| 时间 | 适合发版 | 原因 |
|---|---|---|
| 周一至周三 | ✅ 首选 | 出问题还有 4 个工作日可以修、可以再提审 |
| 周四 | ⚠️ 勉强 | 出问题只剩 1 天，修复要跨周末 |
| 周五 | ❌ | 周末是流量高峰，也是最没人值班的时候 |
| 节假日前一天 | ❌ | 审核排期不确定，节假日又是流量高峰，双重风险 |
二、两个平台的发版机制：差在「反悔之后手上还有没有东西」
| 项目 | 微信小游戏 | 抖音小游戏 |
|---|---|---|
| 审核时长 | 正常 1 个自然日 | 首次上线前需 QA 回归 1–3 个工作日（更新版本未写明） |
| 灰度叫什么 | 分阶段发布 | 灰度发布 |
| 灰度期长度 | 15 天内自定义比例 | 未写上限，满 15 天自动全量 |
| 比例能否调低 | 只能递增 | 只可增加不可减少 |
| 能否撤销 | 可以撤销，全部用户回退到上一个全量版本 | 可以撤销，但线上灰度版本被撤掉，需重新提交测试版本 |
| 撤销后有没有备胎 | 有——上一个全量版本仍在服务 | 没有——必须立刻重提，期间无新版本在线 |
| 到期不操作 | 平台在第 15 天自动全量 | 满 15 天自动全量 |
| 首版限制 | 第一个版本必须全量发布 | 首次上线前要多端 QA 回归 |
| 版本号 | — | 任一宿主未通过要重提，下次版本号必须大于当前 |
| 提审勾选项 | — | 需要灰度时不要勾「自动发布」，否则审核通过即全量 |
来源与等级见第十节。微信那列主要依据小程序口径的分阶段发布规则（B 级），小游戏是否完全一致列为待核实。
2.1 抖音的比例是单向的，但「撤销」是另一回事
核实前本文判断「抖音灰度不可撤销」，依据只有提审指引页的「只可增加不可减少」。查到专页后发现：比例单向 ≠ 不能撤销，这是两件事。
改判来源：游戏灰度（采集：2026-10-28），原文两句：
- 灰度比例只可递增，不可减少，灰度满 15 天后将自动全量到线上。
- 可以发布灰度之后撤销灰度，此时撤销灰度，会直接撤掉线上灰度版本，需要重新提交测试版本。
第二句是关键。抖音能撤销，但撤销的语义与微信完全不同。
两个平台都叫「撤销」，结果不是一回事：
| 微信 | 抖音 | |
|---|---|---|
| 能否撤销 | 能 | 能 |
| 撤销后用户拿到什么 | 上一个全量版本（有备胎） | 没有备胎——线上灰度版本被撤掉，必须重新提交测试版本 |
| 撤销的代价 | 这一版改动作废，回到旧版 | 线上进入「无新版本」状态，得重走提审 + 审核 |
所以两个平台的真实差异不在「能不能撤」，而在撤销之后有没有东西可用。
- 微信撤销是「回退」，你仍然有一个功能完整的旧版本在服务用户，只是新功能没了。
- 抖音撤销是「裸奔」——灰度撤掉后，那个版本就不在线上了，你需要立刻重提一个，而重提要过审核。撤销和重提之间的窗口，是没有新版可用的。
原先因为「不能撤销」而定的规则——起点压到 5%–10%、自测更严——依然成立，但理由换了：不是怕撤不回来，是怕撤回来之后手上没东西。
真正该做的是提前准备一个可回滚的全量版本：上线前确认线上那个版本是健康且可用的。否则「撤销」这个动作只是把问题从「坏版本在跑」换成「没版本在跑」。
另外一条仍然硬的约束没变：灰度比例只能往上走。所以「先小跑到 5%，观察没问题再放到 20%」这个路径成立；「先放 20%，不对再退回 5%」不成立，只能整段撤销。
所以两个平台的灰度策略不该一样：
| 微信 | 抖音 | |
|---|---|---|
| 灰度起点 | 10%–20% 可以接受 | 5%–10%，能再低就再低 |
| 自测标准 | 常规 | 需要更严——撤销后没有备胎 |
| 灰度期发现问题的动作 | 撤销，回退到上一全量版 | 撤销，但必须立刻重提才有版本在线 |
| 排期要多留的时间 | 无 | 一次提审 + 审核，不是零 |
撤销分阶段发布后，所有用户会回到上一个全量发布的版本。如果上一版已经是很久以前的，等于把这段时间的改动全部作废——包括那些已经验证有效的。
所以「可撤销」不等于「敢乱发」。它只保证你不会一直暴露在坏版本里。
2.2 抖音的两条时间线会打架
抖音从 2026-04-20 起，提审会自动上线到所有已接入的合作 App，QA 默认做多端回归。这带来一个不明显的后果：
审核时长从「一个版本的时间」变成了「最慢那个宿主的时间」。 只要有任一宿主没通过，整包退回重提，而重提的版本号还必须大于当前版本号。如果连续两次都卡在同一个宿主上，版本号会被推高两格，而线上什么都没变。
排期时要按最慢宿主留缓冲，不要按「1–3 个工作日」的中间值排。
2.3 灰度期的数据是脏的，必须自己分版
两个平台在灰度 / 分阶段期间，后台报表都会把灰度版本和线上版本混在一起。抖音的文档写得很直白：「线上版本」的数据包含了「灰度版本」的数据，只有切到「灰度版本」tab 才能看灰度那部分。
微信这边更麻烦：分阶段发布是同一个线上版本按比例下发，后台没有「分阶段版本」这个独立维度。
所以埋点必须自己带版本号。 广告接入实现 里那张五事件埋点表，至少要再加两个字段：
| 字段 | 取值 | 用途 |
|---|---|---|
app_version | 客户端上报的版本号 | 灰度期分版对比，也是复盘时唯一能验证「同期改了什么」的证据 |
release_channel | 灰度 / 全量 / 审核体验 | 区分灰度用户与正常用户 |
没有这两个字段，灰度期间的所有数据只能看崩溃率，不能看收入，也不能看留存——因为你不知道分子分母里各混了多少比例的新版本用户。
三、微信的「游戏更新提醒」：每月 4 次免费召回，开关在提审表单里
这一节是全文最值钱的部分。微信有一条完全免费、面向已订阅用户的全量推送通道，它的触发条件是「你提审了一个新版本」。 也就是说：发版这个动作，除了改产品，还附带一次召回。
但它有一整套硬约束，而这些约束直接决定了版更节奏能排多密。
3.1 它怎么工作
用户在小游戏里订阅（SYS_MSG_TYPE_WHATS_NEW，基础库 v2.32.1 起支持，低版本调用会报错），之后：
- 你每次提审时，在提审页配置「更新内容」，从限定词库中选，每次最多 3 个
- 版本全量发布后，平台在审核通过并生效后 24 小时内自动下发服务通知
- 用户从「服务通知」点进来，场景值 1014，可以单独归因
关键的一句是官方原文：用户的订阅是持续生效的，无需重复订阅。 这意味着订阅池是一次性积累、长期复用的资产——和一次性订阅消息完全不同。
3.2 五条硬规则，每一条都能毁掉一次召回
| 规则 | 原文要点 | 后果 |
|---|---|---|
| 配额 | 一个月至多提交 4 次，提交 1 次扣 1 次，与是否通过审核无关 | 第 5 次没有；写错也扣 |
| 必须全量 | 配置版本需为线上唯一版本且覆盖用户比例 100% | 灰度期间配不了 |
| 不可修改 | 审核不通过的内容不支持修改，该版本也不允许再次提交 | 一次写错，这个版本的召回永久归零 |
| 改版本即失效 | 申请期间变更游戏版本（含发布或撤回灰度、发布或撤回全量）会导致更新提醒失效 | 全量后又发灰度 = 白扣一次配额 |
| 20:00 线 | 20:00 前审核通过当天推送，之后次日推送 | 想赶周末高峰，必须在 20:00 前拿到通过 |
另外还有一条容易踩的：1 个线上版本只能配置 1 条更新提醒，且内容不允许与之前配置的高度重合。
这是最常见的一种浪费。顺序是：全量发布 → 配好更新提醒 → 发现一个小问题 → 发灰度修 → 更新提醒失效，配额已经扣掉。
正确的处理是：小问题等下一个版本。除非它影响收入或合规（见 6.3）。在这套机制下，「顺手修一下」的成本不是一次发版，是一次召回。
3.3 所以发版顺序是固定的
提交审核（填好 3 个词）
↓
灰度 / 分阶段（此时不能配更新提醒）
↓
全量发布
↓
配更新提醒（如走后台入口）
↓
平台 24 小时内下发服务通知
↓
此后 14 天内不要再动版本
灰度和更新提醒是互斥的。 这句话要贴在排期表上。想「既灰度又召回」在现有机制下做不到——你得二选一，或者把这两件事排到不同版本上。
3.4 那 18 个词是文案，不是标签
官方词库一共 18 个：
优化性能、修复 bug、新英雄上线、新皮肤上线、新增道具、新增场景、新增关卡、周年庆活动开启、圣诞活动开启、新年活动开启、春节活动开启、端午活动开启、中秋活动开启、特殊节日开启、活动开启、推出新功能、推出新玩法、开启新赛季
它们是推送给用户看到的文案，不是内部归档标签。 用户看到的是一句「XX 游戏：新增关卡」，他决定点不点，靠的就是这几个字。
由此有两个判断（C，未验证，建议自己 A/B）：
- 「优化性能」「修复 bug」几乎肯定是点击率最低的两个词。 它们对用户没有信息量。可 18 个词里只有这两个能覆盖「这一版没有新内容」的情况——这就是为什么「没有新内容的版本」不该配更新提醒，纯浪费配额。
- 平台会按「订阅用户近期活跃情况、历史下发点击率」动态调整下发比例。 如果这个「历史」包含该游戏自己的历史，那连续几次低点击会压低后续推送量——于是浪费一次配额不是损失一次，是损失后面几次。
3.5 加圈 = 订阅，零成本扩大订阅池
官方文档写明：用户在游戏圈选择「加圈」，等同于订阅游戏更新提醒，可用 wx.getGameClubData 查状态。
这是一个纯白送的动作：游戏圈本身有内容运营价值（版本公告、攻略、玩家晒图），而「加圈」这个动作顺带把用户加进了推送池。接入游戏圈的成本远低于任何买量手段，而它带来的推送资格是长期有效的。
新版本发布时在游戏圈发公告，本身也是内容——这条链路上平台不收任何费用。
3.6 抖音的对应物：能订阅，但管得更细
抖音也有订阅消息，但版本更新提醒在抖音上是单独一类，需要单独订阅：官方明确「版本更新提醒需要单独订阅，与其他模板混合会产生 1005 错误」。也就是说，你不能把「版本更新」塞进一次「体力回满」的订阅弹窗里一起要。
另外两条要知道：
- 长期订阅有频次上限，一般每月每用户 8 条以内（小程序口径，B 级）
- 有清退机制：平台监测订阅率、退订率、点击率、投诉率，不达标会清退订阅消息能力——这是一项会被回收的权限，不是开通即永久
所以抖音的推送策略要比微信更保守：微信那边是「订阅一次持续生效」，抖音这边是「每次都要重新要，而且要被考核」。
四、抖音的「必接」与「重点推荐」：差的是钱，不是体验
抖音开发者工具在上传时会做审核预检，检测代码里有没有调用相应能力。两类能力的后果完全不同：
| 类型 | 能力 | 未接入的后果 |
|---|---|---|
| 必接 | 侧边栏复访 | 版本上传失败（不是拒审，是包传不上去） |
| 重点推荐 | 添加至桌面、订阅消息、支付、广告 | 不拦截上传，但会提示 |
重点推荐那栏有一句话要单独拎出来：
添加至桌面、订阅消息能力能提升游戏留存，建议开发者接入；且有计划或正在进行广告投放的游戏，只有接入这些能力后才能获得商业化广告金。
这条把「接不接订阅消息」从产品决策变成了财务决策。 不接，不是「少一个召回通道」，是买量的广告金拿不到——而广告金在买量测算里是要按 50%–70% 折现算进 ROI 的。
自然量获取 里写侧边栏复访「未接入在首发和版本更新环节会有拒审风险」，依据是侧边栏技术指南。开发者工具文档的口径更硬：未接入会导致版本上传失败。
两者不冲突（预检会先拦住上传，根本走不到审核），但「拒审」这个说法会让人以为「可以试试看」——实际上你连包都传不上去。
五、活动：在 IAA 里是「广告出口的重排」，不是新增收入
5.1 先算清楚活动的净增量
IAA 产品没有付费出口，活动奖励只能通过广告发放。所以活动的本质是：把分散在 30 天里的广告曝光，压缩到 7 天里。
它提高的是 IPU 的分布，不是总量。这意味着活动期的 IPU 峰值不等于增量，净增量必须把活动后的回落一起算。
一个验算（全部为假设值）：
| 数值 | |
|---|---|
| 30 天基线 IPU | 3.0 |
| 活动 7 天 IPU | 5.0 |
| 活动后 7 天 IPU | 2.4 |
| 表观增量 | (5.0 − 3.0) × 7 = +14 次/人 |
| 活动后回落 | (2.4 − 3.0) × 7 = −4.2 次/人 |
| 净增量 | +9.8 次/人 |
峰值增量 14 次，净增量 9.8 次——三成是借来的。 按 eCPM 30 元算：表观 0.42 元/人，真实 0.294 元/人，差 0.126 元/人。10 万 DAU 上就是 1.26 万元的「虚增收入」。
这和 复盘范例 里那个错误是同一个：只看活动期的曲线，一定会高估。
只截活动期的数据，等于只看借来的钱不看还的钱。活动结束后至少再跟 7 天，用「活动期 + 后 7 天」的合并均值去比基线。
如果后 7 天的 IPU 回不到基线（本例中从 3.0 掉到 2.4），说明活动把用户养刁了——他们学会了只在活动期玩。这类活动做一次亏一次，只是亏在两周后。
5.2 三种节奏，作用完全不同
| 类型 | 周期 | 真正的作用 | 主要风险 |
|---|---|---|---|
| 每日任务 / 签到 | 日 | 拉平 DAU 曲线，提高访问频次 | 容易变成「看广告领低保」，把 eCPM 拉低 |
| 赛季 / 段位 | 4–8 周 | 内生节奏，完全可控，适合有进度系统的产品 | 赛季末期疲劳，需要设计收尾钩子 |
| 节日活动 | 外生 | 借大盘流量，用户本来就在玩 | 全行业同时做，买量 CPI 上涨 |
选择依据不是「哪个热闹」，是你的留存曲线断在哪：
- 断在 D1 → 做每日任务（解决「明天为什么回来」）
- 断在 D7 → 做赛季（解决「这周为什么继续」）
- 断在 D30 → 做节日活动（解决「这个月为什么还留着」）
5.3 节假日：买量最贵、留存最好的窗口
这是 IAA 排期里最反直觉的一条。
节假日期间，所有厂商同时加预算，CPI 上涨；同时也是用户时长最充裕的时候，留存最好。两件事同时发生，于是：
- 纯自然量的产品：节假日是做活动的最佳窗口，一分钱不用多花，白拿时长红利
- 正在买量的产品：节假日是降档或停投的窗口。同样的钱买到更少的量，而现金周转里那个垫资水位一分不降
这条和「版更」叠在一起就有了完整策略：节假日发版 + 做活动，但不加预算。 版更的召回、活动的曝光、平台的大盘流量，三件事在同一个窗口里同时发生，成本只有开发工时。
节假日 CPI 具体上涨多少，官方没有公开数据，列为待核实。不要拿行业传闻当测算依据。
5.4 能用运营工具配的活动，不要为它发版
微信有「游戏运营工具」，配置活动后可以走「推广渠道 - 服务通知」下发，文案最多 20 个字符。
这条通道的价值在于：它不需要提审新版本。 对比一下：
| 发版做活动 | 运营工具配活动 | |
|---|---|---|
| 审核 | 要（1 自然日 / 抖音 1–3 工作日） | 要，但只审活动内容 |
| 占更新提醒配额 | 占 | 不占 |
| 灰度风险 | 有 | 无（没有代码变更） |
| 能改吗 | 不能（发出去就定了） | 可以重配 |
所以纯数值调整的活动、限时加成、双倍奖励，一律走运营工具，不要发版。 发版只用于代码逻辑变更。
官方写明：用户每款游戏每天累计最多只能收到 1 条服务通知。
这意味着「版本更新推送」和「活动开始推送」如果排在同一天，只会发出 1 条，另一条被吃掉。排期时两者至少错开 1 天。
5.5 活动设计的三条合规约束
活动是合规红线最容易踩的地方，因为「活动要有奖励」和「奖励要靠广告」这两句话一叠加，很容易滑到违规：
- 不能把「看广告」设成关卡解锁的前置条件（抖音《小游戏行为规范》2.2.2）。活动关卡也一样——「看广告解锁活动关卡」就是这条。
- 不能以分享为参与条件（微信规范 5.1.4）。「分享给 3 位好友解锁」不是「效果差」，是违规。
- 不能做概率性奖励（微信规范 5.1.6）。转盘、抽奖类活动在微信侧有明确限制，纯 IAA 产品绕开它更省事。
六、一张能直接用的双周节奏表
把前面所有约束合起来，得到一个 14 天循环。每月发 2 次版，用掉 2 次更新提醒配额，留 2 次应急。
| 天 | 动作 | 为什么这么排 |
|---|---|---|
| D0（周一） | 全量发布，同时配更新提醒 | 周一发，出问题有 4 天修；20:00 前过审当天推 |
| D0–D1 | 只看崩溃率与启动失败率，不看收入 | 首日数据混着推送带来的异常流量，不能当基线 |
| D2 | 确认无异常，开始记收入基线 | — |
| D5（周五） | 用运营工具开一个 7 天活动 | 与版本推送错开 ≥1 天，避免「每天 1 条」被吃掉 |
| D7 | 看活动中期 IPU，不看留存 | 7 留还没满 |
| D11 | 活动结束，开始跟 7 天回落 | 净增量要算到这里才算完 |
| D14 | 下一版全量 | 正好 14 天，7 留与收入两个窗口都走完 |
6.1 什么时候该打破 14 天
只有三类，其余一律等窗口走完：
| 情况 | 处理 |
|---|---|
| 崩溃、启动失败、支付/广告不可用 | 立刻发，不排队，可以用加急审核（见 6.2） |
| 合规风险（被驳回、可能被处罚） | 立刻发 |
| 收入断崖（连续 3 天 IPU 或 eCPM 异常下跌且已排除数据问题） | 立刻排查，确认是版本问题才发 |
「觉得数据不好想赶紧改」不在这三类里。那种冲动 90% 会在窗口走完后自己消失。
6.2 加急审核：一个很多人不知道自己没有的权限
微信的加急审核要同时满足三个条件：
- 是更新版本（历史已有通过的版本），首版不能用
- 剩余加急次数大于 0：每季度 2 次，每年 1/4/7/10 月的 1 日刷新，过期不叠加
- 累计注册用户 > 5000
第 2 条和第 3 条加起来，得到一个不太舒服的结论：你最需要加急的时候（刚上线、用户还少、问题最多），恰恰是用不了的时候。
所以不要把它算进计划里。它是一个「已经跑起来的产品遇到突发问题时」的保险，不是新产品的提速工具。
6.3 一个小问题该不该等下一版：三问
| 问题 | 是 → 处理 |
|---|---|
| 影响收入吗（广告拉不到、发奖失败）？ | 发。这是钱 |
| 影响合规吗（可能被判违规）？ | 发。这是号 |
| 用户会因此流失吗（卡关、闪退）？ | 看比例：受影响用户超过 1% 就发，低于 1% 等下一版 |
三个都不是 → 等。等不是懒，是保护下一次召回。
七、发版前 12 项自查
| # | 检查项 | 不做会怎样 |
|---|---|---|
| 1 | 埋点已带 app_version 与 release_channel | 灰度期数据全废，只能看崩溃率 |
| 2 | 灰度比例与「出问题怎么办」已写下来 | 抖音撤销后没有备胎版本，必须立刻重提，排期要留一次审核时间 |
| 3 | 抖音提审没有勾「自动发布」 | 审核通过即全量，灰度计划作废 |
| 4 | 更新提醒文案已定稿（不能改、不能重提） | 一次写错，这个版本的召回归零 |
| 5 | 更新提醒选的词与上一版不「高度重合」 | 审核不过，且该版本不能再提交 |
| 6 | 版本号大于当前线上版本 | 抖音强制要求，卡住就要重推版本号 |
| 7 | 本期没有同时加买量预算 | 事后无法归因，结论污染后续所有决策 |
| 8 | 发版时间在周一至周三 | 周五发版 = 周末无人修 + 撞流量高峰 |
| 9 | 版本推送与活动推送错开 ≥1 天 | 每天只有 1 条，另一条被吃掉 |
| 10 | 崩溃率看板已就绪，发版后 2 小时内能看 | 发现太晚，卸载已经发生 |
| 11 | 新增的信息收集已同步更新隐私指引与适龄提示 | 提审被打回，或上线后被要求整改 |
| 12 | 活动奖励有广告出口，且不触发 2.2.2 / 5.1.4 / 5.1.6 | 不是「效果差」，是违规 |
八、关于「版更期回流 7 倍」这个数字
本站目标用户与需求 的来源表里有一条：「抖音社交互动产品次留 +20%、版更期回流 7 倍」，出自《2026 抖音小游戏行业白皮书》（抖音 × 极光月狐，B 级）。
用之前必须知道三件事：
- 它说的是「社交互动产品」，不是所有产品。 有社交/公会/好友系统的产品，版更有额外的社交召回路径，纯单机产品拿不到这个倍数。
- 口径不明。 白皮书没有说明「7 倍」的基数是日均回流、7 日回流还是活动期回流。「7 倍」可能是从 0.3% 到 2.1%，也可能是从 3% 到 21%——差一个量级。
- 站内这条引用的交叉指针已经失效（原文标「见 6.1」，而 6.1 是讲短视频替代的，没有这段内容）。
结论：这个数字只能当方向证据（版更确实带来回流），不能进任何测算。 想用它做预算，先用自己的数据算出「版更后 7 天回流人数 / 平时 7 天回流人数」，那个倍数才是你的。
九、待核实
- 微信「分阶段发布」是否完全适用于小游戏（现依据小程序口径的分阶段发布规则，B 级）
- 微信分阶段发布期间配置游戏更新提醒是否一定失效（后台文档写的是「申请期间更改游戏版本会导致失效」，「更改」是否包含发布或撤回灰度）
- 「游戏更新提醒」的两条入口（提审时选词库 / 后台「游戏更新提醒」配置 20 字简介）是互斥、叠加，还是一套能力的两个时期
- 每月 4 次配额是自然月还是滚动 30 天
- 「更新内容高度重合」的判定标准（未公开）
- 平台「动态调整下发比例」的细则：历史点击率是否包含该游戏自己的历史
- 抖音灰度是否真的没有撤销入口 → 已核实：可以撤销，但撤销会撤掉线上灰度版本、需重新提交测试版本（游戏灰度），见 2.1
- 抖音「接入重点推荐能力才能获得商业化广告金」的判定方式（代码预检 / 后台配置 / 数据侧）
- 节假日期间小游戏 CPI 的实际上涨幅度（无官方数据）
- 「版更期回流 7 倍」的原始统计口径（见第八节）
十、来源与等级
| 事实 | 内容 | 来源 | 采集日期 | 等级 |
|---|---|---|---|---|
| 微信版本审核时限 | 正常情况 1 个自然日；审核通过后需备案完成才能发布 | 版本审核 | 2026-10-28 | A |
| 微信加急审核条件 | 需为更新版本、每季度 2 次（1/4/7/10 月 1 日刷新、不叠加）、累计注册用户 > 5000 | 同上 | 2026-10-28 | A |
| 微信分阶段发布规则 | 15 天内自定义比例、可递增、可撤销回退上一全量版、15 天未操作自动全量、首个版本必须全量 | 分阶段发布功能介绍 | 2026-10-28 | B（小程序口径） |
| 灰度比例只能升 | 错误码 85082：当前发布比例需比之前设置的高 | 分阶段发布 API | 2026-10-28 | A（接口口径） |
| 游戏更新提醒（推送） | 订阅持续生效；SYS_MSG_TYPE_WHATS_NEW 基础库 2.32.1+；提审时从词库选 ≤3 个；需全量发布才有推送任务；24 小时内下发；按活跃度与历史点击率调整比例；每款游戏每天最多 1 条 | 游戏更新提醒（开发指引） | 2026-10-28 | A |
| 游戏更新提醒（后台配置） | 1 个线上版本 1 条；需线上唯一版本且覆盖 100%；每月 ≤4 次、提交即扣；审核不过不可修改且该版本不可重提；改版本（含灰度发布/撤回）导致失效；20:00 前过审当天推 | 游戏更新提醒（配置流程） | 2026-10-28 | B（微信服务市场社区文档） |
| 加圈 = 订阅 | 用户在游戏圈「加圈」等同于订阅游戏更新提醒，可用 wx.getGameClubData 查状态 | 同「游戏更新提醒（开发指引）」 | 2026-10-28 | A |
| 运营工具服务通知 | 活动配置后可走「推广渠道-服务通知」，文案 ≤20 字符 | 同上 | 2026-10-28 | A |
| 抖音提审时长 | 首次上线前需 QA 回归 1–3 个工作日；2026-04-20 起提审自动上线所有合作 App，任一宿主未过需重提且版本号须递增 | 版本提审指引 | 2026-10-28 | A |
| 抖音灰度规则 | 可调覆盖 App 与比例、只可增加不可减少、满 15 天自动全量；需灰度勿勾「自动发布」；线上版数据含灰度版 | 同上 | 2026-10-28 | A |
| 抖音灰度可撤销 | 「可以发布灰度之后撤销灰度，此时撤销灰度，会直接撤掉线上灰度版本，需要重新提交测试版本」 | 游戏灰度 | 2026-10-28 | A |
| 抖音必接与重点推荐 | 侧边栏复访未接入导致上传失败；添加至桌面/订阅消息未接入则投放中游戏拿不到商业化广告金 | 开发者工具·审核预检 | 2026-10-28 | A |
| 抖音版本更新提醒订阅 | 版本更新提醒需单独订阅，与其他模板混合报 1005 | tt.requestSubscribeMessage | 2026-10-28 | A |
| 抖音订阅消息清退 | 监测订阅率、退订率、点击率、投诉率，不达标清退；长期订阅一般 8 条/月/用户 | 订阅消息 2.0 | 2026-10-28 | B（小程序口径） |
| 版更期回流 7 倍 | 社交互动产品次留 +20%、版更期回流 7 倍（口径不明，不进测算） | 《2026 抖音小游戏行业白皮书》（抖音 × 极光月狐） | 2026-03-07 | B |
等级说明：A = 官方文档明确写出；B = 官方旧版页、相邻能力页或第三方转述，需复核；C = 经验判断，未经文档证实。
十一、变更记录
| 日期 | 变更 |
|---|---|
| 2026-10-28 | 建立初版。核心判断：IAA 的版更间隔下限由观测窗口（14 天）而非开发速度决定；微信「游戏更新提醒」是每月 4 次配额的免费召回通道，且与灰度互斥；活动是广告出口的重排而非新增收入 |
| 2026-10-28 | 更正：原判断「抖音灰度没有撤销入口」错误。查到专页后确认可以撤销，但撤销会撤掉线上灰度版本、需重新提交测试版本（无备胎）。2.1 整节重写，对比表增「撤销后有没有备胎」一行，自查表与关键词同步。原「单向闸门」表述改为「比例单向」，因为这两件事被混为一谈了 |
相关文档： 自然量获取（订阅消息与侧边栏是获量还是召回）· 买量测算（发版与加预算不能同周）· 复盘模板（同期改了什么，必须写下来）· 广告位设计（活动期的 IPU 峰值不是增量）· 合规红线（活动设计的三条硬约束）· 现金周转（节假日为什么该降预算）