analytics-strategy

分析策略

设计能够推动决策，而不只是生成仪表板的衡量框架。与技术栈无关，与工具无关。

此技能用于规划衡量方案。若要优化转化，请使用 cro-optimization。若要专门衡量 SEO，请使用 seo-onpage 及相关 SEO 技能。

---

适用场景

• 为新产品或网站搭建分析体系
• 审查现有的分析设置
• 为团队或企业设计仪表板
• 定义 KPI 和北极星指标
• 为产品分析构建事件分类体系
• 为营销设计归因模型
• 将业务问题转化为衡量方案

不适用场景

• 转化测试或优化（使用 cro-optimization）
• SEO 效果衡量（使用 SEO 技能）
• 纯数据基础设施决策（属于不同领域）

---

必需输入

• 业务或产品背景（成功是什么样的）
• 分析的受众（谁需要做出什么决策）
• 当前的衡量状况（现有工具、跟踪方式和缺口）
• 团队需要回答的问题

---

框架：4 个层次

完整的衡量策略应涵盖全部 4 个层次。每个层次都为下一层提供依据。

1. 北极星指标与 KPI 层级

一个能够体现最重要成果的指标，以及为其提供支撑的指标。

北极星指标：

• 只能有一个指标。
• 体现客户感知到的价值。
• 能够带来收入，但本身不是收入（收入离实际行动太远）。
• 示例：每周活跃用户数、已完成的工作数、产生收入的会话数、交付价值的小时数。

北极星指标之下的 KPI 层级：

North star metric
├── Acquisition KPI (how new users enter)
├── Activation KPI (when new users get value)
├── Engagement KPI (how often users return)
├── Retention KPI (how many stick over time)
└── Monetization KPI (how value translates to revenue)

这就是“AARRR”或“海盗指标”框架。它之所以有效，是因为涵盖了完整的生命周期。

2. 事件分类体系

产品用来描述用户行为的一套词汇。

事件设计原则：

• 动词 + 名词。 signed_up、created_project、completed_checkout。使用过去时和 snake_case。
• 每个独立操作对应一个事件。 不要使用过于模糊的 interacted_with_modal。应具体使用 opened_modal_X、closed_modal_X、confirmed_in_modal_X。
• 属性用于捕获上下文。 每个事件都包含用于描述上下文的属性（键值对）。signed_up 可包含 signup_method、referrer、plan 等属性。
• 统一属性名称。 到处都用 user_id，不要一处用 userId，另一处用 id。
• 记录所有内容。 无处存放的跟踪计划，无人会遵循。

事件覆盖范围：

• 跟踪所有关键用户操作
• 跟踪所有转化点
• 跟踪所有错误
• 跟踪所有页面浏览（属性保持一致）
• 跟踪所有重要的按钮点击（不是所有按钮点击，那些只会制造噪声）

反模式：

• 有 500 多个事件，却没有文档
• 命名不一致（buttonClicked、Button Clicked、clicked_button）
• 不同事件使用不同的属性键
• 在客户端触发本应在服务端触发的事件（反之亦然）
• 在事件属性中包含 PII（隐私问题和工具问题）

3. 仪表板和报告

连接数据与决策的界面。

仪表板设计原则：

• 每个仪表板面向一个受众。 高管仪表板 != 产品团队仪表板。指标不同，更新频率也不同。
• 每张图表只回答一个问题。 一张图表应该回答一个问题，而不是三个。
• 注释很重要。 记录发布、实验、节假日和故障。没有上下文，数据峰值毫无意义。
• 提供对比背景。“本月有 10,000 次注册”——与什么相比？上个月、去年，还是目标？
• 以行动为先。 这个仪表板能帮助人们做出什么决策？

常见的仪表板类型：

仪表板	受众	指标	更新频率
高管	领导层	北极星指标、排名前三的 KPI、宏观趋势	每周回顾
产品	产品团队	漏斗指标、功能采用率、留存率	每日 / 每周
营销	营销团队	各渠道获客、CAC、归因	每日 / 每周
运营	运营 / 值班人员	性能、错误、容量	实时
自定义（按团队）	特定团队	团队自己的 KPI	按团队节奏

