事件设计、漏斗与数据质量

级别：首作必学。 埋点要回答决策问题。先写出要知道什么，再选择事件，避免把所有触摸都上传。

翻牌项目的最小事件

事件	触发时机	关键字段
load_result	资源加载成功或失败	阶段、耗时、错误分类
round_start	状态初始化并允许操作	局 ID、关卡、配置版本
first_valid_flip	本局第一次有效翻牌	距开始耗时、局 ID
round_end	首次进入胜负终态	结果、有效尝试数、剩余回合
retry	玩家确认重开	上一局 ID、新局 ID、来源

客户端版本、平台、会话和事件版本作为公共字段。需要可靠去重时增加 event_id；局内事件按业务规则使用唯一键，避免结算界面打开多次导致重复结果。

先在本地看见数据

首版可在开发日志输出结构化事件，确认顺序和字段，再接采集端。round_start 应出现在资源就绪之后，round_end 应只发生一次。重开和退出属于不同路径，退出前未必有可靠最后事件。

{"event":"round_end","event_version":1,"round_id":"r-17","level_id":"learn","config_version":"levels-1","result":"won","turns_left":2}

该示例不含真实用户信息。是否需要标识符、保留多久、是否传第三方 SDK，要根据实际用途、平台要求和隐私披露核实。

漏斗必须定义分母

“进入 → 成功加载 → 开始 → 首次操作 → 完成 → 重试”能定位大致损失，但每一步要说明按玩家、会话还是局去重，窗口多长、版本是否一致。

完成率低可能来自加载失败、规则不懂或关卡太难，不能只看 round_end 的胜率。只分析已完成局，会遗漏中途退出的人。

传输与平台

批量上报要有大小和队列上限、失败重试及丢弃策略；不能在每帧同步发送。客户端时间可变，日志排序结合会话顺序和服务端接收时间。

微信 wx.reportEvent 需要配合后台配置，不能把任意事件名发出就当成已采集。旧 reportMonitor 已停止维护。方法参考 PM：埋点设计、微信 reportEvent。

练习：完成、失败、退出各跑一次，对照日志和实际行为。完成标准：事件能回答一个明确问题，没有重复结算，未报告的数据不被当作零。