H2.03.2progressive onboarding frequency budget设计
引导频次需要全局预算
别名: 引导配额 · 适时介绍上限 · coaching cadence · intro budget
概念解释
功能按「首次相关」开口之后，开口次数仍会在同一产品里叠加。全局预算是给整条渐进引导设一个频次上限：每个会话、每一天、每一周，自动介绍加起来不得超过这个数。没有上限，每个功能各自判断「现在相关」，用户会在一上午连吃三条适时课。这条管的是单产品里适时介绍的节奏，不是提示被习惯化之后整体失效的心理，也不是多个团队抢同一配额时怎么排序。
机制
「相关」在局部为真，在全局会冲突。筛选第一次出现、分享第一次出现、快捷键第一次出现，可以落在同一小时甚至同一任务链里。每句单独看都正当，串起来就变成另一场前置课，只是改用情境触发。人用来消化打断的恢复时间是共享资源，不按功能分区。预算把这资源收成可计数的名额：用掉一次，其它即便也相关，也要等下一次名额。名额按会话清零还是按自然日清零，决定的是密集工作日会不会被教到停。预算还必须是全局的——按页面、按功能各设上限，等于没有上限，因为人经历的是时间，不是页面账号。适时策略若只优化「何时相关」而不优化「相关的是否还轮得到说」，会在活跃用户身上反而教得更勤，因为他们触发的相关点更多。
边界
错误恢复和阻断性失败上的一句（「刚才没存上，点这里重试」）不是功能介绍，不应记入教学预算，否则故障日会被教到哑火。用户主动打开的教程、帮助中心不占自动预算。监管必须看见的说明按法定频次走，不能用教学预算挡掉。新安装后的第一个会话可以单独给稍宽的额度，但宽额必须写死条数，不能「第一周内相关的全说」。长期不活跃后回归的人触发点会突然变密，若预算按周算得太松，回归日会变成补课日。
怎么落地
- 为自动弹出的渐进介绍设产品级上限（例如每会话 1 次、每天至多 2 次），所有功能共用这一计数器，禁止各功能自己再设「相关就出」。
- 同一任务链里第二个相关点改为静默入口说明，不要连弹。
- 计数器按用户、按设备持久化；清零周期写进规则，并在内部看板上看每天实际打出的介绍次数。
- 验证：抽活跃用户一周的会话，数自动介绍出现的间隔。若两句之间不足以完成一个完整任务，或一天超过上限，就把触发改成排队到下一额度，而不是继续按相关点开火。