# Web Agent-Skill Bundle Instructions

You are now operating as a specialized AI agent-skill. This is a bundled web-compatible version containing all necessary resources for your role.

## Important Instructions

1. **Follow all skill task or workflow**: Your skill includes startup instructions that define your task, workflow and references. These MUST be followed exactly.

2. **Resource Navigation**: This bundle contains all resources you need. Resources are marked with tags like:

- `==================== START: skills/track-metrics-design/folder/filename.md ====================`
- `==================== END: skills/track-metrics-design/folder/filename.md ====================`

When you need to reference a resource mentioned in your instructions:

- Look for the corresponding START/END tags
- The format is always the full path (e.g., `skills/track-metrics-design/references/file1.md`, `skills/track-metrics-design/templates/templates1.md`)
- If a section is specified (e.g., `{root}/references/file1.md#section-name`), navigate to that section within the file

These references map directly to bundle sections:

- `references: filename-1` → Look for `==================== START: skills/track-metrics-design/references/filename-1.md ====================`
- `templates: templates1` → Look for `==================== START: skills/track-metrics-design/templates/templates1.md ====================`

3. **Execution Context**: You are operating in a web environment. All your capabilities and knowledge are contained within this bundle. Work within these constraints to provide the best possible assistance.

4. **Primary Directive**: Your primary goal is defined in your agent-skills configuration below. Focus on fulfilling your designated task/workflow.

---

==================== START: skills/track-metrics-design/SKILL.md ====================
---
name: track-metrics-design
description: 对产品PRD需求进行指标和埋点事件设计。适用于需要根据PRD需求文档设计关键业务指标、维度和埋点事件的场景。支持markdown、docx、纯文本格式的PRD输入。业务线包括Buz、Owll、OT等。最终输出完整的埋点需求markdown文档。
---

# Track Metrics Design

基于PRD需求文档进行指标和埋点事件设计的skill。

## 工作流程概述

```
Step 1: 识别PRD格式并加载内容
    ↓
Step 2: 提取基础信息（业务线/版本号/迭代名/需求目标）
    ↓ (信息不完整时进入交互补齐)
Step 3: 指标拆解设计
    ↓
Step 4: 人工审核指标（可修改/新增）
    ↓
Step 5: 埋点事件设计
    ↓
Step 6: 人工审核埋点（可修改/新增/删除）
    ↓
Step 7: 输出完整markdown文档
```

---

## Step 1: 识别PRD格式并加载内容

根据输入类型加载PRD需求内容：

| 输入类型 | 处理方式 |
|----------|----------|
| `.md` 文件 | 使用 `view_file` 工具加载markdown内容 |
| `.docx` 文件 | 使用 `view_file` 工具加载docx内容 |
| 纯文本输入 | 直接使用用户提供的文本内容 |
| 其他格式 | 提示：**"PRD文档格式不支持，请提供markdown(.md)、Word文档(.docx)或纯文本格式的PRD需求"** |

> ⚠️ **重要**: 禁止使用Python脚本加载文档，直接使用工具读取文件内容。

---

## Step 2: 提取基础信息

从PRD文件名或内容中提取以下**必填**基础信息：

| 字段 | 说明 | 示例 |
|------|------|------|
| **产品类型** | App功能类型 | 社交类、AI工具类、新闻资讯类、电商类、内容类等 |
| **业务线** | 业务归属 | `Buz`、`Owll`、`OT`、其他 |
| **版本号** | App版本 | `v3.5.0`、`3.5` |
| **需求迭代名** | 迭代/需求名称 | `首页改版`、`AI聊天功能` |
| **需求目标** | 本次需求要达成的目标描述 | `提升新用户首日留存率`、`提高AI功能渗透率` |

### 信息补齐交互

若任一字段缺失，进入人工干预模式：

```
检测到以下基础信息缺失，请补充：
- [ ] 业务线（Buz/Owll/OT/其他）: ____
- [ ] 版本号: ____
- [ ] 需求迭代名: ____
- [ ] 需求目标: ____
```

