Timi-Fish 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