埋点设计、数据质量与分析流程

仪表盘显示三次奖励发放，玩家余额只增加两次。你应该补发一次，还是删掉重复事件？如果把日志和权益当成同一件事，两种处理都可能扩大错误。

本篇帮助你从待决问题倒推事件，并检查操作、记录、资产和指标是否在讲同一个事实。

为什么不从“记录所有点击”开始

你想判断广告是否阻碍解题，需要知道请求、展示、关闭、奖励与关卡后续，而不只是按钮点了多少次。没有业务问题，数据量越多，越难知道哪一条应被解释。

先写指标与决定，再列必要事件、触发、属性和分析用途。收集前检查个人信息与授权，只留必要字段；具体要求见 隐私专题。方便分析不代表可以无限收集。

两种标识为什么不能混用

event_id 标识一条事件。断网重发同一事件时复用它，才能去重。attempt_id 标识一次游玩尝试；同一关重来，必须新建尝试，否则会把不同过程并成一次。

level_id 标识关卡，level_version 区分改版。事件名保持稳定，关卡变化放属性，才能比较和过滤。公共字段还包括事件与接收时间、会话、合规玩家标识、客户端和配置版本、渠道。客户端时间会出错，不能毫无检查地作为唯一顺序依据。

事件	触发含义	为什么不提前记录
game_start	必要资源就绪，可进入主体验	启动 SDK 尚不代表可玩
level_start	关卡可交互，生成一次尝试	资源请求成功尚不代表已准备好
level_end	尝试进入定义好的结束状态	后台切出不必等于失败
ad_request / ad_show / ad_close	对应实际广告状态	点击意图不能冒充展示
reward_grant	有效奖励变更被确认	关闭广告不必然满足奖励条件

未知结果保留未完成或待确认，生命周期事件与超时规则单独定义。这样后续能区分主动放弃、进程终止和状态缺失。

为什么链路要逐层对账

原始事件三条、去重后两条、权益两笔，可能完全正确；原始两条、权益三笔，则可能是资产重复变更。事件去重和资产幂等是两个独立保证，不能靠仪表盘差不多就判定通过。

用正常完成、重复点击、断网补报、杀进程、前后台、旧版本、时间异常和配置变化逐步核对。涉及资源与金额，再和可信资产记录对账。

为什么分析先检查数据质量

渠道漏报、某版本没有事件，会让玩家看起来“流失”。先确认问题、比较对象和完整性，再看总体与分群，提出候选解释并补证。查询、指标版本和埋点断点保留记录，避免把口径变化误当产品改善。

看板只需服务近期决定：启动失败是否扩大、新手是否独立完成、广告是否伤害后续。附口径、延迟和负责人，比增加图表数量更重要。

适用边界：并非所有行为都能精确还原

离线、隐私限制、进程结束都可能让部分过程缺失。记录可观测范围和延迟，不应补造失败事件使漏斗整齐。本地原型也不能证明线上资产安全。

练习：用 埋点模板 定义奖励链，制造一次重复上报与一次真实新请求。分别数原始事件、去重事件和权益变更，解释每个数字为何不同。