# Tracking Plan

> 为一个功能设计数据埋点与成功指标，分步骤走：定成功指标 → 画漏斗 → 列埋点事件 → 上报验收。 触发词：设计埋点、埋点方案、tracking-plan、这个功能要埋什么、成功指标怎么定、要采哪些数据、加个数据埋点章节。 可独立使用，也被 prd-writing skill 在阶段 3 调用。产品级配置（命名规范/公共属性/上报通道）读产品上下文。

- Skill: `timi-fish/tracking-plan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add timi-fish/tracking-plan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/timi-fish/tracking-plan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: Timi-Fish (https://skillmd.com/u/timi-fish)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/timi-fish/tracking-plan

---


# Tracking Plan Skill

给一个功能（或一份 PRD）产出「数据埋点与成功指标」方案。顺序是**先定成功指标、再定事件**——
没有北极星指标的埋点会变成「什么都埋一点、什么都说不清」。

## 第 0 步：读产品上下文

按 prd-writing skill 目录下的 `PRODUCT-CONTEXT.md` 协议定位 `product.md`，取「埋点体系」一节
（命名规范、公共属性、上报通道、看板）。product.md 不存在 → 按协议做首次访谈并落盘；
存在但埋点体系一节缺失 → 只补问这一节。被 prd-writing 调用时上下文已就绪，直接读。
**未安装 prd-writing（找不到该协议文件）时单独可用**：跳过协议，直接问命名规范、公共属性、
上报通道三项，本次会话内用，不落盘。

## 三类数据分清楚（方案里别混着写）

| 类型 | 内容 | 说明 |
|------|------|------|
| 性能数据 | 崩溃/启动/成功率/耗时 | 偏技术基线，按需带 |
| **行为数据** | 用户路径/流失节点/使用频率 | **本 skill 主要产出** |
| 反馈数据 | 用户反馈渠道与归集 | 不靠埋点，如已有机制就注明 |

## 第 1 步：定成功指标（这个功能算不算成功）

先问：这个功能最关键的一个数是什么（北极星）？逼自己只选一个。

| 指标 | 定义 | 目标值 | 来源 |
|------|------|--------|------|
| 北极星指标 | 最关键的一个数 | 待定 | 行为埋点 |
| 采纳率 | 触达用户中实际使用比例 | > X% | 行为埋点 |
| 完成率 | 开始使用中走完核心流程比例 | > X% | 漏斗埋点 |
| 质量/稳定性 | 崩溃率/失败率/耗时（如涉及） | 见性能基线 | 性能埋点 |

## 第 2 步：画关键漏斗

`入口曝光 → 点击进入 → 核心操作 → 完成 →（回访）`

每一步都要有事件，才能定位用户在哪一步流失。输出到 PRD/方案时把漏斗画出来，
呈现方式（markdown 走 ASCII 字符画、html 走 inline SVG）按 prd-writing 阶段 2.5 的配图规则执行。

## 第 3 步：列埋点事件清单

| 事件名 | 触发时机 | 关键属性 params | 端 |
|--------|----------|----------------|-----|
| xxx_entry_exposure | 入口曝光 | source, 场景 | 全端 |
| xxx_entry_click | 点击入口 | source | 全端 |
| xxx_action_submit | 发起核心操作 | 操作类型 | 全端 |
| xxx_action_result | 操作返回 | result(success/fail), 耗时ms, 失败原因 | 全端 |

- **命名规范与公共属性**：以 product.md 为准；产品没定过的，默认 `模块_对象_动作` 全小写下划线，
  公共属性至少 user_id、platform、app_version，并把这个默认写回 product.md
- **结果类事件必带**：result、耗时、失败原因——这是能不能算「成功率」「定位卡点」的分水岭

## 第 4 步：上报与验收清单

- [ ] 埋点在提测前接入，测试阶段验证能正常上报（别上线后补）
- [ ] 漏斗每一步都有事件，能画出流失漏斗
- [ ] 结果类事件带 success/fail + 失败原因
- [ ] 上报通道与看板按 product.md 执行；产品尚无埋点基建的，方案里明确写出这个前置依赖

## 数据现状要如实写

产品还没有系统性行为数据时（见 product.md「数据现状」），初期样本小、统计意义有限——
把这个判断写进方案，避免"为埋而埋"，并注明哪些指标要等数据量上来后再看。

## 产出去向

- 被 prd-writing 调用时：作为「数据埋点与成功指标」章节附到 PRD 末尾
- 独立使用时：落产品文件夹（product.md 所在目录）的 `tracking/<功能名>.md`