如何设计一套能长期用于生产的游戏埋点事件规范

面向开发者的游戏埋点事件规范：生命周期事件、命名规则、公共上下文、基数限制、版本管理与审核清单。

生产级事件体系是游戏代码与决策之间的版本化契约。生命周期事件应少而稳定，公共上下文集中附加，游戏专属事件只在支持明确决策时增加。

核心要点

先定义应用生命周期，再定义单局或比赛生命周期，然后是进度与经济/战斗摘要，最后才是严格控制的自定义事件。即使后续游戏专属埋点不完整，这种顺序仍能保留可用的最小数据集。

使用小写 snake_case，并用过去式表达已完成结果。可复用分类放在字段中，不要动态生成事件名。例如，一个包含 stage、step、status 的进度事件，比数百个 tutorial_step_17_completed 变体更容易查询。

为 outcome、mode、channel 和 reason 定义允许值。未知值应拒绝或隔离，不能静默创建新分类。自由文本和嵌入维度值的 ID 会产生无限基数和脆弱看板。

每个事件定义都需要负责人、触发时机、权威数据源、必填字段、允许值、隐私分类、去重键，以及它支持的指标或决策。如果没人能说清决策，就先不要加入该事件。

契约测试：在运行游戏前，先根据脚本化单局列出预期的全部事件和值。

字段类型不变但含义变化，仍然属于破坏性分析变更。协议版本应独立于游戏版本记录，定义兼容窗口，并在分母或触发条件变化时给仪表盘指标添加注释。

事件名应该包含关卡或物品 ID 吗？+

通常不应该。保持稳定事件名，把经过校验的低基数关卡或物品类别放在字段中；唯一实例 ID 不应成为分析维度。

首个版本应该有多少游戏埋点？+

采用能覆盖生命周期健康度和最初两三个决策的最小集合。十几个受治理的事件，可能比数百个无人负责的事件更有用。

竞品能力与价格可能变化。本文依据以下官方页面撰写，并以页面所示日期为最后核验时间。

由 G-Less 产品与工程团队撰写并审核。指南建立在真实 Steam Demo 与 PC 游戏版本所使用的事件模型上；涉及产品能力的表述会在发布前对照当前遥测协议进行核验。