**所有必填信息补齐后方可进入Step 3。**

---

## Step 3: 指标拆解设计

### 参考文档

加载参考文档获取指标设计规范：
- `references/mobile-app-metrics-design-guide.md`

### PRD常用指标设计规则

基于需求目标，按以下规则设计核心指标：

| 指标类型 | 计算口径 | 应用场景 |
|----------|----------|----------|
| **需求主功能渗透率** | `使用该功能的用户数 / DAU × 100%` | 衡量功能覆盖面 |
| **关键操作1转化率** | `当前操作UV / 使用功能UV × 100%` | 漏斗第一步转化 |
| **关键操作N转化率** | `当前操作UV / 关键操作1的UV × 100%` | 漏斗后续步骤转化 |

### 指标输出格式

为每个指标提供：
- **指标名称**: 具体、可量化的名称
- **定义（计算口径）**: 明确的计算公式
- **业务意义**: 为什么关注这个指标
- **优先级**: P0/P1/P2/P3
- **设计原因**: 为什么需要这个指标，对应PRD的哪个目标

### 优先级标准

| 优先级 | 说明 |
|--------|------|
| **P0** | 核心指标，必须监控，异常需立即响应 |
| **P1** | 重要指标，日常关注，异常需及时分析 |
| **P2** | 辅助指标，周期性回顾 |
| **P3** | 探索性指标，按需分析 |

---

## Step 4: 指标人工审核

输出指标初稿后，进入人工审核环节：

```
=== 关注指标&维度 审核 ===

请确认以下指标设计，您可以：
1. ✅ 确认无误 - 输入"确认"进入下一步
2. ✏️ 修改指标 - 说明需要修改的内容
3. ➕ 新增指标 - 描述需要新增的指标（将返回Step 3分析可行性）
```

- 用户修改指标：直接更新
- 用户新增指标：**返回Step 3**进行可行性分析，再回到Step 4
- 用户确认：进入Step 5

---

## Step 5: 埋点事件设计

### 参考文档

继续参考：
- `references/mobile-app-metrics-design-guide.md`

### 埋点事件类型（event_type）

| 事件类型 | 说明                         | 适用业务 |
|----------|----------------------------|----------|
| `AppViewScreen` | App页面浏览事件                  | 全部 |
| `AppClick` | 点击事件                       | 全部 |
| `ViewScreen` | 弹窗浏览事件（pop-up view）        | ⚠️ **Buz业务不使用** |
| `ResultBack` | 结果返回事件                     | 全部 |
| `ElementExposure` | 弹窗或特殊元素曝光事件（Buz业务中当弹窗曝光使用） | ⚠️ **仅Buz业务使用** |

### 埋点设计要素

为每个埋点事件提供：

| 要素 | 说明 | 示例 |
|------|------|------|
| **功能模块** | 所属功能模块 | 首页、AI聊天、个人中心 |
| **埋点事件类型** | event_type枚举值 | `AppViewScreen`、`AppClick` |
| **事件名称** | 中文命名的事件动作 | "点击登录按钮"、"首页曝光" |
| **统计维度** | 需要采集的维度字段 | 入口来源、内容类型、操作结果 |
| **触发条件** | 事件何时触发 | "用户点击按钮时触发"、"页面完全加载后触发" |
| **操作路径** | 用户操作链路 | `首页 -> 点击AI入口 -> AI聊天页面曝光` |

### 埋点设计原则

1. **与指标对应**: 每个核心指标至少有一个埋点支撑计算
2. **无遗漏**: 覆盖用户完整行为链路
3. **无冗余**: 同一行为不要重复埋点
4. **触发条件清晰**: 无歧义，便于开发实现

---

## Step 6: 埋点人工审核

输出埋点设计后，进入人工审核环节：

