analytics-strategy

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Analytics Strategy

分析策略

Design measurement frameworks that produce decisions, not just dashboards. Stack-agnostic. Tool-agnostic.

This skill is for measurement planning. For conversion optimization, use

cro-optimization

. For SEO measurement specifically, use

seo-onpage

and adjacent SEO skills.

设计能够产出决策而非仅生成仪表板的测量框架。与技术栈无关，与工具无关。

此技能适用于测量规划场景。如需转化优化，请使用

cro-optimization

；如需专门的SEO测量，请使用

seo-onpage

及相关SEO技能。

When to use

使用场景

Setting up analytics on a new product or site
Auditing existing analytics setup
Designing dashboards for a team or business
Defining KPIs and a north star metric
Building event taxonomies for product analytics
Designing attribution models for marketing
Translating business questions into measurement plans

为新产品或网站搭建分析体系
审核现有分析配置
为团队或业务设计仪表板
定义KPI与北极星指标
为产品分析构建事件分类体系
为营销设计归因模型
将业务问题转化为测量计划

When NOT to use

非使用场景

Conversion testing or optimization (use
```
cro-optimization
```
)
SEO performance measurement (use SEO skills)
Pure data infrastructure decisions (different domain)

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

Required inputs

必要输入

The business or product context (what does success look like)
The audience for the analytics (who needs to make what decisions)
The current measurement state (existing tools, tracking, gaps)
The questions the team needs to answer

业务或产品背景（成功的定义是什么）
分析结果的受众（谁需要做出什么决策）
当前测量状态（现有工具、跟踪机制、存在的差距）
团队需要解答的问题

The framework: 4 layers

框架：4个层级

A complete measurement strategy covers all four. Each layer feeds the next.

完整的测量策略涵盖以下四个层级，每个层级为下一层级提供支撑。

1. North star and KPI hierarchy

1. 北极星指标与KPI层级

The single metric that captures the most important outcome, plus the supporting metrics.

North star metric:

One metric. Singular.
Captures customer-perceived value.
Leads to revenue, but isn't revenue itself (revenue is too far downstream).
Examples: weekly active users, completed jobs, revenue-generating sessions, hours of value delivered.

Underneath the north star, the KPI hierarchy:

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)

This is the "AARRR" or "pirate metrics" framework. It works because it covers the full lifecycle.

最核心的单一指标，用于捕捉最重要的业务成果，辅以支撑性指标。

北极星指标：

仅一个指标，单一明确。
捕捉用户感知到的价值。
最终指向营收，但本身并非营收（营收属于下游指标）。
示例：周活跃用户数、完成的任务量、产生营收的会话数、交付的价值时长。

北极星指标之下的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. Event taxonomy

2. 事件分类体系

The vocabulary the product uses to describe what users do.

Event design principles:

Verb + noun.

signed_up

created_project

completed_checkout

. Past tense, snake_case.

One event per discrete action. Not "interacted_with_modal" - too vague. Specifically
```
opened_modal_X
```
,
```
closed_modal_X
```
,
```
confirmed_in_modal_X
```
.
Properties capture context. Each event has properties (key-value pairs) for context.
```
signed_up
```
has properties like
```
signup_method
```
,
```
referrer
```
,
```
plan
```
.
Standardize property names.
```
user_id
```
everywhere, not
```
userId
```
here and
```
id
```
there.
Document everything. A tracking plan that lives nowhere is a tracking plan no one follows.

Event coverage:

All key user actions tracked
All conversion points tracked
All errors tracked
All page views tracked (with consistent properties)
All button clicks that matter (not all button clicks - that's noise)

Anti-patterns:

500+ events with no documentation

Inconsistent naming (

buttonClicked

Button Clicked

clicked_button

)

Property keys that vary across events
Events fired client-side that should be server-side (and vice versa)
PII in event properties (privacy issue and tooling issue)

产品用于描述用户行为的标准化词汇。

事件设计原则：

动词+名词：
```
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. Dashboards and reports

3. 仪表板与报告

The interface between data and decisions.

Dashboard design principles:

One audience per dashboard. Executive dashboard != product team dashboard. Different metrics, different cadence.
One question per chart. A chart should answer one question, not three.
Annotations matter. Note launches, experiments, holidays, outages. A spike means nothing without context.
Context comparisons. "10,000 signups this month" - compared to what? Last month, last year, target?
Lead with the action. What does this dashboard help someone decide?

Common dashboard types:

Dashboard	Audience	Metrics	Cadence
Executive	Leadership	North star, top 3 KPIs, big-picture trends	Weekly review
Product	Product team	Funnel metrics, feature adoption, retention	Daily / weekly
Marketing	Marketing team	Acquisition by channel, CAC, attribution	Daily / weekly
Operations	Ops / on-call	Performance, errors, capacity	Real-time
Custom (per team)	Specific team	Their specific KPIs	Their cadence

数据与决策之间的交互界面。

仪表板设计原则：

每个仪表板对应一类受众：高管仪表板≠产品团队仪表板，指标不同，更新频率也不同。
每个图表解答一个问题：一张图表应只解答一个问题，而非三个。
注释至关重要：标注产品发布、实验、节假日、系统故障。没有上下文的峰值毫无意义。
上下文对比：“本月注册用户10,000人”——和什么对比？上月、去年同期还是目标值？
以行动为导向：此仪表板能帮助人们做出什么决策？

常见仪表板类型：

仪表板类型	受众	指标	更新频率
高管仪表板	领导层	北极星指标、核心3个KPI、宏观趋势	每周回顾
产品仪表板	产品团队	漏斗指标、功能采用率、留存率	每日/每周
营销仪表板	营销团队	渠道获客量、CAC、归因数据	每日/每周
运营仪表板	运维/值班团队	性能、错误、容量	实时
自定义（按团队）	特定团队	他们的专属KPI	团队自定义频率

4. Attribution and segmentation

4. 归因与细分

How to connect cause and effect.

Attribution models:

First-touch. Credit the first interaction. Useful for awareness understanding.
Last-touch. Credit the final interaction before conversion. Default in many tools, often misleading.
Linear. Spread credit equally across touches. Avoids over-crediting any single channel.
Time-decay. Recent touches get more credit. Reasonable middle ground.
Position-based. First and last get more credit, middle touches less.
Data-driven (algorithmic). Tools like Google Analytics 4 use ML. Black box but increasingly the default.

For most businesses: pick one primary attribution model, use multiple secondary models for validation.

Segmentation principles:

Segment by what causes different behavior, not by what's easy to track
Useful segments: source/channel, plan tier, geography, device, cohort (signup date)
Less useful: demographic guesses without behavioral validation

如何建立因果关联。

归因模型：

首次触点归因：将转化功劳归于首次交互。有助于理解品牌认知度。
末次触点归因：将转化功劳归于转化前的最后一次交互。是许多工具的默认设置，但常常具有误导性。
线性归因：将功劳平均分配到所有触点。避免过度归因于单一渠道。
时间衰减归因：近期触点获得更多功劳。是合理的折中方案。
位置加权归因：首次和末次触点获得更多功劳，中间触点获得较少功劳。
数据驱动（算法）归因：Google Analytics 4等工具使用机器学习。属于黑箱模型，但正逐渐成为默认选择。

对于大多数企业：选择一个主要归因模型，同时使用多个次要模型进行验证。

细分原则：

按导致行为差异的因素进行细分，而非按易于跟踪的因素
有用的细分维度：来源/渠道、套餐层级、地域、设备、同期群（注册日期）
较无用的细分：未经行为验证的人口统计学猜测

The tracking plan document

跟踪计划文档

Output of the analytics strategy. A living document.

Structure:

Goals and KPIs. Business objectives, north star, KPI hierarchy.
Event catalog. Every event, with properties, when fired, why tracked.
User properties. Persistent attributes (plan, signup_date, role).
Page taxonomy. Page categories, page properties.
Naming conventions. Snake_case, verb_noun, etc.
Implementation notes. Client-side vs server-side, SDK details, sampling.
Privacy and compliance. PII rules, consent handling, data retention.
Governance. Who can add events, review process, change log.

分析策略的输出成果，是一份动态更新的文档。

结构：

目标与KPI：业务目标、北极星指标、KPI层级。
事件目录：每个事件的详细信息，包括属性、触发时机、跟踪原因。
用户属性：持久化属性（如套餐、注册日期、角色）。
页面分类体系：页面类别、页面属性。
命名规范：蛇形命名法、动词+名词等规则。
实施说明：客户端vs服务端、SDK细节、抽样规则。
隐私与合规：PII规则、同意管理、数据保留政策。
治理机制：谁可以添加事件、审核流程、变更日志。

Workflow

工作流程

Define the questions. What does the team need to answer? Working backward from questions to metrics works better than starting from metrics.
Define the north star. One metric. Tested against the criteria above.
Build the KPI hierarchy. Acquisition, activation, engagement, retention, monetization.
Audit existing tracking. What's there? What's broken? What's missing?
Design the event taxonomy. Cover the user journey. Document everything.
Implement with care. Test each event. Verify properties. Catch issues in staging.
Build dashboards. One per audience. Lead with action.
Establish review cadence. Weekly business review, monthly KPI review, quarterly strategy review.
Govern. Who adds events, who reviews, how changes propagate.

定义问题：团队需要解答哪些问题？从问题倒推指标比从指标出发更有效。
定义北极星指标：确定一个符合上述标准的单一指标。
构建KPI层级：获客、激活、参与、留存、变现。
审核现有跟踪机制：现有哪些跟踪？哪些已损坏？哪些缺失？
设计事件分类体系：覆盖用户旅程，全面文档化。
谨慎实施：测试每个事件，验证属性，在预发布环境中发现问题。
搭建仪表板：为每个受众单独设计，以行动为导向。
建立回顾节奏：每周业务回顾、每月KPI回顾、每季度策略回顾。
治理管理：谁可以添加事件、谁负责审核、变更如何传播。

Failure patterns

失败模式

Tracking everything. Noise overwhelms signal.
Tracking nothing strategic. Page views and that's it. Cannot answer real questions.
No documentation. Tracking plan lives in someone's head.
Inconsistent naming. Same concept, three names. Reports become detective work.
Events fired but never reviewed. Tracking debt accumulates.
Dashboards no one looks at. Built for vanity, not decisions.
Single attribution model treated as truth. All models lie. Some lie usefully.
PII in events. Compliance and tooling problems.
Client-side only. Critical business events should be server-side too. Ad blockers, network issues, edge cases lose client-side events.
No connection to business outcomes. Metrics exist in a silo, never connected to revenue, retention, or strategic decisions.

跟踪一切：噪音掩盖信号。
未跟踪任何战略指标：仅跟踪页面浏览量，无法解答实际业务问题。
无文档记录：跟踪计划仅存在于某个人的脑海中。
命名不一致：同一概念有三个名称，报告变成侦探工作。
事件已触发但从未回顾：跟踪债务不断累积。
无人查看的仪表板：为虚荣指标而建，而非为决策服务。
将单一归因模型视为真理：所有模型都有局限性，部分模型更具实用价值。
事件中包含PII：合规与工具问题。
仅依赖客户端跟踪：关键业务事件也应在服务端触发。广告拦截器、网络问题、边缘情况会导致客户端事件丢失。
与业务成果脱节：指标孤立存在，从未与营收、留存或战略决策关联。

Output format

输出格式

Default output: a markdown tracking plan at

analytics-tracking-plan.md

plus a dashboard inventory.

Tracking plan structure:

markdown

undefined

默认输出：一份Markdown格式的跟踪计划

analytics-tracking-plan.md

，以及一份仪表板清单。

跟踪计划结构：

markdown

undefined

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
...

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]

---

[Process]

---

Reference files

参考文件

```
references/event-taxonomy-template.md
```
- Starter event catalog with patterns for common product types.

```
references/event-taxonomy-template.md
```
- 适用于常见产品类型的事件目录模板。