H5.10.4frequency cap reset period is visible设计研究
频次上限的重置周期需要向用户透明
别名: 配额重置 · 每日上限何时清零 · cap reset clock
概念解释
「每天 5 条」没有说明哪一天、何时清零。自然日当地午夜、滚动 24 小时、UTC 零点、每周一，四种时钟会让同一句文案变成四种体验：有人觉得今天已经额满，过一会儿又来；有人等到午夜以为会停，结果按滚动窗口马上又开始。重置周期必须写进人能看见的地方，并且与真实计数器一致。
这条只管配额的时钟是否可理解。它不规定每类该不该独立限额，也不规定静默时段谁能穿透。
机制
人用上限做预期：「再来两条就停」「明天才会再响」。预期依赖一个共享的时间原点。原点藏在服务器里时，预期无法形成，到达被读成系统说话不算数。滚动窗口尤其反直觉：最后一条刚到，窗口右沿一滑又空出一个名额，人感觉「不是说满了吗」。自然日更符合口语里的「每天」，但旅行跨日会让一天被切成两段。
不透明还会被当成欺骗。营销在 UTC 零点重置，对北美用户是傍晚又开始一轮，很像故意钻「每天」的空子——即使计数器按字面是对的。
怎么研究
给同一上限配不同重置时钟，问人「现在还能不能来、还要等多久」，再对照真实下一条到达。
自变量：重置是当地日切、滚动窗口还是 UTC；是否在设置里写出下一次重置时刻。 因变量：预期与实际的差、把再到达判为「说话不算」的比例、为了停掉而关类或关权限的比例。
实验室问「你觉得每天是什么意思」只能得到语言直觉，要配一次真实的额满后再到达。不要用投诉量当唯一指标——很多人不会投诉，只是把通道关掉。
边界
内部配额若不对用户承诺条数，就不必展示时钟；一旦文案或设置里出现了「每天 / 每周」，时钟就必须公开。按会话计费的即时消息通常没有「每天 N 条」这种产品承诺，硬加重置说明会制造不存在的限额。法律要求的送达计数器与营销配额不要共用一句「今日剩余」。
怎么落地
- 凡是向用户承诺了上限，就写清重置规则：当地自然日、滚动时长、或具体星期，并显示下一次清零的本地时刻。
- 计数器与文案必须用同一时钟；禁止文案写「每天」计数却按 UTC。
- 额满时在该类的下一张尝试上说明「已达上限，将在 HH:MM 后恢复」，而不是静默丢弃让人猜。
- 验证：让人把某类用到上限，问「下一条什么时候会来」。答案对不上真实计数器，就改文案或改时钟，直到两者一致。旅行跨日后重复一次，看本地日切是否还成立。