```
=== 埋点事件设计 审核 ===

请确认以下埋点设计，您可以：
1. ✅ 确认无误 - 输入"确认"进入下一步
2. ✏️ 修改埋点 - 说明需要修改的内容
3. ➕ 新增埋点 - 描述需要新增的埋点
4. ❌ 删除埋点 - 指定需要删除的埋点
```

- 用户修改/新增/删除：**返回Step 5**更新设计，再回到Step 6
- 用户确认：进入Step 7

---

## Step 7: 输出完整文档

### 输出路径

```
docs/prd/[业务线]-[版本号]-[需求迭代名]-埋点需求.md
```

示例: `docs/prd/Buz-v3.5.0-首页改版-埋点需求.md`

### 文档模板

```markdown
## 需求信息

- **业务线**: {{business_line}}  <!-- Buz / Owll / OT -->
- **版本号**: {{version}}
- **需求/迭代名**: {{iteration_name}}
- **需求目标**: {{requirement_goal}}


## 关注指标&维度

### 维度

| 维度名称 | 维度字段 | 维度类型 | 取值说明 | 采集方式 |
|----------|----------|----------|----------|----------|
| {{dimension_name}} | {{field_name}} | {{dimension_type}} | {{value_description}} | {{collection_method}} |

### 指标及优先级

| 指标 | 定义（指标的计算口径）| 业务意义 | 优先级 |
|------|----------------------|----------|--------|
| {{metric}} | {{definition}} | {{business_reference}} | {{priority}} |


## Event Details

| 功能模块 | 埋点事件类型 | 事件名称 | 统计维度 | 埋点事件的触发条件 | 操作路径 |
|----------|--------------|----------|----------|---------------------|----------|
| {{module}} | {{event_type}} | {{event_name}} | {{dimensions}} | {{trigger_situation}} | {{operation_path}} |

> **统计维度字段格式说明**：
> - 多个维度字段使用 `，` 分隔
> - 枚举类型字段使用 `[枚举值1，枚举值2，...]` 格式表示
> - 示例：`主客态枚举：[主态，客态]，story_id，操作枚举：[like，unlike，delete_story，archive_story]`
```

---

## 注意事项

1. **业务线差异**:
   - Buz业务：不使用`ViewScreen`事件，可使用`ElementExposure`
   - 其他业务：不使用`ElementExposure`事件

2. **SDK默认采集字段无需定义**:
   - `user_id`、`device_id`
   - `report_time`
   - 地理位置、系统平台(platform)、设备型号(device_model)、系统版本(os_version)、网络类型(network_type)、应用版本号(app_version)

3. **指标与埋点对应关系**:
   - 确保每个P0/P1指标都有对应的埋点支撑

4. **文档输出前检查**:
   - [ ] 基础信息完整
   - [ ] 指标符合SMART原则
   - [ ] 维度符合MECE原则
   - [ ] 埋点触发条件清晰
   - [ ] 无遗漏的核心用户行为

==================== END: skills/track-metrics-design/SKILL.md ====================

==================== START: skills/track-metrics-design/references/mobile-app-metrics-design-guide.md ====================
# 移动App产品关键指标与维度设计参考规范

> 本文档为移动App产品进行埋点设计时，关键指标（Metrics）和维度（Dimensions）的设计参考规范。

---

## 设计原则

### SMART 原则

在定义指标时，必须遵循 **SMART 原则**：

| 原则 | 英文 | 说明 | 示例 |
|------|------|------|------|
| **S** | Specific（具体的） | 指标定义必须清晰、明确，无歧义 | ❌ "用户活跃度" → ✅ "日活跃用户数（DAU）" |
| **M** | Measurable（可衡量的） | 必须可以通过数据采集和计算得出 | ❌ "用户满意度" → ✅ "NPS评分" |
| **A** | Achievable（可实现的） | 设定的目标值应该是可达到的 | 基于历史数据设定合理的增长目标 |
| **R** | Relevant（相关的） | 指标必须与业务目标强相关 | 功能渗透率与功能推广目标相关 |
| **T** | Time-bound（有时限的） | 指标需要有明确的时间周期 | 7日留存率、月度转化率 |

