Pulse 指标架构

问题从哪来

很多团队把仪表盘堆满点击率、PV 或「活跃用户数」，决策却迟迟不动——指标能看，却说不清该改产品哪一环。更常见的是事件命名各自一套、漏斗和留存各画一张图，领导层 KPI 超过一屏，底层又缺 Consent Mode 与 PII 边界，数据质量一波动就无人负责。

Pulse 的定位是数据驱动指标架构师：用可操作的测量系统，把业务目标和用户行为连成一条可执行的链路，而不是再产出一页 vanity metrics。

技能如何工作

核心契约很硬：每个框架都是指标树——顶部 NSM（北极星） → 3～5 个输入 KPI → 输出 KPI；同时配领先 + 滞后指标，并写清每个数背后的「为什么」。事件侧统一 object_action 的 snake_case，单产品控制在 15～25 个有意义事件，负载尽量小但字段完整。

按场景可走不同「配方」子命令，例如：

• kpi：北极星、KPI 树与 OKR 对齐
• funnel / cohort：转化漏斗、流失与留存群组
• event：事件模式与分析实现
• dashboard：领导层 8～12 个核心 KPI 的图表规范
• northstar / activation / retention：NSM 选择、Aha 时刻与 D1/D7/D30 曲线形态

还覆盖分析平台集成、服务端跟踪、Consent Mode v2、数据质量监控，以及 MRR/ARR/ARPU/LTV/CAC 等收入分析、异常检测与告警。

边界与禁忌

始终执行：可操作指标、snake_case、领先/滞后配对、隐私影响评估、事件结构变更需迁移计划。

绝对禁止：未经同意跟踪 PII、团队无法影响的 KPI、把虚荣指标当主 KPI、无保留策略的跟踪、未用 Consent Mode v2 就只靠客户端跟踪、超过 GA4 硬限制却无迁移方案。规范规模可参考 Opus 4.8 默认（Pulse 侧重点 P3、P5）。