游客身份的数据留存期限需要明确告知
别名: 游客过期 · anonymous data TTL · 未登录草稿保留
概念解释
游客桶不能无限期充当免费账号。留存期限是这份临时数据会被清掉的时间或条件（N 天未活动、卸载、清站点数据、服务端匿名令牌到期）。明确告知指人在产生第一份游客数据时就能看见期限，并在临近清除时再看到一次，而不是消失当天才发现空白。这条只管能留多久、怎么说，不管注册后怎么合并，也不管哪些功能根本不给游客。
机制
没有账号就没有稳定的通知通道，期限只能写在当下界面和本地。人把游客草稿当成「已经保存在云端」，离开几天再回来，桶已被策略清掉，信任破裂发生在产品曾经鼓励他们先用的路径上。不告知的清除会被读成丢失故障。告知要同时覆盖本地与服务端：只说「关掉浏览器会丢」却把匿名令牌在服务器留三十天，或反过来只清服务器、本地还躺着过期数据，都会让预期错位。期限还影响隐私承诺：声称游客不建档，却把匿名行为日志留得很长，留存政策与营销句冲突。
怎么研究
让人在游客态产生数据，间隔超过期限后再回访，比较有无事前告知、有无到期前提醒，看预期与实际是否一致。
自变量：期限是否在首次写入时可见、是否有到期倒计时或横幅、清除后是否解释「游客数据已到期」而不是空白。 因变量：回访时对丢失的归因（到期 vs 故障）、因不知情丢失而投诉的比例、看到期限后选择注册以保留的比例。
实验室很难真等 N 天，可用缩短的 TTL。不要把「到期后注册转化」当唯一成功——那可能是胁迫。成功标准是归因正确：人能说出为什么没了，以及还有没有机会导出或注册挽救。
边界
仅内存的游客（关掉即没）期限是会话长度，告知应在第一次写入时说「关闭应用将丢失」，不要假装有天数。法律要求更短或更长的匿名日志留存时，对用户说的期限必须覆盖他们能看见的那层数据，日志另遵合规不必写进同一句，但不可声称「我们什么都不留」。清站点数据、换浏览器、拒绝 cookie，都会提前结束期限，告知要提这些用户侧动作。已经注册的账号数据不走游客 TTL。
怎么落地
- 在游客第一次保存或加购时用一句可见文案给出期限（「游客草稿保留 N 天或直到清除本站数据」），设置里也可查到。
- 临近到期用应用内横幅提醒；到期清除后的空状态写明原因，并给出注册后不可复活已清数据的诚实说明。
- 本地与服务端匿名令牌使用同一可见期限，到期两边一起清。
- 验证：把 TTL 收到可观察窗口，首次写入时人应能复述期限；到期后空状态不得像故障。换浏览器或清站点数据应提前结束，且界面不承诺数据仍在。抽查服务端匿名记录是否在所说日期后不可再用来重建工作区。