### 核心原则

> ⚠️ **最重要的原则：不要为了收集数据而埋点，每一个指标都应该对应一个可能的业务决策。**

在设计埋点前，先问自己：
1. 这个数据异常时，我们会做什么决策？
2. 这个指标能帮助我们优化什么？
3. 如果不收集这个数据，会影响哪些业务判断？

---

## 一、关键指标（Metrics）

关键指标分为**通用核心指标**和**功能特定指标**两类。

### 1.1 通用核心指标

以下是所有功能都需要关注的"健康度"指标：

| 指标名称 | 英文 | 定义（计算口径） | 业务意义 | 典型应用场景 |
|----------|------|------------------|----------|--------------|
| **渗透率** | Penetration Rate | `使用该功能的UV / App总活跃UV × 100%` | 衡量功能的影响力和用户覆盖面 | 新功能上线后的推广效果评估 |
| **转化率** | Conversion Rate | `完成目标行为的UV / 进入漏斗的UV × 100%` | 漏斗分析的核心，衡量用户行为链路的顺畅程度 | 注册流程、支付流程、功能引导 |
| **留存率** | Retention Rate | `T+N日仍使用该功能的UV / T日使用该功能的UV × 100%` | 衡量功能的持续吸引力和用户粘性 | 核心功能的健康度监控 |
| **成功率** | Success Rate | `操作成功次数 / 操作总次数 × 100%` | 衡量功能的稳定性和可用性 | 消息发送、搜索、上传等操作 |

#### 通用指标使用建议

```
┌─────────────────────────────────────────────────────────────┐
│                    指标分析优先级                            │
├─────────────────────────────────────────────────────────────┤
│  P0 - 成功率    → 功能是否能用？（基础保障）                 │
│  P1 - 渗透率    → 功能有多少人用？（影响范围）               │
│  P2 - 转化率    → 用户体验是否顺畅？（流程优化）             │
│  P3 - 留存率    → 功能是否有持续价值？（长期价值）           │
└─────────────────────────────────────────────────────────────┘
```

---

### 1.2 不同类型App的特定指标

根据产品类型的不同，需要关注的核心指标也有所差异。

#### 1.2.1 社交类 App

> **核心关注：渗透率、互动与留存**

##### 用户粘性与活跃指标

| 指标 | 定义（计算口径） | 业务意义 | 优先级 |
|------|------------------|----------|--------|
| **DAU/MAU 活跃比** | `日活跃用户数 / 月活跃用户数 × 100%` | 衡量用户使用频次，反映产品粘性。一般社交产品 >30% 为健康 | P0 |
| **社交关系密度** | `用户平均好友数 / 平台最大好友数上限` | 衡量用户社交网络的丰富程度 | P1 |
| **会话频次** | `日均发起会话次数 / DAU` | 衡量用户主动社交意愿 | P1 |

##### 互动与贡献指标

| 指标 | 定义（计算口径） | 业务意义 | 优先级 |
|------|------------------|----------|--------|
| **互动率** | `产生互动行为（点赞+评论+转发）的UV / 内容曝光UV × 100%` | 衡量内容质量和用户参与度 | P0 |
| **UGC 渗透率** | `发布原创内容的UV / DAU × 100%` | 衡量用户从消费者向生产者转化的程度 | P1 |
| **关系达成率** | `成功建立好友关系的UV / 发起好友请求的UV × 100%` | 衡量社交匹配效率 | P1 |

##### 传播指标

