事件跟踪计划和治理
事件跟踪计划是应用程序代码和使用遥测技术的人员之间的可审查合同。它解释了一行的含义、事件存在的原因、允许哪些字段、谁拥有更改以及如何验证事件。如果没有该合同，技术上有效的 JSON 有效负载仍然可能产生误导性的价格、破损的漏斗、隐私风险或无人拥有的仪表板。
每个事件合约使用一行：
| 领域 | 示例 |
|---|---|
| 活动名称 | checkout_completed |
| 谷物 | 所有内部尝试后的一次逻辑检查 |
| 决定 | 识别终端故障较多的结账步骤 |
| 业主 | 支付工程 |
| 触发 | 成功或最终失败 |
| 必填字段 | event_id、status、checkout_step、duration_ms、timestamp_utc |
| 可选字段 | account_id、plan、release、error_type |
| 禁止内容 | 付款详细信息、电子邮件、请求正文、原始错误消息 |
| 保留率 | 产品认可的操作窗口 |
| 架构版本 | 1 |
| 消费者 | 检查可靠性仪表板和终端故障告警 |
| 验证 | 综合成功、失败、超时、重试和重复赛程 |
在字段之前定义含义
从决定和谷物开始。 “结帐事件”含糊不清。 “在所有内部尝试之后进行一次逻辑检查”告诉审阅者 COUNT(*) 代表什么以及重试是否应该创建额外的行。
写出最终结果和排除情况。如果无法观察到放弃的结帐，请说明该限制。如果在异步履行步骤之前发出成功事件，请勿将其标记为 checkout_completed。
对每个领域进行分类
对于每个字段，记录：
- 类型和单位
- 必需、可选或有条件必需的状态
- 允许值或最大长度
- 真理的来源
- 无论是个人的、假名的、敏感的还是不受限制的
- 目的：过滤、分组、连接、计算、关联或调试
- 当值不可用时的行为
对 status、error_type、feature 和其他分组维度使用受控分类法。仅当批准的调查或联接使用高基数标识符时才保留它们。禁止任意嵌套有效负载和无界字符串。
记录下游依赖关系
列出取决于事件的已保存查询、仪表板、告警、导出、实验和报告。在这些使用者被更新或有意版本控制之前，字段重命名是不完整的。
对于每个操作查询，记录其分母、时区、迟到政策、重试处理、最小数量和预期固定结果。该计划应链接到查询或相关的 SQL配方，而不是重述未记录的指标名称。
在合同变更时审查变更
添加可选字段通常比更改现有含义更安全。当类型、单位、粒度或类别含义发生变化时，使用新的字段或架构版本。推出期间：
- 更新跟踪计划并获得所需的审查。
- 添加或更新确定性装置。
- 部署具有向后兼容字段的生产者。
- 检查架构和空率。
- 更新消费者。
- 仅在历史和部署窗口允许后才删除兼容性逻辑。
在准备好每个运行时并记录回退计划之前，切勿强制执行新引入的配置值。
指定操作节奏
按计划和事件发生后审查关键计划。查找未使用的字段、无主仪表板、类别爆炸、空值率上升、意外的模式版本以及不再具有合理用途的标识符。删除或缩短不再带来成本和风险的数据保留时间。