游客模式让用户在注册前体验核心功能
别名: 匿名使用 · guest checkout identity · 未登录可用
概念解释
游客模式是产品承认的一种临时身份：没有邮箱密码，但有一份仅存在于设备或短命服务端的工作区，人可以真正做核心动作（编辑、加购、算一次、听完一首），而不是只能看营销页。它和「把注册墙往后挪、人其实没有身份」不同——游客是一种身份，有自己的数据桶。这条谈这种模式为什么存在、核心功能指什么。数据如何在注册后合并、能留多久、哪些功能故意不做，分属同组其它条目。注册表有多长、墙出现在第几步，是注册摩擦，不是游客身份。
机制
核心功能往往在人还没决定开户时就要被验证。若未登录只能浏览外壳，体验到的不是产品，是说明书。游客身份让产品在本地（或匿名令牌下）接受写入，价值发生在注册之前。它比单纯推迟注册表更重：系统必须能区分「这台设备上的这份工作」和「尚未存在的账号」，并在人离开时决定这份工作怎么办。没有游客桶，所谓先体验只能是只读；有游客桶，体验包括产生结果。成本是状态机变复杂：同一功能要能在游客与登录下跑，权限模型不能把「有账号」当成唯一开关。
怎么研究
比较「未登录只读」「未登录可写的游客身份」「必须先注册」，看核心动作完成率与后续开户。
自变量：未登录是否可写入、写入存在哪里（仅内存、本地持久、匿名服务端）、核心动作清单。 因变量：未注册完成核心动作的比例、之后开户的比例、因不能写入而离开的比例。
实验室要求「请试用」会抬高游客使用。真实漏斗要把「完成了游客动作」和「创建了账号」分成两个成功。不要把游客完成率写成延迟注册的转化数字——没有身份桶的延迟注册测的是另一件事。
边界
监管要求实名才能提供的核心动作（支付结算、处方）不能放进游客；游客只能做到动作之前的浏览与配置。强协作产品（文档必须有可分享的稳定 URL）很难在纯本地游客下演示核心，除非给匿名文档一个临时链。已经登录的人被踢进游客是故障。游戏或工具若核心就是云进度，游客只能覆盖单局，需在模式名称上说清。
怎么落地
- 列出未登录也必须能做完的核心动作，为它们建立游客工作区，而不是只打开只读演示。
- 在界面标明当前是游客，避免人以为已经有账号；需要记住结果时再请开户，而不是一进门就请。
- 游客可写的范围写进功能开关，登录态与游客态共用同一套编辑器，不要做两个互相不像的产品。
- 验证：冷启动不注册，走完声明的核心动作，应得到可感知的结果（草稿、车、计算结果）。再找未参与设计的人问「你现在有账号吗」，应回答没有。若核心动作仍被登录墙挡住，游客模式未成立。