4. 数据采集与埋点：埋点规范、事件设计、常见埋点坑
数据产品最怕什么？最怕算出来的指标没人信。而指标可信的根基，就是埋点。
我见过太多团队，花大价钱搭了数据平台，结果因为埋点质量太差，所有报表都成了摆设。说白了，埋点就是数据产品的「地基」——地基歪了，上面盖的楼再漂亮也没用。
这一章，咱们就聊聊怎么把埋点这件事做扎实。
4.1 埋点规范：先定规矩，再动手
没有规范的埋点，就是一场灾难。我接手过一个项目，光「注册成功」这个事件，就有三种命名：register_success、reg_ok、user_signup_done。你想想看，后面做分析的时候得有多痛苦。
4.1.1 命名规范
我个人习惯用「对象_动作_状态」的命名方式。全小写 + 下划线，清晰且统一。
| 规范项 | 推荐做法 | 反面案例 |
|---|---|---|
| 事件命名 | product_detail_view |
ProductDetailView、查看商品详情 |
| 属性命名 | product_id、price |
productID、商品价格 |
| 枚举值 | click、long_press |
1、2（无文档时无法解读） |
4.1.2 版本管理
埋点也是代码，必须纳入版本管理。我建议每个事件都带上 version 属性，比如 v1.2。这样当埋点逻辑变更时，数据团队能清楚知道哪些数据是旧版本的，哪些是新版本的。
4.2 事件设计：从业务出发，不是从技术出发
很多工程师设计事件时，习惯从「页面有什么」出发。但真正好的事件设计，应该从「业务需要什么」出发。
4.2.1 事件的三层结构
我把事件拆成三层：
- 原子事件：用户的一次操作，比如点击、滑动、页面浏览。这是最底层的数据。
- 业务事件：由多个原子事件组合而成，比如「完成注册」= 填写手机号 + 获取验证码 + 点击注册按钮 + 注册成功回调。
- 指标事件：直接用于计算业务指标的事件，比如「新增用户数」对应的就是注册成功事件。
为什么要分三层？因为不同角色关注的东西不一样。产品经理看业务事件，数据分析师看指标事件，而开发同学只需要埋好原子事件就行。
4.2.2 属性设计原则
属性不是越多越好。我见过一个事件带了 40 多个属性，结果 90% 从来没被用过。属性设计要遵循「够用就好，可扩展」的原则。
核心属性清单（以电商为例）：
- 公共属性：用户ID、设备ID、时间戳、页面来源、App版本
- 业务属性：商品ID、商品名称、价格、品类、数量
- 上下文属性：网络类型、地理位置、屏幕分辨率
4.3 常见埋点坑：漏埋、错埋、重复埋
做埋点这么多年，踩过的坑能写一本书。下面这三个是最常见的，也是破坏力最大的。
4.3.1 漏埋：数据永远少一块
漏埋是最隐蔽的坑。数据看起来有，但一算关键指标就对不上。
典型案例：我之前做一个电商项目，订单转化率怎么算都偏低。查了两天才发现，用户在「确认订单」页面点击「返回修改」的操作没有被埋点。也就是说，所有修改订单的用户都被算成了「流失用户」。
避坑指南：我曾经在项目里推行「埋点覆盖率检查」——每个页面发布前，必须对照埋点字典逐条验证。漏掉一个事件，QA 就不给过。虽然前期麻烦，但后面省了无数排查时间。
4.3.2 错埋：数据是错的，比没有更可怕
错埋的典型表现是：数据有，但不对。比如把「商品ID」传成了「订单ID」，或者把「点击」事件和「曝光」事件搞混了。
为什么会这样？很多时候是因为开发同学对业务理解不够。我见过一个案例，开发把「加入购物车」事件里的 price 字段传成了「商品原价」，而不是「实际成交价」。结果所有跟价格相关的分析全错了。
我的建议：每个事件上线前，让产品经理或数据分析师做一次「数据验收」。他们最清楚业务逻辑，能一眼看出数据对不对。
4.3.3 重复埋：数据膨胀，成本飙升
重复埋点有两种情况：
- 同一个事件被多个地方触发：比如页面加载时触发了一次，用户操作时又触发了一次。
- 同一个属性被重复上报：比如
product_id和productId同时存在，值还一样。
重复埋点最直接的后果是数据量翻倍，存储成本上升。更麻烦的是，分析时还得做去重，稍不注意就会算错。
4.4 埋点质量保障体系
光知道坑还不够，得有系统的方法来防坑。下面这张图是我在团队里推的埋点质量保障流程。
4.5 埋点工具选型建议
工具选对了，能省一半的力。我简单对比一下市面上主流的埋点方案：
| 方案类型 | 代表工具 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 全埋点 | GrowingIO、友盟+ | 接入快，无需开发 | 数据量大，灵活性差 | 初创期快速验证 |
| 代码埋点 | 自研SDK、Firebase | 灵活可控，数据精准 | 开发成本高，易出错 | 成熟期精细化运营 |
| 可视化埋点 | 神策、Heap | 运营可自助配置 | 依赖页面结构，易失效 | 运营活动频繁的场景 |
我的建议：不要迷信全埋点。全埋点看似省事，但产生的数据噪音极大。我见过一个团队用全埋点，一个月的数据量是代码埋点的10倍，但有效信息反而更少。成熟的产品，建议以代码埋点为主，可视化埋点为辅。
4.6 埋点数据质量监控
埋点上线不是终点，而是起点。数据质量需要持续监控。
我习惯在数据平台里建几个「健康度看板」：
- 数据量级监控：每天对比事件量级，波动超过20%自动告警。
- 空值率监控：核心属性空值率超过5%就要排查。
- 异常值监控：比如
price出现负数，或者user_id出现空字符串。
嗯，这里要注意一点：告警阈值别设得太敏感。我刚开始做的时候，阈值设了10%，结果天天告警，团队都麻木了。后来调到20%，反而更有效。
埋点这件事，说难不难，说简单也不简单。核心就三点：规范先行、设计合理、持续监控。把这三点做到位，你的数据产品就有了一个扎实的底座。