tracking-plan
Skill0 starsChanged 3 months agoMITView on GitHub
为一个功能设计数据埋点与成功指标，分步骤走：定成功指标 → 画漏斗 → 列埋点事件 → 上报验收。 触发词：设计埋点、埋点方案、tracking-plan、这个功能要埋什么、成功指标怎么定、要采哪些数据、加个数据埋点章节。 可独立使用，也被 prd-writing skill 在阶段 3 调用。产品级配置（命名规范/公共属性/上报通道）读产品上下文。
1 other project uses a version of this.
Adopted by
Most recently taken up by
- omarmfouad25/google-marketing-agenttheir own version, first seen Oct 25, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- omarmfouad25/google-marketing-agent★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository5 other files it gives its agents.
- feature-teardownSkill
- pm-flowSkill
- prd-writingSkill
- prior-artSkill
- requirement-evalSkill
The file
Files
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
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.