4. 归因与细分

了解如何关联因果。

归因模型：

• 首次触点。 将功劳归于首次互动。适用于了解认知度。
• 末次触点。 将功劳归于转化前的最后一次互动。许多工具的默认设置，但往往会造成误导。
• 线性。 将功劳平均分配给所有触点。避免过度归功于某个渠道。
• 时间衰减。 越近期的触点获得的功劳越多。较为合理的折中方案。
• 基于位置。 首次和末次触点获得更多功劳，中间的触点获得较少。
• 数据驱动（算法）。 Google Analytics 4 等工具使用 ML。虽然是黑盒，但正逐渐成为默认选择。

对大多数企业来说：选定一个主要归因模型，并使用多个次要模型进行验证。

细分原则：

• 按会导致行为不同的因素细分，而不是按容易追踪的因素细分
• 有用的细分维度：来源 / 渠道、套餐等级、地理位置、设备、群组（注册日期）
• 用处较小的维度：未经行为验证的人口统计推测

---

追踪计划文档

分析策略的产出。一份持续更新的文档。

结构：

1. 目标和 KPI。 业务目标、北极星指标、KPI 层级。
2. 事件目录。 每个事件及其属性、触发时机和追踪原因。
3. 用户属性。 持久属性（套餐、signup_date、角色）。
4. 页面分类体系。 页面类别、页面属性。
5. 命名约定。 Snake_case、verb_noun 等。
6. 实施说明。 客户端与服务端、SDK 详情、采样。
7. 隐私与合规。 PII 规则、同意处理、数据保留。
8. 治理。 谁可以添加事件、审核流程、变更日志。

---

工作流

1. 明确问题。 团队需要回答什么问题？从问题倒推指标，比从指标入手更有效。
2. 定义北极星指标。 选定一个指标，并根据上述标准进行检验。
3. 构建 KPI 层级。 获客、激活、参与、留存、变现。
4. 审查现有追踪。 已经有哪些？哪些已损坏？缺少哪些？
5. 设计事件分类体系。 覆盖用户旅程。记录所有内容。
6. 谨慎实施。 测试每个事件。验证属性。在预发布环境中发现问题。
7. 构建仪表板。 每个受众对应一个。以行动为先。
8. 建立审查节奏。 每周业务回顾、每月 KPI 回顾、每季度战略回顾。
9. 进行治理。 谁添加事件、谁负责审核，以及如何传递变更。

---

失败模式

• 什么都追踪。 噪声淹没信号。
• 没有追踪任何战略性指标。 只有页面浏览量，除此之外一无所有。无法回答真正的问题。
• 没有文档。 追踪计划只存在于某个人的脑海里。
• 命名不一致。 同一个概念有三种名称。生成报告变成了侦探工作。
• 事件已触发，却从未审查。 追踪债务不断累积。
• 无人查看的仪表板。 为虚荣指标而建，而非用于决策。
• 把单一归因模型当成真相。 所有模型都会说谎，有些谎言有用。
• 事件中包含 PII。 会带来合规和工具方面的问题。
• 仅在客户端追踪。 关键业务事件也应在服务端追踪。广告拦截器、网络问题和边缘情况会导致客户端事件丢失。
• 与业务成果脱节。 指标各自为政，从未与收入、留存或战略决策关联起来。

---

输出格式

默认输出：位于 analytics-tracking-plan.md 的 Markdown 追踪计划，以及一份仪表板清单。

追踪计划结构：

# Tracking Plan

## North star metric
[Definition, calculation, target]

## KPI hierarchy
[Each KPI with definition, calculation, owner]

## Event catalog
| Event | When fired | Properties | Owner | Status |
|---|---|---|---|---|
| user_signed_up | After successful signup form submit | source, plan, referrer | Marketing | Live |
| project_created | When user clicks Create Project | project_type, template_used | Product | Live |
| ... | | | | |

## User properties
[List with definitions]

## Naming conventions
[Rules]

## Privacy and compliance
[Rules]

## Governance
[Process]

---

参考文件

• references/event-taxonomy-template.md - 包含常见产品类型模式的事件目录入门模板。