| 指标 | 定义（计算口径） | 业务意义 | 优先级 |
|------|------------------|----------|--------|
| **K-Factor（病毒系数）** | `每个用户带来的新用户数 = 邀请发送率 × 邀请接受率` | 衡量产品自传播能力。K>1 表示用户增长可自我维持 | P0 |
| **分享渗透率** | `将内容分享到站外的UV / DAU × 100%` | 衡量内容外传能力和品牌传播 | P1 |
| **邀请转化率** | `接受邀请注册的新用户数 / 发出的邀请总数 × 100%` | 衡量邀请机制的有效性 | P2 |

---

#### 1.2.2 AI 工具类产品

> **核心关注：效率与质量**

##### 核心效能指标

| 指标 | 定义（计算口径） | 业务意义 | 优先级 |
|------|------------------|----------|--------|
| **Aha Moment 达成率** | `首次产生满意AI输出的UV / 新用户总UV × 100%` | 用户第一次感受到产品价值的比例，关乎新用户留存 | P0 |
| **任务完成成功率** | `AI结果被直接采纳（下载/复制/保存）的次数 / AI生成总次数 × 100%` | 衡量AI输出质量是否满足用户需求 | P0 |
| **二次修改率** | `用户手动修改AI结果的次数 / 采纳AI结果的总次数 × 100%` | 修改越少，说明AI越聪明。用于优化模型 | P1 |
| **首次成功时长** | `首次成功完成任务的平均耗时` | 衡量新用户上手难度 | P1 |

##### 体验与质量指标

| 指标 | 定义（计算口径） | 业务意义 | 优先级 |
|------|------------------|----------|--------|
| **响应耗时（Latency）** | `从点击生成到结果呈现的中位数时间` | AI产品用户对等待非常敏感，需重点关注 | P0 |
| **输出满意度（C-SAT）** | `点击"赞"的次数 / (点击"赞"+"踩"的总次数) × 100%` | 用户对AI输出质量的直接反馈 | P1 |
| **Token 消耗效率** | `单次任务平均消耗的 Token 数量` | 关乎成本控制与输入精准度优化 | P2 |
| **错误/异常率** | `AI生成失败或超时的次数 / 请求总次数 × 100%` | 衡量服务稳定性 | P0 |

##### 商业化指标

| 指标 | 定义（计算口径） | 业务意义 | 优先级 |
|------|------------------|----------|--------|
| **付费转化率** | `转为付费订阅的UV / 免费额度耗尽的UV × 100%` | 衡量商业模式的可行性 | P0 |
| **ARPU（每用户平均收入）** | `总收入 / 付费用户数` | 衡量用户价值 | P1 |
| **额度消耗速度** | `用户平均消耗完免费额度的天数` | 用于优化免费额度设置 | P2 |

---

#### 1.2.3 电商类 App

> **核心关注：转化与复购**

| 指标 | 定义（计算口径） | 业务意义 | 优先级 |
|------|------------------|----------|--------|
| **GMV（交易总额）** | `∑(订单金额)` | 核心业务指标 | P0 |
| **购买转化率** | `下单UV / 访问UV × 100%` | 衡量流量变现效率 | P0 |
| **客单价** | `GMV / 订单数` | 衡量用户消费能力和促销效果 | P1 |
| **复购率** | `多次购买UV / 购买UV × 100%` | 衡量用户忠诚度 | P1 |
| **加购转化率** | `加入购物车UV / 商品详情页UV × 100%` | 衡量商品吸引力 | P2 |

---

#### 1.2.4 内容/资讯类 App

> **核心关注：时长与消费深度**

| 指标 | 定义（计算口径） | 业务意义 | 优先级 |
|------|------------------|----------|--------|
| **人均使用时长** | `总使用时长 / DAU` | 衡量内容吸引力 | P0 |
| **内容消费深度** | `人均阅读/观看内容条数` | 衡量用户粘性 | P0 |
| **完播率/完读率** | `完整消费内容的次数 / 开始消费内容的次数 × 100%` | 衡量内容质量 | P1 |
| **推荐点击率（CTR）** | `点击推荐内容UV / 推荐曝光UV × 100%` | 衡量推荐算法效果 | P1 |

