A telemetry contract for a mobile game soft launch
A telemetry contract for a mobile game soft launch
移动游戏软启动的遥测契约
A limited release only produces useful evidence when the build, events, and decision rule agree. Before opening a mobile game to a small real audience, write a one-page telemetry contract. It prevents a team from calling a broken event trigger “poor retention.” 只有当构建版本、事件埋点和决策规则达成一致时，有限发布（软启动）才能产生有价值的证据。在向一小部分真实用户开放移动游戏之前，请先撰写一份一页纸的“遥测契约”。这可以防止团队将损坏的事件触发器误判为“留存率低”。
Start with a question, not an event list. Suppose the launch question is: can a new player complete the first mission without help on the target device class? Name the build version, audience, observation window, and owner. Then define only the events needed to answer it: session_started, mission_started, mission_completed, and an abandonment or failure state. A crash trace and device/build identifier provide context; they do not replace player behavior.
从问题出发，而不是从事件列表出发。假设发布的核心问题是：新玩家能否在目标设备类别上无需帮助完成第一个任务？明确构建版本、受众群体、观察窗口和负责人。然后，仅定义回答该问题所需的事件：session_started（会话开始）、mission_started（任务开始）、mission_completed（任务完成），以及放弃或失败状态。崩溃追踪和设备/构建标识符提供背景信息，但它们不能替代玩家行为数据。
Each event needs a trigger, allowed properties, and an expected count. For example, mission_completed should fire once after the game state commits the result, not every time a completion animation replays. If the game works offline, document how events queue and how duplicates are handled after reconnecting. Without that rule, a retry can make a completion funnel look healthier than it is.
每个事件都需要明确触发条件、允许的属性和预期计数。例如，mission_completed 应该在游戏状态提交结果后触发一次，而不是每次重播完成动画时都触发。如果游戏支持离线运行，请记录事件如何排队，以及重新连接后如何处理重复数据。如果没有这条规则，重试机制可能会让完成漏斗看起来比实际情况更健康。
Separate test traffic from release traffic. Validate events in a development or test environment before the limited release, then verify that the production build sends to the intended production environment. Unity Analytics supports environment separation; an impressive graph is not evidence if internal QA sessions are mixed with real players. 将测试流量与发布流量分开。在有限发布之前，先在开发或测试环境中验证事件，然后确认生产版本是否发送到了预期的生产环境。Unity Analytics 支持环境隔离；如果内部 QA 会话与真实玩家的数据混在一起，那么再漂亮的图表也不是有效的证据。
Run a small acceptance matrix before opening the audience: 在向受众开放之前，请运行一个小型的验收矩阵：
| Scenario | Expected evidence |
|---|---|
| 场景 | 预期证据 |
| Install and complete mission | One start and one completion for the correct build |
| 安装并完成任务 | 正确构建版本的一次开始和一次完成 |
| Exit halfway | A start without a completion, with no invented success |
| 中途退出 | 有开始无完成，且没有虚构的成功记录 |
| Lose connection and retry | No duplicate completion after recovery |
| 断开连接并重试 | 恢复后没有重复的完成记录 |
| Crash before objective | Crash and last known stage can be correlated |
| 目标达成前崩溃 | 崩溃信息与最后已知阶段可关联 |
| Internal QA session | Excluded or clearly segmented from release analysis |
| 内部 QA 会话 | 从发布分析中排除或清晰分段 |
Do not put personal identifiers into public reports. Decide what data is actually needed and check consent and privacy requirements before instrumenting a user journey. 不要将个人标识符放入公开报告中。在对用户旅程进行埋点之前，请确定实际需要哪些数据，并检查同意书和隐私要求。
Make the decision before seeing the graph. The contract should say which outcome means continue to the next bounded audience, which means fix and retest, and which means stop or rescope. A tiny or biased cohort should be labelled inconclusive. If the build changes during the test, split the results by version. If an event is unreliable, mark the measurement invalid; do not treat missing data as player failure. 在看到图表之前先做出决策。契约应说明哪种结果意味着进入下一个受众群体，哪种意味着修复并重测，哪种意味着停止或调整范围。规模过小或有偏差的群体应被标记为“结论不明确”。如果测试期间构建版本发生变化，请按版本拆分结果。如果某个事件不可靠，请将该测量标记为无效；不要将缺失的数据视为玩家失败。
This is only one part of a wider release decision. Build stability, support load, store availability, and the actual first-session experience matter too. Our broader game soft-launch decision guide covers the difference between beta testing, limited-market release, and staged app updates, plus the evidence a game owner should ask the development team to deliver. The useful deliverable is not a wall of charts. It is a versioned build, a verified event contract, and a written go/fix/stop decision that another person can audit. 这只是更广泛发布决策的一部分。构建稳定性、支持负载、商店可用性以及实际的首次会话体验同样重要。我们更广泛的游戏软启动决策指南涵盖了 Beta 测试、有限市场发布和分阶段应用更新之间的区别，以及游戏负责人应要求开发团队提供的证据。有用的交付成果不是一堆图表，而是一个带版本的构建包、一份经过验证的事件契约，以及一份可供他人审计的书面“执行/修复/停止”决策。