第3章 数据口径规范:事件命名、属性定义、归因窗口、计算逻辑
内容产品的度量体系若缺乏统一的数据口径规范,不同业务团队对同一指标的理解可能产生偏差,导致看板数据“对不齐、算不对、说不清”。本章围绕四个核心维度建立规范框架:事件命名、属性定义、归因窗口、计算逻辑。每一维度都直接决定指标的可信度和可复用性。
3.1 事件命名规范
事件是度量体系的最小原子单元。规范命名需遵循“对象+动作+场景”三层结构,避免歧义。
| 层级 | 含义 | 示例 |
|---|---|---|
| 对象 | 行为主体或承载实体 | video, article, comment |
| 动作 | 用户或系统执行的操作 | play, share, delete |
| 场景 | 触发行为的上下文(可选) | home_feed, detail_page, push |
命名原则:全小写英文,下划线分隔,动词过去式。例如
video_played_detail_page,严格禁止混合大小写或使用中文拼音。3.2 属性定义规范
属性承载事件的附加信息,必须明确类型、格式和枚举值。常见分类如下:
- 公共属性:所有事件均携带,如 user_id、device_id、timestamp、app_version。
- 业务属性:特定事件独有,如 video_id、duration_watched、share_platform。
- 维度属性:用于下钻分析,如 content_category、author_type、region。
// 属性定义示例(JSON Schema 片段)
{
"video_played_detail_page": {
"properties": {
"video_id": {"type": "string", "required": true},
"play_duration_s": {"type": "integer", "min": 0},
"play_source": {"enum": ["recommend", "search", "history", "related"]}
}
}
}
常见错误:将枚举值写成不同字符串(如 "IOS" vs "iOS"),或同含义属性在不同事件中类型不一致(如时间戳有时为字符串,有时为 Long)。必须统一使用属性字典进行校验。
3.3 归因窗口规范
归因窗口决定“事件A发生后多久内的事件B可被认定为归因关系”。常见窗口类型:
- 点击归因:曝光后 24 小时内点击算有效。
- 转化归因:最后点击后 7 天内完成购买算归因。
- 内容消费归因:阅读完成后 5 秒内点赞算关联。
| 业务场景 | 推荐窗口 | 说明 |
|---|---|---|
| 信息流推荐 | 30 分钟 | 用户滑动刷新快,窗口过大会引入噪声 |
| 搜索广告 | 7 天 | 决策周期长,需足够窗口覆盖 |
| 内容订阅 | 24 小时 | 推送后短时间内的打开行为具有强相关性 |
3.4 计算逻辑规范
每个指标必须附带完整的计算逻辑说明书,包括分母、分子、去重粒度、时间聚合方式。例如:
指标名称:视频完播率(video_completion_rate)
定义:完整观看视频的用户数 / 点击播放视频的用户数
分子:count(distinct user_id) where playback_progress >= 0.95
分母:count(distinct user_id) where event_name = 'video_played'
归因窗口:无(跨session累加)
时间粒度:自然日
规范强制要求:所有上线看板指标必须经过口径评审,并在看板侧方浮动信息栏中展示“查看口径”入口,点击后直接展示上述结构化定义。
3.5 数据口径规范流程总图
下方流程图展示了从原始事件到指标看板的规范链路,每个环节均需遵循统一的口径定义。
3.6 口径规范的落地检查清单
在每次迭代中,请使用以下清单对新增或修改的指标进行自查:
- 事件名是否符合“对象+动作+场景”命名规范?
- 所有属性是否已在属性字典中注册并注明类型和枚举值?
- 归因窗口是否在业务场景合理范围内,且有文档说明?
- 计算逻辑是否包含分子、分母、去重粒度、时间窗口等完整信息?
- 关键指标是否已通过口径评审会(Review Board)确认?
防过度设计:不要为所有指标都设置超长归因窗口或过细的属性维度,应根据实际数据量和分析成本权衡。建议每季度对口径规范执行一次审计,清理废弃事件和无效属性。