数据埋点不能上线前才想：选择率、退出点和结局怎样记录

互动影游的埋点应在节点数据定型时设计，因为真正有用的数据必须知道玩家看见了什么、可以选什么、最终选了什么，以及技术上是否成功播放。只记录按钮点击会把未曝光、误触、退出和加载失败混在一起，得出错误的剧情判断。

先列产品问题：玩家在哪一章离开？某个选项没人选是因为不吸引，还是根本没出现？结局稀少是条件太难还是玩家不愿走？复玩者在寻找什么？每个问题对应指标和最少事件，不要把所有界面操作都上传。

数据不能回答“为什么”的全部。定量发现异常后，再结合可用性观察、评论和访谈解释。低选择率可能是文案、角色价值观或前置状态造成，不能自动判定为坏分支。

至少记录会话开始与结束、节点进入、媒体准备成功或失败、选项曝光、选择提交、状态里程碑、结局到达和重玩开始。公共字段包括匿名会话 ID、游戏版本、平台、语言、节点或选项 ID、时间与必要的实验版本。

选项曝光事件同时记录本次可见选项集合和计时规则；提交事件记录选择 ID、从曝光到提交的时长、是否超时。这样选择率的分母是“真正看见该选项的人”，不是所有玩家。

程序无法可靠收到每次关闭通知，尤其崩溃、断电或移动端被系统清理时。可在节点进入与关键播放阶段记录轻量心跳，下次启动再判断上次会话未正常结束。区分主动退出、后台超时、崩溃和正常结束。

退出点不只记录节点，还记录播放进度、是否正在等待选择、最近一次加载耗时和是否重复观看。玩家在同一视频 90% 离开，可能是内容问题；在 0% 离开且加载失败，更像技术问题。

结局事件记录主要结局 ID、尾声变体、关键状态摘要、总时长、重试次数和是否使用跳过。不要上传完整逐帧行为或自由文本，只保留回答设计问题所需字段。

为关键选择建立路径漏斗，而不是保存每一种完整排列。完整路径组合会迅速稀疏，也增加隐私和分析负担。通常章节入口、关键节点与结局足以定位问题。

事件字典包括名称、触发时机、字段类型、示例、负责人、用途、保留期和版本。事件名保持稳定，字段新增向后兼容；改变含义时建立新版本，不能悄悄复用旧字段。

每个事件只由一个系统触发。若按钮、节点管理器和播放器都发送“选择完成”，数据会重复。提交成功后生成唯一事件 ID，离线重传也能去重。

只收集必要信息，避免姓名、原始设备标识或玩家输入内容。说明收集目的、保留时间与退出方式；适用地区的具体法律要求应由合格人员审查。未同意分析时，游戏核心流程仍应可运行。

开发日志与分析数据分开。前者可在本地包含详细状态帮助排错，后者只上传聚合所需字段。测试账号与正式玩家也要标记隔离，避免污染上线数据。

为每条事件写测试用例：何时应出现、何时不应出现、字段是否合法。跑一条已知路径，手算预期事件，再与后台逐条对比。测试离线、重连、重复提交、跨版本和系统时间异常。

最后制作一张最小仪表盘：章节到达率、节点退出率、选项曝光与选择率、各结局人数、首轮完成时长、复玩启动率、媒体失败率。若某个图表不能支持决策，就不要为了“数据丰富”而长期维护。

每个指标旁边补一句“它不能说明什么”。完成率下降不能单独证明剧情变差，复玩率高也可能来自存档故障或成就要求。发布改动前保留版本分组，避免把新玩家构成变化误判为内容效果。样本很小时展示人数与区间，不用小数点制造确定感。

数据评审要形成动作：继续观察、深入研究、修复技术或调整内容，并指定负责人和复查日期。没有动作的问题不值得持续收集更多字段。

下一步：选三个最重要的设计问题，为每个问题写指标公式、所需事件和决策阈值；随后让测试人员用一条固定路径核对原始事件，确认分母没有错。