第1章 埋点中间态概念与分类

埋点中间态是指用户行为数据从采集到最终形成可分析指标的过程中，所经历的三个关键状态阶段：原始态、清洗态和聚合态。这三个中间态构成了数据管道中的核心分层，理解它们的定义、特征与流转规则，是构建高质量用户行为漏斗分析体系的基础，也是数据产品经理与数据工程师之间统一语言的关键锚点。

1.1 适用场景

埋点中间态概念体系适用于以下典型场景：

• 用户行为漏斗搭建：在转化率、留存、路径分析等漏斗模型中，需要明确每个环节的数据来源与处理阶段。
• 数据质量治理：识别原始日志中的脏数据、清洗后的标准化记录、聚合后的指标异常，分别定位问题层。
• 数据仓库分层建设：将ODS（原始数据层）、DWD（明细数据层）、DWS（汇总数据层）与三种中间态对应，统一设计规范。
• 实时/离线数据管道运维：在Flink/Spark Streaming或离线ETL任务中，监控各状态的数据完整性与时延。
• 跨团队协作对齐：数据产品、数据开发、数据分析师使用统一的中间态术语，减少沟通歧义。

1.2 前置条件

在应用埋点中间态概念之前，需要确认以下条件已就绪：

• 埋点采集系统已部署并稳定运行（客户端SDK + 服务端接收端）。
• 数据仓库分层规范已定义，并同步至团队各成员。
• ETL/ELT处理框架（如Airflow、DolphinScheduler、Flink）已就绪。
• 团队已完成基础的数据建模培训，具备事件、用户、维度等基本概念共识。
• 数据字典与埋点元数据管理平台（如Metabase、DataHub）已上线。

1.3 操作步骤

本章的操作目标为识别与分类三个中间态，共包含4个步骤：

步骤1：采集原始埋点日志，确认原始态特征

从客户端或服务端获取未经任何清洗的原始日志。原始态数据的典型特征包括：时间戳格式不统一、存在重复事件、缺失关键字段、包含机器人或爬虫流量。以下是一条典型的原始埋点日志：

{
  "event": "click",
  "page": "home",
  "uid": "u12345",
  "ts": 1700000000,
  "device": "iPhone15,3",
  "os": "iOS 17.1",
  "extra": "ref=ad_banner&pos=top",
  "ip": "192.168.1.1"
}

步骤2：执行清洗标准化，确认清洗态特征

对原始日志进行字段校验、去重、格式归一、脏数据过滤后，得到清洗态数据。清洗态数据的特征：字段类型统一、缺失值已标记或填充、事件名称标准化、用户ID已解析。清洗后的标准化记录示例如下：

{
  "event_id": "click_home_top_banner",
  "user_id": "u12345",
  "event_time": "2024-01-01 00:00:00",
  "device_type": "ios",
  "device_model": "iPhone15_3",
  "os_version": "17.1",
  "referrer": "ad_banner",
  "position": "top",
  "ip": "192.168.1.1"
}

步骤3：执行聚合计算，确认聚合态特征

基于清洗后的明细数据，按时间、用户、事件等维度进行汇总，得到聚合态数据。聚合态特征：已形成可直接用于分析的指标，粒度较粗，存储量级大幅缩减。聚合结果示例如下：

{
  "date": "2024-01-01",
  "page": "home",
  "event": "click",
  "position": "top_banner",
  "total_count": 15432,
  "unique_users": 8721,
  "avg_daily_per_user": 1.77
}

步骤4：掌握状态流转关系（核心）

三种中间态之间按照原始态 → 清洗态 → 聚合态的方向依次流转，不可逆跳转。每个流转步骤都有明确的处理动作和验收条件。下图展示了完整的流转链路及各态的核心属性：

1.4 输入输出物

每个中间态对应明确的输入数据与输出产物，如下表所示：

中间态	输入物	输出物	典型存储格式
原始态	客户端/服务端埋点事件	原始日志文件	JSON / CSV / 文本
清洗态	原始日志	标准化明细数据表	Parquet / ORC / Avro
聚合态	清洗后明细数据	汇总指标宽表 / OLAP 数据集	ClickHouse / Doris / 宽表

1.5 责任边界

三种中间态的处理涉及三个核心角色，分工如下：

角色	原始态	清洗态	聚合态
数据产品经理	定义埋点需求与事件规范	定义清洗规则与字段口径	定义指标维度与业务口径
数据开发工程师	采集传输通道建设与运维	清洗ETL开发、调度与监控	聚合ETL开发、OLAP建模
数据分析师	数据探查与异常发现	质量验证与反馈	指标分析与漏斗搭建

1.6 记录材料

每个中间态实例都需要在数据字典中记录以下元数据信息，用于追溯与审计：

字段	说明	示例
状态ID	中间态唯一标识	MID_20240101_001
中间态类型	原始态 / 清洗态 / 聚合态	原始态
数据源	事件来源标识	app_home_page_click
生成时间	状态首次生成的时间戳	2024-01-01 00:00:00
责任人	该状态处理负责人	张三
处理批次	ETL任务批次号或实时管道偏移量	batch_20240101_001 / offset=15230

建议将以上记录存储在统一的元数据平台中，并开放给全团队查询。

1.7 异常处理

在实际数据处理过程中，中间态流转可能出现以下异常情况，需按照既定策略处理：

• 原始态数据缺失或延迟：检查采集链路（SDK → 服务端 → 消息队列 → 存储），确认是否由网络抖动或客户端版本问题导致。处理策略：设置延迟报警阈值（如15分钟未到达），触发补采或重传任务。
• 清洗态数据回退：当清洗ETL发现字段无法解析或数据质量不达标时，应将数据标记为“清洗异常”并退回原始态，同时记录异常原因。处理策略：隔离异常数据进入“脏数据池”，由数据产品经理分析后决定丢弃或修复。
• 聚合态数据跳变：聚合结果出现突增或突降，需反向追溯清洗态和原始态数据，定位是埋点代码变更、清洗规则调整还是真实业务波动。处理策略：启动“数据血缘追溯”流程，逐层下钻分析。
• 跳过清洗态直接聚合：禁止此类操作。若因紧急需求发生，需在聚合表中标注“快速通道”，并在24小时内补做清洗流程，更新聚合结果。

1.8 验收标准

本章内容是否成功落地，通过以下标准进行验证：

• 定义一致：团队中随机抽问3人，能准确说出三种中间态的定义与核心区别。
• 数据可追溯：任意一条埋点数据都能找到其原始态、清洗态、聚合态的三态记录，且时间戳和责任人可查。
• 流转可复现：按照本章操作步骤，从原始日志出发，经清洗ETL和聚合ETL，能稳定产出聚合指标，中间过程无跳步。
• 文档完整性：数据字典中已为每个事件记录三态元数据，包含状态ID、类型、生成时间、责任人、处理批次。
• 异常可闭环：过去一个月内发生的所有中间态异常均有处理记录，且异常处理策略已更新至团队SOP文档。