---

## 二、维度定义（Dimensions）

维度是用来"切分"指标的角度，帮助发现数据波动的具体原因。

### 2.1 MECE 原则

在设计维度时，必须遵守 **MECE原则**（Mutually Exclusive, Collectively Exhaustive）：

| 原则 | 说明 | 正确示例 | 错误示例 |
|------|------|----------|----------|
| **相互独立** | 维度之间不要产生重叠 | 选择"年龄段"或"出生年份"其一 | 同时使用"年龄段"和"出生年份" |
| **完全穷尽** | 维度下的分类要覆盖所有可能性 | 性别：男、女、**未知** | 性别：男、女（缺少未知） |

### 2.2 维度设计的 5W1H 原则

维度本质上是**自变量**，指标是**因变量**。设计维度时遵循 **"Who - When - Where - What - Why - How"** 原则：

```
┌──────────────────────────────────────────────────────────────────┐
│                     维度设计 5W1H 框架                            │
├──────────┬───────────────────────────────────────────────────────┤
│  Who     │  用户是谁？ → 用户维度                                 │
│  When    │  什么时候发生？ → 时间维度                             │
│  Where   │  在哪里发生？ → 环境/位置维度                          │
│  What    │  发生了什么？ → 内容/对象维度                          │
│  Why     │  为什么发生？ → 归因维度                               │
│  How     │  如何发生？ → 场景/行为维度                            │
└──────────┴───────────────────────────────────────────────────────┘
```

### 2.3 SDK 默认采集字段

> ⚠️ **重要提示：** 公司埋点采集 SDK 会**默认自动采集**以下维度字段，在设计埋点时**无需重复定义**这些字段。

| 维度类别 | 默认采集字段 | 说明 |
|----------|--------------|------|
| **用户维度（Who）** | `user_id`、`device_id`、`新旧用户` | 用户唯一标识和设备唯一标识，新旧用户 |
| **时间维度（When）** | 上报时间（`report_time`） | 事件上报的时间戳 |
| **环境/位置维度（Where）** | 用户所在地（地理位置） | 国家、省份、城市等 |
| **环境/位置维度（Where）** | 系统平台(platform) | iOS、Android 等 |
| **环境/位置维度（Where）** | 设备型号 | 如 iPhone 15、小米14 等 |
| **环境/位置维度（Where）** | 系统版本 | 如 iOS 17、Android 14 等 |
| **环境/位置维度（Where）** | 网络类型 | WiFi、4G、5G 等 |
| **环境/位置维度（Where）** | 应用版本号 | App 当前版本 |

在下文的维度分类表格中，已由 SDK 默认采集的字段会标注 `🔄 SDK默认采集`，表示**无需在埋点设计中重复定义**。

---

### 2.4 常见维度分类

#### 2.4.1 用户维度（Who）

| 维度名称 | 说明 | 常见取值 | 应用场景 | 备注 |
|----------|------|----------|----------|------|
| **用户标识** | 唯一识别用户 | user_id, device_id | 用户行为追踪 | 🔄 SDK默认采集 |
| **新老用户** | 用户生命周期阶段 | 新用户、老用户 | 新用户引导优化 | |
| **用户分层** | 基于价值/行为的分层 | 核心用户、活跃用户、沉默用户、流失用户 | 精细化运营 | |
| **会员等级** | 付费/权益等级 | 普通、VIP、SVIP | 付费转化分析 | |
| **注册渠道** | 用户来源 | 自然流量、广告投放、邀请裂变 | 渠道ROI分析 | |

#### 2.4.2 时间维度（When）

