3. 数据采集策略：埋点方案设计、日志规范、采样频率与数据量权衡、数据清洗与预处理
数据采集是整个度量分析的起点。起点要是歪了，后面再漂亮的图表、再高级的算法，都是白搭。我见过太多团队，花了大价钱搭平台，结果埋点数据一塌糊涂——字段对不上、时间戳飘忽不定、关键事件漏报。说白了，数据采集不是「插个代码就完事」，而是一套需要精心设计的系统工程。
这一章，我就把我在座舱项目里踩过的坑、总结出的套路，掰开揉碎讲给你听。
3.1 埋点方案设计：从业务指标到技术实现
埋点方案设计，核心就一句话：先想清楚要度量什么，再决定怎么采集。千万别反过来，先看 SDK 支持什么功能，再硬往上套业务。
3.1.1 埋点类型选择
座舱场景下，我一般把埋点分成三类：
| 类型 | 说明 | 典型场景 | 我常用的实现方式 |
|---|---|---|---|
| 代码埋点 | 在业务逻辑中手动插入采集代码 | 按钮点击、页面跳转、功能开关 | 封装一个统一的 track() 函数，避免到处写 console.log |
| 无埋点（全埋点） | 自动采集所有用户交互事件 | 页面浏览、手势操作、控件曝光 | 通过 AOP 切面或运行时 Hook 实现，但要注意性能开销 |
| 服务端埋点 | 在后端接口中记录关键行为 | 登录、支付、数据同步、OTA 升级 | 在 API 网关或业务服务中异步写入日志 |
3.1.2 事件命名规范
事件命名这件事，看着简单，但坑最多。我曾经接手过一个项目，事件名叫 click_btn、button_click、btnClick 三种混着来，查数据时简直想骂人。
我建议的命名规范：
- 统一分隔符：全部用下划线
_，不要混用驼峰和连字符 - 层级清晰：
模块_页面_控件_动作，比如navi_search_input_click - 动词后置：统一用
_click、_view、_swipe、_longpress - 避免数字后缀：不要出现
button_1、button_2，用语义化名称
避坑指南：我曾经因为事件名大小写不一致，导致数据清洗时丢失了 30% 的埋点记录。从那以后，我强制要求所有埋点在上线前必须通过命名规范校验脚本。
3.2 日志规范：让数据「说人话」
埋点事件定义好了，接下来就是日志格式。日志规范的核心目标是：让机器能解析，让人能看懂。
3.2.1 统一日志结构
我推荐使用 JSON 格式，结构如下：
{
"event": "navi_search_input_click",
"timestamp": 1712563200000,
"session_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"user_id": "u_98765",
"device_id": "d_abc123",
"app_version": "2.3.1",
"os_version": "Android 14",
"properties": {
"search_type": "voice",
"input_length": 8,
"result_count": 5
}
}
几个关键字段的说明：
- timestamp：统一使用 UTC 毫秒时间戳，避免时区问题
- session_id：每次启动生成唯一 ID，用于串联用户操作路径
- properties：事件属性，按需扩展，但不要塞太多无关字段
3.2.2 字段类型约束
每个字段的类型必须明确。我见过最离谱的是，同一个字段今天传字符串，明天传数字，后天传 null。数据清洗时直接崩溃。
| 字段 | 类型 | 约束 |
|---|---|---|
| event | string | 必须匹配预定义事件列表 |
| timestamp | int64 | 毫秒级，不允许为 0 或负数 |
| session_id | string (UUID) | 非空，格式校验 |
| properties | object | 键值对，值类型统一 |
3.3 采样频率与数据量权衡
座舱场景有个特殊之处：数据量可能非常大，但存储和带宽都有限。你想想看，一辆车每天可能产生几十万条埋点数据，如果全量上报，车机网络扛不住，云端存储成本也吃不消。
所以，采样是必须的。但怎么采样，是个技术活。
3.3.1 采样策略对比
| 策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 固定比例采样 | 用户量大、行为均匀 | 实现简单，统计偏差小 | 无法聚焦特定用户群 |
| 分层采样 | 需要按车型/版本/地区分析 | 保证各层都有代表性样本 | 配置复杂，需要先分层 |
| 自适应采样 | 异常检测、高频事件降噪 | 动态调整，节省资源 | 算法复杂，可能引入偏差 |
| 全量+降采样 | 关键事件（如崩溃、安全告警） | 不丢失重要数据 | 存储成本高 |
3.3.2 采样频率的「黄金法则」
采样频率不是越高越好。我见过有人把传感器数据设成 100ms 采集一次，结果车机 CPU 占用率飙升，导航都卡了。嗯，这里要注意：
- 用户交互事件：按需触发，不要轮询
- 性能指标：每秒 1-2 次足够，除非在做专项分析
- 传感器数据：根据业务需求，一般 100ms-1s 一次
- 网络请求：只记录请求开始和结束，不要记录中间状态
3.4 数据清洗与预处理
数据采集上来，直接分析？别急。原始数据里什么妖魔鬼怪都有。我总结了一套「四步清洗法」：
3.4.1 清洗四步走
- 去重：同一事件在短时间内重复上报，只保留第一条
- 过滤：剔除字段缺失、格式错误、时间戳异常的数据
- 修正：对明显异常的值做修正或标记（如时间戳漂移超过 5 分钟）
- 标准化：统一单位、时区、枚举值（如将 "click"、"CLICK"、"Click" 统一为 "click"）
避坑指南：我曾经遇到过一个 case，某车型的埋点时间戳全部比实际时间晚了 8 小时，原因是车机时区设置错误。如果没做时间戳校验，所有「日活」数据都会算到前一天。从那以后，我强制在清洗阶段加入时间戳合理性校验。
3.4.2 常见异常数据处理
| 异常类型 | 示例 | 处理方式 |
|---|---|---|
| 缺失值 | session_id 为空 | 丢弃该条记录，或填充默认值 |
| 重复值 | 同一事件 1 秒内出现 3 次 | 保留第一条，其余丢弃 |
| 异常值 | 启动耗时 99999ms | 标记为异常，不参与统计 |
| 格式错误 | 时间戳为 "2024-04-08" | 尝试解析，失败则丢弃 |
| 逻辑矛盾 | 退出时间早于进入时间 | 丢弃该 session 的所有数据 |
3.5 数据采集整体流程
说了这么多，我把整个数据采集的流程画成一张图，方便你理解：
这张图把整个流程串起来了。你会发现，埋点设计、日志规范、采样策略是前置条件，决定了数据采集的质量；而数据清洗是最后一道关卡，确保进入分析阶段的数据是干净、可信的。