第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 数据口径规范流程总图

下方流程图展示了从原始事件到指标看板的规范链路,每个环节均需遵循统一的口径定义。

数据口径规范流程 原始事件 原始日志 事件命名规范 对象+动作+场景 属性定义规范 类型/枚举/校验 归因窗口 点击/转化/消费 计算逻辑 分子/分母/去重 指标看板 口径一致/可追踪 关键原则 1. 全局唯一事件ID 2. 属性字典统一管理 3. 窗口参数可配置 每个环节都必须经过评审委员会确认,方可进入开发

3.6 口径规范的落地检查清单

在每次迭代中,请使用以下清单对新增或修改的指标进行自查:

  1. 事件名是否符合“对象+动作+场景”命名规范?
  2. 所有属性是否已在属性字典中注册并注明类型和枚举值?
  3. 归因窗口是否在业务场景合理范围内,且有文档说明?
  4. 计算逻辑是否包含分子、分母、去重粒度、时间窗口等完整信息?
  5. 关键指标是否已通过口径评审会(Review Board)确认?
防过度设计:不要为所有指标都设置超长归因窗口或过细的属性维度,应根据实际数据量和分析成本权衡。建议每季度对口径规范执行一次审计,清理废弃事件和无效属性。