| 维度名称 | 说明 | 常见取值 | 应用场景 | 备注 |
|----------|------|----------|----------|------|
| **上报时间** | 事件发生时间戳 | report_time | 时序分析 | 🔄 SDK默认采集 |
| **日期** | 具体日期 | 2024-01-01 | 日报分析 | 🔄 SDK默认采集 |
| **时段** | 一天中的时间段 | 早高峰、午间、晚高峰、深夜 | 推送时机优化 | |
| **星期** | 周几 | 周一至周日 | 周期性规律分析 | |
| **自然周/月** | 统计周期 | 2024年第1周、2024年1月 | 周报/月报 | |

#### 2.4.3 环境/位置维度（Where）

| 维度名称 | 说明 | 常见取值 | 应用场景 | 备注 |
|----------|------|----------|----------|------|
| **地理位置** | 用户所在地 | 国家、省份、城市 | 区域运营分析 | 🔄 SDK默认采集 |
| **系统平台** | 系统平台 | iOS、Android | 平台适配 | 🔄 SDK默认采集 |
| **设备类型** | 设备型号 | iPhone 15、小米14 | 兼容性分析 | 🔄 SDK默认采集 |
| **操作系统** | 系统版本 | iOS 17、Android 14 | 版本适配 | 🔄 SDK默认采集 |
| **网络环境** | 网络类型 | WiFi、4G、5G | 加载性能分析 | 🔄 SDK默认采集 |
| **App版本** | 应用版本号 | v1.0.0、v1.1.0 | 版本迭代效果 | 🔄 SDK默认采集 |

#### 2.4.4 场景/行为维度（How）- 业务逻辑核心

| 维度名称 | 说明 | 常见取值示例 | 应用场景 |
|----------|------|--------------|----------|
| **入口来源** | 用户从哪里进入 | 首页、Push推送、弹窗提醒、搜索进入、分享进入 | 入口效果分析 |
| **操作路径** | 用户行为链路 | track_id / session_id | 路径漏斗分析 |
| **触发方式** | 如何触发的 | 主动点击、自动触发、系统推荐 | 功能优化 |
| **页面位置** | 在页面的哪个位置 | 首屏、二屏、底部 | 坑位效果分析 |

#### 2.4.5 内容/对象维度（What）

| 维度名称 | 说明 | 常见取值示例 | 应用场景 |
|----------|------|--------------|----------|
| **内容ID** | 唯一标识内容 | content_id, message_id | 内容归因 |
| **内容类型** | 内容分类 | 文字、图片、视频、音频 | 内容策略分析 |
| **业务类型** | 业务分类 | 直播、短视频、商城 | 业务线分析 |
| **商品类目** | 商品分类 | 服装、数码、食品 | 品类分析 |

#### 2.4.6 归因维度（Why）

| 维度名称 | 说明 | 常见取值示例 | 应用场景 |
|----------|------|--------------|----------|
| **推广活动** | 活动标识 | campaign_id, activity_name | 活动效果归因 |
| **实验分组** | A/B测试分组 | 实验组A、对照组B | 实验效果分析 |
| **推荐算法** | 推荐策略 | 协同过滤、热门推荐、个性化推荐 | 算法效果对比 |

---

## 三、输出规范

### 3.1 指标字典表格模板

#### 维度定义表

```markdown
### 维度列表

| 维度名称 | 维度字段 | 维度类型 | 取值说明 | 采集方式 |
|----------|----------|----------|----------|----------|
| {{dimension_name}} | {{field_name}} | {{dimension_type}} | {{value_description}} | {{collection_method}} |
```

**维度类型说明：**
- `用户维度` - 描述用户属性
- `时间维度` - 描述时间相关
- `环境维度` - 描述设备/网络环境
- `场景维度` - 描述行为场景
- `内容维度` - 描述内容/对象属性

#### 指标定义表

```markdown
### 指标及优先级

| 指标 | 定义（指标的计算口径） | 业务意义 | 优先级 |
|------|------------------------|----------|--------|
| {{metric}} | {{definition}} | {{business_reference}} | {{priority}} |
```

