Skip to content
返回分析与实验

事件设计

设计事件分类 —名、属性、触—使数据可查、一致、且跨产品变耐用

为什么

事件数据是所有分析的原料且坏事件设计毒一切下游。若事件名不一致（"button_click" vs "buttonClicked" vs "cta_click"）每查询须猜命名约定且半数据漏。若属性缺（事件触发无—URL 或用户套餐）事件不可按要紧维度切。若触发错（事件渲染时触发非点击时、把展示算点击）每衍生指标膨胀。事件设计是定一次分类、用 linter 和包装执、并—schema 对待的纪律：版本化、文档、刻意迁移。坏事件设计的成—6 月后才见，分析师—Pro 套餐多少用户点了部署按钮"—不知因点击事件不含套—

何时使用

埋任新功能前。当查询模式频触"无此属—或事件量 > 2x 预期（可能误触发）时重设

如何做

1. 定命名约定：snake_case、verb_noun（如 project_created、deploy_started，非"createProject"—new project"—2. 事件分类定义—schema：每事件有名、描述、触发条件和必属性列—3. 每事件定必属性：user_id、session_id、timestamp（自动）、加事件特定（project_id、plan、page_url、element_id—4. 精定触发—#deploy-button 元素点击时触发、非渲染、非悬停" —不精触发是指标膨胀—#1 —5. 实现类型包装：track("project_created", { projectId, plan }) 包装—schema（TypeScript 类型、dev 运行时验证）
6. —linter 查每 track() 调用—schema —未知事件名或缺属性构建失—7. 在单一登记文档分类（表格或代码文件）为唯一事实—每事件、其属性、其触发、其负责—8. 版本化分类：事件变（新属性、改名）时提版、按需迁历史数据、更新登—9. —dev/staging 加事件于已知动作触发并验事件现带正确属性后上生产

示例

# 事件分类（摘—版本—.2  负责人：@analytics-platform

event: project_created
  描述：用户建新项—  触发：成—POST /api/projects—00 响应）时
  必：user_id、session_id、project_id、plan、template_id
  选：source（modal|dashboard|api—  版本—.2（v1.2 —template_id—
event: deploy_started
  描述：用户点部署按钮
  触发：点 [data-testid="deploy-button"] —  必：user_id、session_id、project_id、deploy_target
  选：is_redeploy（bool—  版本—.0（v2.0 —deploy"改名—
// 类型包装（TypeScript—track("project_created", {
  projectId: "prj_abc",    // —  plan: "pro",             // —  templateId: "tpl_blank", // 必（v1.2+—  source: "modal",         // " });
// Linter：若 projectId —plan —-> 构建失败
// Linter：若事件名不—schema -> 构建失败

// 反模式（linter 捕）—track("createProject", { id: "abc" });
// -> 错：事件"createProject"不在 schema
// -> 你是—project_created"—// -> 缺必：user_id、session_id、plan、template_id

常见问题

  • ⚠跨团队名不一—A 团队—button_click"、B —buttonClicked"、C —cta_click"且每查询须查三者、漏用第四约定无人文档的事件
  • ⚠渲染时触发非交互—"deploy_clicked"事件在部署按钮渲染时触发非用户点击时，故展示和点击混—CTR 100%
  • ⚠缺可切属—事件触发—user_id —timestamp 但无 plan —source，故"按套餐转—按来源转—不可答且数据对业务问题无用
  • ⚠—linter —schema —开发者加新属性于一调非另、或拼错事件名且 schema 是建议非规则；漂数月后查询返空时才发现

最佳实践

  • ✓定类型包装和构建时执 schema —linter —linter —schema 有约束力；无—schema 是漂的文档且数据质量静腐
  • ✓用单一命名约定（snake_case、verb_noun）跨所有团队执 —一致比具体约定更有值且拒非约定名的 linter 是你如何执
  • ✓精定触发—[data-testid=X] —部署按钮—）—不精触发是指标膨胀 #1 因且精度防渲—点击混淆
  • ✓版本化分类并刻意—事件变时版本提、按需迁历史数据、更新登记；此使数据跨产品变耐用