埋点、BI 与分析系统

Category

operation / bi 子树。节点定位：数据系统的失败形态是「人人有图、无人敢信」——埋点的事实采集纪律、口径治理、BI 复用与链路故障点。

Definition

数据系统最常见的失败，不是没有数据，而是所有人都能拿出一张图，却没人敢保证图里的数字真能代表业务现实。埋点、BI 和分析系统如果没有统一口径，只会把争论从“发生了什么”升级成“到底该信哪份报表”。

Problem

没有统一口径，分析只会把「发生了什么」的争论升级成「该信哪份报表」的争论；采集→传输→入仓→出表的链路任何一环悄悄丢数据，下游所有结论都失真。埋点先回答「事实是什么」，图表只是事实的投影。

埋点首先是事实采集，不是想到什么记什么

很多团队早期做埋点，习惯是产品、运营、分析师谁要数就让客户端或服务端“顺手埋一下”。这种做法短期快，但后续会持续制造问题：

• 同一个行为在不同端被重复定义
• 事件名相似但字段含义不同
• 老埋点没人清理，新埋点没人验收
• 客户端事件和服务端事实互相打架

更稳妥的做法是先给事件分层：

• 行为事件：点击、进入、退出、浏览等前端交互
• 业务事件：完成对局、领取奖励、完成支付、创建角色等关键事实
• 系统事件：加载失败、网络错误、卡顿、崩溃、服务异常

其中真正影响经营判断的关键指标，尽量优先建立在服务端可验证事实之上。客户端行为数据很重要，但更适合解释路径和体验，不适合单独承担结算类、收入类和资产类结论。

指标口径为什么永远比图表更重要

日报、周报、活动看板都只是展示层。真正决定分析质量的是口径定义，例如：

• “新增用户”是按首次登录、首次创角，还是首次完成新手引导
• “活跃用户”按登录算，还是按产生有效行为算
• “付费用户”是按支付成功算，还是按发货成功算
• “流失”是几天未登录，还是几天未产生核心行为

只要这些口径不稳定，报表越多，误导越严重。很多经典争议并不是算法问题，而是口径问题：

• 市场侧说投放带来高新增，产品侧说新手流失异常，其实一个按注册算，一个按创角算
• 运营说活动提升留存，分析师说没有显著变化，结果一个看次日登录，一个看七日核心行为
• 支付看板显示收入增长，但财务对账发现其中包含未最终确认订单

所以任何重要指标都应该有清晰定义文档、负责人和变更记录。

BI 系统的价值不在“能查”，而在“查出来能被复用”

如果数据系统只是让分析师写 SQL，再把结果截图发群里，那它还算不上真正的 BI 能力。成熟一点的 BI 平台，通常至少要解决三件事：

• 让不同角色看到相同口径的指标
• 让高频分析模板化，而不是每次重写 SQL
• 让报表能和活动、实验、分群、告警等动作链路接起来

也就是说，BI 不只是读数据，还要成为组织内的共享事实层。没有这层共享事实，复盘会变成各说各话。

数据链路通常会在哪些地方出问题

采集侧

• 客户端丢包、重试、离线缓存导致事件时序混乱
• 服务端事件定义和数据库事实不一致
• 多端共用一个埋点名，但字段语义不一致

加工侧

• ETL 逻辑版本变更后未同步历史重算
• 维表口径变化，例如渠道、区服、用户等级映射不同步
• 时区、自然日和运营日定义不统一

消费侧

• 不同部门复制报表后二次加工，形成“民间口径”
• 活动复盘直接拿临时报表，未固定样本和时间窗口
• 关键指标没有异常告警，错了很多天才被发现

一个更实用的建设顺序

对于大多数团队，数据系统更现实的建设顺序是：

1. 先稳定关键业务事实事件和核心指标口径
2. 再做统一主题域，例如新增、留存、付费、活动、经济
3. 然后再做更灵活的自助分析、标签分群和实验分析

很多团队会反过来，先上很强的查询平台，最后发现底层数据不可信，平台越强，传播错误的速度越快。

常见错误

• 埋点没有命名规范和验收流程，导致没人知道哪些还能信
• 过度依赖客户端埋点去判断资产、支付和结算类事实
• BI 平台只服务分析师，不服务运营、产品和研发的共同决策
• 报表很多，但没有指标 owner、没有口径文档、没有异常校验

真正成熟的数据分析系统，不是你能画多少图，而是关键时刻团队能不能快速拿到同一份可信事实，然后在这份事实上做决策。

Used By

埋点方案评审（事件设计与口径文档）；BI 指标体系与看板建设；数据链路故障排查（数字对不齐时的分层归因）。

Related

关系链：事实采集 → 口径治理 → BI 复用 → 链路故障点 → 建设顺序。上游：bi/01（运营闭环靠核对端兜住）。下游：bi/03（三类分析消费这些口径）、numerical 树（数值核对用同一套口径）。

Reference

本页为工程经验归纳。