**优先级说明：**
- `P0` - 核心指标，必须监控，异常需立即响应
- `P1` - 重要指标，日常关注，异常需及时分析
- `P2` - 辅助指标，周期性回顾
- `P3` - 探索性指标，按需分析

### 3.2 埋点事件详情表

```markdown
## Event Details

| 功能模块 | 埋点事件类型 | 事件名称 | 统计维度 | 埋点事件的触发条件 | 操作路径 |
|----------|--------------|----------|----------|---------------------|----------|
| {{module}} | {{event_type}} | {{event_name}} | {{dimensions}} | {{trigger_situation}} | {{operation_path}} |
```

**埋点事件类型说明：**
- `$app_page_view` - 页面浏览事件
- `$app_element_click` - 元素点击事件
- `$element_exposure` - 弹窗或特殊元素曝光事件（**仅Buz业务使用**，Buz业务中当弹窗曝光使用）
- `$pop-up_view` - 弹窗展示事件 （⚠️ **Buz业务不使用**）
- `$result_return` - 结果返回事件

---

## 四、设计检查清单

在完成指标和维度设计后，使用以下检查清单进行自查：

### 4.1 指标设计检查

- [ ] 每个指标都有明确的计算口径定义
- [ ] 每个指标都对应一个可能的业务决策
- [ ] 指标符合 SMART 原则
- [ ] 指标之间没有重复或矛盾
- [ ] 优先级划分合理

### 4.2 维度设计检查

- [ ] 维度遵循 MECE 原则（相互独立、完全穷尽）
- [ ] 每个维度的取值都有"未知/其他"兜底
- [ ] 维度粒度适中（不过细导致数据稀疏，不过粗失去分析价值）
- [ ] 关键路径有 track_id 支持路径串联

### 4.3 埋点设计检查

- [ ] 触发条件清晰无歧义
- [ ] 同一行为不会重复触发
- [ ] 包含必要的公共维度（用户ID、时间戳、页面来源等）
- [ ] 敏感信息已脱敏处理

---

## 五、最佳实践

### 5.1 指标设计最佳实践

1. **从业务问题出发**：先明确要解决什么业务问题，再设计对应指标
2. **建立指标体系**：使用 OSM（Object-Strategy-Measure）模型构建指标体系
3. **设置基准值**：为每个核心指标设置健康基准值和预警阈值
4. **数据验证**：上线前进行数据验证，确保埋点准确性

### 5.2 常见陷阱

| 陷阱 | 问题描述 | 解决方案 |
|------|----------|----------|
| **虚荣指标** | 追踪无法驱动行动的指标 | 每个指标都要回答"数据异常时怎么办" |
| **维度爆炸** | 维度组合过多导致数据稀疏 | 先聚焦核心维度，后续按需扩展 |
| **口径不一致** | 相同指标在不同场景定义不同 | 建立统一的指标字典 |
| **过度埋点** | 埋点过多增加端性能负担 | 优先级驱动，P3指标可延后 |

---

## 附录

### A. 术语表

| 术语 | 英文 | 定义 |
|------|------|------|
| UV | Unique Visitor | 独立访客数 |
| PV | Page View | 页面浏览量 |
| DAU | Daily Active User | 日活跃用户 |
| MAU | Monthly Active User | 月活跃用户 |
| GMV | Gross Merchandise Volume | 商品交易总额 |
| ARPU | Average Revenue Per User | 每用户平均收入 |
| NPS | Net Promoter Score | 净推荐值 |
| CTR | Click Through Rate | 点击率 |

### B. 参考资源

- [Google HEART Framework](https://www.gv.com/lib/how-to-choose-the-right-ux-metrics-for-your-product)
- [AARRR Pirate Metrics](https://www.slideshare.net/daborga/aarrr-metrics)
- [OSM 指标体系构建方法](https://www.growingio.com/)

---

*文档版本：v1.0*  
*最后更新：2026-01-09*

==================== END: skills/track-metrics-design/references/mobile-app-metrics-design-guide.md ====================


