作者：上线第三天，老板在工作群里丢出一句话：“昨天新增的人里，有多少玩到了第十关？“群里安静了半分钟——统计SDK是接了，但没人埋”通过第十关“这个事件。做游戏数据埋点这几年，类似的场面见过不止一次，它最要命的地方在于：窗口只有一次，错过了，历史数据永远不会回来补。这篇把上线前必须接好的东西，按顺序说清楚。
埋点体系的三层
第一层是技术埋点：启动、崩溃、卡顿、加载时长，回答“游戏本身稳不稳”。第二层是行为埋点：关卡进度、新手引导每一步的流失、功能使用频次，回答“玩家在怎么玩”。第三层是商业埋点：广告展示与收益、付费节点、首充转化，回答“钱从哪来”。
落到具体事件上，技术层是“游戏启动”“崩溃上报”这类；行为层是“进入关卡”，参数带关卡号、用时、失败次数；商业层是“广告展示”，参数带广告位、类型、收益。三层的重要性，对休闲游戏来说恰恰是倒过来的——不少团队把力气全花在技术上，上线后最想看的留存和流失原因，一条数据都没有，只能干瞪眼。
三层不用一步到位，但三个问题各留至少一条数据。上线第一周你要回答的，无非是“稳不稳、玩到哪、赚没赚”，对应三层数据各成一块，报表的骨架就有了。
事件设计：别贪多，先保关键路径
埋点设计最容易犯的错，是想把一切记下来。事件一多，命名混乱、标准打架、没人看得过来，报表最后变成没人打开的摆设。可行的做法是先画出玩家的关键路径——下载进入、完成教程、通过前三个核心关卡、次日返回、首次付费或首次看广告——关键路径上的每个节点必须有事件，节点之间的转化率就是你要的第一批数据。
关键路径之外，只埋“做决策时你确定会看”的指标。埋点文档里可以给每个事件标上两栏：谁会看它、看它做什么决策。说不清这两问的事件，大概率不值得埋。数据不是记得越多越好，是查得越快越好。
新手引导值得单独说：它是流失最集中的路段，每一步的通过率都值得有事件。见过一个项目，引导第二步的流失比别处高出一截，查下来是一个按钮的点击区域太小。没有埋点，这种问题永远只会被笼统地归因为“留存不行”。
统计标准这件事，现在不统一，以后对不上
“活跃用户”算不算只打开了三秒的？“一天”按自然日还是24小时？广告收益按展示算还是按填充算？每个问题单看都有道理，但一个项目里只能有一种答案，而且要写进文档。留存的算法也要一开始锁死：新增算不算自然回访、跨零点的局怎么算，这些和一个渠道的统计平台对不上是常态——先定好自己的、以自己为准，渠道数据只做参考。
埋点事件表——事件名、参数、触发时机、负责人——是项目的正式交付物，和代码一个地位：换人的时候它是交接文档，对数的时候它是对账单。见过一个项目，两张报表的日活差了三成，查了三天，发现是两套SDK对“活跃”的定义不同。顺带把数据面板的默认视图也定下来：留存曲线、关键漏斗、广告收益三块，够用到上线后第一个月。
上线前，把埋点也“测”一遍
埋点是代码就会出错，所以它也要过测试。版本打包后，实际操作一遍关键路径，对着后台看每个事件有没有触发、参数对不对；多端项目还要核对各端上报的一致性。这一步半天就能做完，省下的是上线后“数据好像不太对，但说不清哪里不对”的漫长抓瞎。
再把埋点验收写进发版流程：每次新版本合并前，跑一遍关键路径的埋点校验。埋点坏掉，往往就是某次重构顺手改出来的。另外别忘了隐私这条线：采集之前要有用户同意和隐私政策，涉及个人信息的事件要收敛——合规的成本不高，出事的成本很高。
玉雀科技做手游开发项目时，埋点方案是和需求文档放在一起评审的。即将上线的项目，想让第二双眼睛把埋点方案过一遍，联系我们，或打18616880101——赶在上线前过，还来得及。