Ludo Atlas · 管线 · 遥测与数据分析¶
管线与工作流。定位：把「玩家实际怎么玩」变成可查询、可信、可行动的数据，覆盖事件设计、采集、治理、看板与隐私最小化的完整数据管线。 配套：《运营与增长手册》·《法务、专利与竞争手册》·《制作管理手册》·《避坑大全》。 适用：进入可玩测试就该有最小埋点（崩溃、会话、核心漏斗）；单机小品可以裁剪，但事件字典与数据最小化两条不省。与 《运营与增长手册》 的边界：《运营与增长手册》 讲拿数字做运营决策，本页讲数字怎么来、靠不靠得住。
1. 定位与适用¶
遥测与数据分析管线是一条「把行为变成证据」的通道：事件从玩法代码出发，经过采集、治理、存储与聚合，抵达看板与决策会议。它不负责「拿到数字之后怎么运营」，那是《运营与增长手册》的领地；它负责「数据可不可信、问题答不答得上」：
- 有出处：每个数据点能追到事件定义与触发时机；口径写在字典里，不靠口口相传。
- 有目的：每个事件挂着一个具体问题和一个消费方，先定问题再埋点（§3.1）。
- 有边界：采集以最小化为默认，能匿名就匿名，能不收就不收（§3.3）。
五个环节先摆清楚，后文反复出现：
| 环节 | 做什么 | 归属 |
|---|---|---|
| 事件设计 | 定义事件、属性与口径 | 事件字典，与代码同仓库 |
| 采集 | 客户端触发、缓存、上送 | 客户端工程 |
| 治理 | 去重、清洗、保留期、删除通道 | 数据侧流程 |
| 存储与查询 | 明细留存、聚合表、口径换算 | 数据仓库或分析库 |
| 消费 | 看板、报表、报警与决策记录 | 看板与例会 |
什么时候值得立这条管线：已经能问出「玩家卡在哪、还回不回来、一局玩多久」，却拿不出数据回答的时候；准备上线、要盯崩溃与核心漏斗的时候。原型期可以只留崩溃与一条关键行为，靠试玩与访谈找方向；进入可玩测试后最小埋点就该就位，上线前夜才补，等于把最该看的早期曲线全部丢掉。
2. 工具链¶
链路五段，每段只留一件主力工具，选型先看归口：
| 环节 | 自建方案 | 服务方案 | 选型注意 |
|---|---|---|---|
| 采集 SDK | 自研，批量、异步、断点补发 | 服务商 SDK（Firebase、GameAnalytics 一类） | 上报不得拖帧，断网补发要有窗口 |
| 接入与处理 | 自建端点加定时清洗 | 服务商端点 | 去重、时钟、环境隔离都由这段负责 |
| 存储与查询 | 云端数据仓库或列式库（BigQuery、ClickHouse 一类） | 服务商自带存储 | 明细保留期与查询成本提前算 |
| 看板与报表 | 开源 BI（Metabase、Grafana 一类） | 服务商面板 | 指标定义以字典为准，不跟工具走 |
| 崩溃与性能 | 自建上报加聚合 | 崩溃收集服务（Crashlytics、Sentry 一类） | 与玩法事件分通道，同源不同路 |
自建与服务的取舍是选型核心：
| 维度 | 服务 | 自建 |
|---|---|---|
| 起步成本 | 低，接上 SDK 就有面板 | 高，每段都要自己搭 |
| 变更速度 | 受服务商迭代与配额约束 | 想加就加 |
| 数据主权 | 数据在服务商侧，出境与合规要评估 | 全程在自家库，透明度最高 |
| 费用 | 随事件量上涨，量大后常超预算 | 固定成本为主，人力换掌控 |
| 维护负担 | 接近零 | 要有人长期养 |
| 适合 | 没有数据工程人力的团队、验证期 | 事件量大、合规敏感、需求特殊 |
纪律三条：先服务、后自建是常见路线（先用服务验证哪些看板真有人看，再决定哪些搬到自建）；事件字典永远在自己仓库里（工具可以换，定义不能跟着服务商走）；免费档的配额、保留期与取样是隐形代价，选型时先把细则读完。
3. 流程与规范¶
3.1 先定问题，再埋点¶
正向链路是固定的：问题 → 假设 → 指标 → 事件 → 看板。反过来先埋一堆再找用途，得到的是一屋子没人看的曲线。三类问题对应的事件骨架：
| 问题类型 | 典型问法 | 核心事件 | 关键属性 |
|---|---|---|---|
| 漏斗 | 玩家卡在哪一步？教程到首胜的转化是多少？ | 关键步骤的进入与完成，如 tutorial_step_start、tutorial_step_complete |
步骤编号、耗时、结果 |
| 留存 | 玩家还回来吗？哪批人第二天就没影了？ | 会话开始 session_start 加首次关键行为，如 first_win |
渠道来源、版本、首次日期 |
| 曲线 | 时长、难度、经济在什么水平？ | 单局开始与结束，如 level_start、level_end |
关卡编号、成败、时长、分数或资源量 |
- 漏斗问题的动作是改流程与引导；留存问题是改前期体验；曲线问题是改数值。三类问题的数据流向与看板形态不同，不要用一张大表糊全部。
- 先写假设再取数：预期「教程第二步流失超过三成」，再与实测比对。没有预期的数字，事后解释权全归直觉。
- 定量与定性是两条腿：遥测回答「多少、在哪一步」，试玩与客服回答「为什么」。只有数字不知道原因，只有体感不知道范围。
3.2 事件命名与属性规范¶
事件名是接口，上线即承诺。规范定死后写进仓库：
- 命名格式：全小写、下划线分隔、动词收尾，形如
对象_动作或流程_步骤_动作；版本、数值、参数一律不进名字。 - 语义只增不改：要改语义就新增事件、废弃旧事件；废弃走停采公告，给看板留迁移期。
- 属性三条纪律：通用字段（时间、会话、版本、平台、渠道、地区）由采集框架统一带；枚举值用固定小写英文常量，禁止自由文本；数值带单位约定，如
duration_ms。 - 属性最小化：每个事件只带回答它那个问题所需的属性。多带的每个字段既是成本，也是隐私面。
事件字典是唯一事实来源，一张表定全：
| 事件名 | 触发时机 | 必填属性 | 回答什么问题 | 消费方 |
|---|---|---|---|---|
session_start |
进入游戏主界面 | 渠道、版本 | 活跃与留存口径 | 健康看板 |
level_end |
单局结算 | 关卡编号、成败、时长 | 难度与时长曲线 | 玩法看板 |
purchase_complete |
支付回调成功 | 商品编号、金额档、货币 | 付费漏斗与收入口径 | 运营看板，口径联动 《运营与增长手册》 |
字典与代码同仓库、改动走评审；新增事件前先答三问：回答什么问题、谁消费、半年后还有没有人看。答不全就不加。
3.3 数据最小化与隐私合规¶
原则一句话：能回答问题的前提下，收得越少越好。法规与平台规则的全量清单见《法务、专利与竞争手册》（《法务、专利与竞争手册》§6.1，覆盖 GDPR、CCPA、COPPA、PIPL 与商店隐私标签），本节只列管线侧要落实的动作：
- 默认最少：每个字段先问「没有它，问题还答不答得上」，答得上就不收；年龄、性别这类档案字段非必填、可跳过。
- 标识符纪律：设备级匿名 ID 与账号 ID 分开存，可重置、可解绑；不申请与游戏无关的系统权限，通讯录、相册、精确位置、剪贴板都不碰。
- 同意与开关：首次启动的隐私说明与实际采集逐条一致；提供关闭数据采集的开关，关闭后游戏功能不受影响。
- 生命周期：每类数据定保留期，到期清理；账号注销与删除请求要能贯穿明细库、聚合库与备份，删得掉才算合规。
- 儿童与青少年：面向或可能覆盖儿童的品类，家长同意与最小化标准更严，方案先过 《法务、专利与竞争手册》 的儿童数据条款。
- SDK 台账：每个第三方采集 SDK 登记「装了谁、收什么、发到哪」；商店隐私标签与数据安全表单要和台账逐条对得上，对不上是下架级风险，不是文案问题。
3.4 采集纪律与数据质量¶
- 客户端纪律：上报异步、批量、可丢弃，任何情况下不拖累帧率与操作；断网写入本地缓存，恢复后按窗口补发；每条事件带唯一 ID 供去重。
- 时间口径：以服务器接收时间为准，客户端时间只作诊断；跨时区的日报口径提前定死。
- 环境隔离：开发、测试、生产三套 key，测试包与机器人数据不进生产库；从第一天隔离，事后清洗的成本高一个量级。
- 质量四查：关键事件应触发必到达、延迟在窗口内、去重与乱序处理后口径稳定、与商店或平台侧数据交叉验证。四查做成例行报表，不靠临时抽查。
- 断流监控：每个事件的日到达量设基线，偏离阈值即报警。半夜断流，第二天早上就该知道，而不是月底复盘才发现。
- 技术侧优先：崩溃率、启动失败率、帧率分布是数据管线第一批要服务的问题；技术上不了线，玩法看板再全也兑现不了。
3.5 看板与决策习惯¶
- 看板分层，每层只留关键指标：健康层（崩溃、留存、核心漏斗）→ 玩法层（关卡、系统）→ 经济层（收入与消耗，若有）→ 技术层（性能、包体）。起步每层 5-10 个指标，加一个先去掉一个。
- 每个上板指标配三件套：负责人、对比基准（上周或基线）、触发动作（跌破多少做什么）。没有触发动作的指标下架。
- 更新节奏：自动日报发摘要，周会只过异常，月度回看口径。会议看异常与动作，不逐条诵数。
- 数据辅助而非主导：数字告诉你问题「在哪里」，玩家告诉你「为什么」。指标恶化先拆维度（哪批人、哪个版本、哪个平台）再定动作；拆不出来就去玩一下游戏。
- 决策记录：重要改动写下依据与预期，上线后回来对账；预期没发生也是结论，写进复盘（方法见《制作管理手册》（《制作管理手册》§9））。
- 反虚荣：不看注册总量与累计下载，看活跃分布与时长分位数；平均时长骗人，中位数与尾部才说明问题。
4. 自动化与验收¶
机器查格式与完整性，人查口径与问题。下列检查尽量脚本化，接在构建与数据链路上：
| 检查项 | 触发时机 | 不通过的处理 |
|---|---|---|
| 事件登记检查 | 构建时，埋点代码对照字典 | 构建失败 |
| 属性 schema 校验 | 上报前与入库前，查类型、必填、枚举 | 丢弃并告警 |
| 关键路径断言 | 自动化测试跑关键路径并断言事件触发 | 测试失败 |
| 到达量与延迟监控 | 每日基线对比 | 报警，值班跟进 |
| 隐私扫描 | 发版前搜敏感字段与未登记 SDK | 发布拦截 |
| 看板刷新 | 定时任务重算聚合 | 异常自动标注 |
验收看四件事，全部可观察：
- 拿来一个新问题，从定义指标到看板出答案，全程不需要口头解释。
- 抽查三个关键事件：线上数据的结构与量级和字典对得上，触发时机与文档一致。
- 关掉整条采集管道：游戏功能与帧率不受影响，数据侧按约定从缓存补上或安全丢弃。
- 提一个玩家删除请求：明细、聚合与备份里都查不到该玩家的原始数据。
管线自己的四个指标：事件到达率、schema 违规数、从问题到结论的周期、上板指标中「有触发动作」的占比。前三个看健康，第四个看这条管线有没有真的参与决策。
5. 常见坑¶
- 跟风埋点：别人采什么我采什么，采完没人看。每个事件先写清回答什么问题、谁消费，答不出就不采（§3.1）。
- 指标无行动：看板天天刷新，没有任何数字触发过行动。上板即定负责人、阈值与动作，定不出来就别上（§3.5）。
- 隐私越界：顺手收设备信息与用户画像，理由是「以后可能有用」。最小化是默认，儿童数据先过法规（§3.3、《法务、专利与竞争手册》）。
- 只看数字不看玩家：留存掉点，报表里找不到原因，只能靠加福利硬拉。数字定范围，玩家讲原因，两条腿一起走（§3.1）。
- 命名与口径各自为政：程序事后改名、运营口径另算，会上两个数字打架。字典是唯一来源，口径变更走同一次评审（§3.2）。
- 埋点拖帧：上报同步等网络，卡顿出现在玩家脸上。采集异步、批量、可丢弃（§3.4）。
- 上报丢失无感知：弱网、改版、SDK 故障，数据缺了一角，决策照着残缺曲线做。到达量监控与补发窗口是标配（§3.4）。
- 测试数据污染生产：测试包、机器人与开发机数据全进生产库，指标虚高。环境隔离从第一天做起（§3.4）。
- 字典失修：代码改了没人更新字典，半年后自己也不敢信这张表。新增与废弃事件走评审与公告（§3.2）。
- 漏掉技术侧遥测：只埋玩法不盯崩溃与启动失败率，流失原因找错方向。技术数据与玩法数据一起上板（§3.4）。
延伸阅读¶
- 《运营与增长手册》：指标口径与运营决策的消费端；《运营与增长手册》 管「数字拿来做决策」，本页管「数字怎么来、靠不靠得住」。
- 《法务、专利与竞争手册》：隐私法规、平台隐私标签与儿童数据条款，第 3.3 节的法规底稿（§6.1）。
- 《制作管理手册》：埋点与看板同样是排期对象；复盘方法说明数据在项目复盘里怎么用（§9）。
- 《避坑大全》：遥测、数据与隐私相关的实例清单，与第 5 节对照阅读。