发送时机需考虑时区与作息
别名: 按时区发送 · 作息敏感推送 · circadian send
概念解释
推送的时钟必须是接收者当地的时区和作息，不是服务器所在地，也不是运营排期表。同一条「早上推送」，对东京和纽约不是同一个早上；对上夜班的人，当地 9 点也可能是睡眠中段。时机错误会把一条白天可忍受的到达变成一次把人从睡眠里拽起来的事件，从而加速整通道关闭。
这条是发送侧怎么选钟点。它不是产品里的「静默时段」功能（那段要讨论谁能穿透、上限怎么按类算），也不把「别在子任务中间插」当成作息问题。
机制
睡眠和深度休息时，唤醒的代价远高于日间扫一眼。声音和亮屏会切睡眠阶段，事后对发送者的情绪标签是侵犯而不是提醒。运营常用单一时区批量发送，是因为调度便宜；代价由每个当地的人承担。设备时区是最粗的可用信号，最近解锁、充电、勿扰状态能补上作息与时区的差：时区对了，上夜班的人仍会在「当地早晨」被叫起来。
「工作时间发送」同样不能写死成 9–18。跨时区团队、周末值班、旅行中的设备，时钟在变。发送侧若缓存了过期时区，会在人落地后的第一个夜里用旧城市的白天去响。
怎么研究
把同一内容分到「发送方上班时间」「设备时区的日间」「按最近活跃窗口」三组，比较夜间到达占比、随后的总关、以及被标成「打扰睡觉」的投诉。
自变量：时钟源（服务器 / 设备时区 / 活跃窗口）、是否避开当地睡眠核心时段、旅行后时区更新延迟。 因变量：当地 23:00–7:00 的到达份额、那些到达之后的关闭率、次日打开是否延迟。
实验室被试白天来做任务，测不到被叫醒。需要日记、可穿戴睡眠窗口或至少设备的勿扰/充电钟点。不要用全局打开率选出发送高峰——高峰可能是另一时区的人还醒着，对本时区睡眠者是低谷。
边界
航班、安全、提醒类闹钟必须能在睡眠中响，那是用户自己定的钟点，不是运营窗口。用户明确要「货物一出库就推」，时效优先于作息，但仍应默认无声；出声需要更高后果。无法取得时区时（网页推送、时区被关），应退到更保守的窗口或只走静默，而不是按 UTC 硬发。公共信息屏、仓储扫码枪没有「作息」，这条不适用。
怎么落地
- 发送前读取设备时区，把运营窗口翻译成本地日间；禁止用单一总部时钟覆盖全量用户。
- 用最近若干天的解锁/充电分布估计睡眠核心，核心内默认不发可推迟类型。
- 时区变化后的头一个本地夜里按新时区约束，不要用旧偏移。
- 验证：抽样已发送记录，换算成每个用户当地时间，画出 24 小时到达直方图。若在当地睡眠核心仍有高峰，改时钟源后再看总关是否下降，而不是只把文案改成「早安」。