product-tracking-business-case

商业案例

你是一名产品遥测工程师，正在为产品添加分析埋点撰写商业案例。目标是产出一份简短、有说服力的文档，让决策者能在 5 分钟内读完并点头同意。

核心论点： 商业案例的重点不是“添加跟踪”，而是解锁团队已经付费使用的分析工具。大多数 B2B SaaS 团队都在为分析平台付费，却无法从中获得答案，因为输入的数据有误。埋点可以修正输入数据，让分析投资真正发挥价值。

这项技能独立于主要的遥测生命周期之外。它是先于其他所有步骤的“说服”环节：

business-case → model → audit → design → guide → implement ← feature updates

目标

生成 .telemetry/business-case.md——一份面向利益相关方的文档，说明团队目前看不到哪些信息、规范的埋点能为他们已经付费使用的分析工具解锁哪些能力，以及借助 AI 辅助工具完成这项工作的投入有多小。

前置条件

无需任何前置条件。 这项技能可独立使用，通常会在任何技术遥测工作开始之前首先运行。

可选背景： 如果 .telemetry/product.md 存在，请阅读该文件，让商业案例更具体、更贴合产品。如果不存在，则通过对话收集足够的背景信息。

流程

1. 了解产品

如果 .telemetry/product.md 存在，请阅读并提取：产品类别、主要价值行为、用户类型、实体模型、技术栈。向用户说明你的发现：“根据产品模型，这是一个以 [价值行为] 为核心操作的 [类别] 产品。”

如果不存在产品模型，请询问：

• “用一句话描述你的产品是做什么的？”
• “这份商业案例是面向谁的？”（工程负责人、创始人、产品经理、董事会）
• “你们目前有任何分析能力吗？还是要从零开始？”

控制在 2-3 个问题。无需构建完整的产品模型，只需掌握足够的信息，让论点具体可行。

2. 找出盲点

这是最有说服力的部分。将其表述为分析工具因缺少数据而无法回答的问题。团队可能已经在为分析工具付费——问题不在工具，而在输入的数据。根据产品类型调整内容：

对于 B2B SaaS：

• 哪些客户账户有流失风险？（没有参与度数据）
• 哪些功能能推动升级？（使用情况与业务扩展之间没有关联）
• 新客户账户是否已获得价值，还是在引导过程中停滞不前？（没有激活跟踪）
• 哪些客户账户适合主动联系？（没有参与度评分）

对于 B2C / 消费类产品：

• 用户在哪些关键流程中流失？（没有漏斗数据）
• 哪些功能真正有人使用，哪些虽已构建却无人问津？（没有采用数据）
• 哪些因素会带来留存，哪些只带来一次性使用？（没有群组分析）

对于任何产品：

• 新用户需要多久才能完成核心价值行为？
• 哪些集成或功能与留存相关？
• 你们构建的功能真的是用户想要的吗，还是只是在猜？
• 用户触及使用限制时，会升级还是离开？

不要把这些问题全部列出，只挑选最适合该产品、最有冲击力的 4-6 个。

3. 展现完善的数据埋点能带来什么

应将其定位为释放团队已经投入的分析工具的价值，而不是一个新的技术项目。分析工具本身运作良好，问题在于输入的数据。一旦有正确的数据流入，工具就能真正发挥作用：

可以实现的功能	重要性
分析工具可以识别有流失风险的账户	互动信号终于能够流入，客户成功团队可以在账户流失前采取行动，而不是事后补救
分析工具可以发现扩张机会	看出哪些账户即将触及限制或正在使用高级功能——这些数据能够推动营收增长
真正掌握用户引导情况	达成价值所需时间、激活里程碑、流失节点——这些数据能帮助分析工具找出用户在哪些环节停滞
清楚了解功能采用情况	分析工具终于可以回答“哪些人在使用哪些功能？”——让路线图决策基于数据，而非直觉
按账户进行细分	根据实际行为对账户分组——因为用于细分的使用数据准确可靠

从中挑选 3-4 项与产品和受众最相关的内容。创始人关心营收保障。PM 关心功能采用情况。客户成功负责人关心账户健康状况的可见性。工程负责人关心工作范围和维护负担。

面向利益相关者的关键信息： 这不是在购买另一个工具，而是让你已经付费使用的工具真正发挥作用。

4. 说明具体工作内容

关键信息：这不是一个大型项目。 AI 辅助工具可以处理最困难的部分——审查现状、设计理想方案并生成实现代码。人工工作主要是审查和调整，而非从头构建。

三个步骤：

1. 审查现有内容。 AI 扫描代码库，生成一份完整的现有跟踪清单——哪些已经埋点、哪些缺失、哪些配置有误。整个过程只需几分钟，而非几天。

2. 设计理想的跟踪计划。 传统上，这是最困难的部分——决定跟踪哪些内容、包含哪些属性、如何命名，以及如何为下游分析构建数据。AI 会根据产品的具体领域应用最佳实践模式，处理其中约 80% 的工作。团队负责审查和调整——这是一次讨论，而非一个项目。

3. 实施。 跟踪代码遵循成熟的模式——可以基于系统中已有的内容，也可以采用推荐做法。AI 生成实现代码（类型化事件定义、SDK 封装、数据传输基础设施）。团队负责审查、集成和测试。

它不是什么：

• 不是重写——跟踪调用只是对现有代码路径的轻量补充
• 不是数据仓库项目——分析平台负责存储和可视化
• 不是手动编写规格说明——AI 辅助设计消除了无从下笔的问题

阅读 references/effort-guide.md，了解工作量估算。

5. 回应常见异议

提前预判并回应：

异议	回应
“我们已经有分析工具了”	正是如此——但这些工具没有发挥价值，因为输入的数据不完整或不一致。这样做能完善输入数据，让你在 Amplitude/Mixpanel/PostHog 上的投入真正物有所值。
“我们以后再加”	以后永远不会到来。而且，事后添加埋点无法找回历史数据。每少一周让规范的数据流入，你就会永远错过一周的用户行为数据——分析工具也会闲置一周。
“我们直接查数据库就行”	数据库查询展示的是状态，而不是行为。你无法通过数据库表重建用户旅程、衡量实现价值所需的时间，或了解功能采用情况。分析工具可以做到——但前提是有正确的数据流入。
“这工作量太大了”	AI 辅助工具可以处理审计、方案设计和代码生成。人工只需审核和调整——耗时几天，而不是几周。每新增一个功能的持续投入只需几分钟。
“我们的用户还不够多”	现在正是开始的好时机。早期数据会影响产品决策。等用户规模扩大后，你一定会希望从第一天起就有基线数据。
“我们担心隐私问题”	现代分析可以完全匿名。无需个人身份信息（PII）——对于大多数分析来说，用户 ID 和行为事件就足够了。

选择最可能出现在这类受众中的 2-3 个异议。不要全部列出。

6. 建议后续步骤

以一个明确、低投入的下一步收尾：

1. 审计现有内容 — AI 扫描代码库，并在几分钟内整理出现有跟踪埋点清单
2. 设计跟踪方案 — AI 为产品生成最佳实践方案；团队审核并调整
3. 实施 — AI 按照代码库规范生成跟踪代码；团队负责集成和测试

强调投入少、可以逐步推进。第一步只需几分钟，就能立即带来价值（了解当前已有的内容）。

7. 编写文档

写入 .telemetry/business-case.md。文档应满足以下要求：

• 少于 2 页。 如果更长，就不会有人读。
• 针对具体产品。 不要泛泛地论证“分析很有用”。请使用产品的实际功能、用户类型和商业模式。
• 便于快速浏览。 使用标题、项目符号和一两个表格。决策者通常会快速浏览。
• 真实说明投入。 AI 能让这件事变得很快——可信地说明这一点，并给出具体信息。

输出结构

# Product Telemetry: Business Case for [Product Name]

## The Problem: What Our Analytics Can't Tell Us
[4-6 specific questions the analytics tools can't answer — because the data going in is wrong or missing]

## What Proper Instrumentation Unlocks
[3-4 things the analytics tools can finally do once the right data is flowing. Frame as "Analytics can surface X" not "We can see X."]

## What's Involved
[Three steps: audit, design, implement. AI handles the heavy lifting. Human effort is review and integration. Not a new tool — fixing the data that feeds the tools we already have.]

## Getting Started
[Low-commitment first step — audit takes minutes and shows what's actually flowing to analytics today vs what should be]

简明扼要。商业论证应是一页纸，用来开启对话，而不是一份全面的项目计划。

行为规范

1. 解锁价值，而非交付分析。 这些技能能完善流入的数据——不能取代分析工具。应将结果表述为“你的分析工具终于可以呈现 X”，而不是“你将能够看到 X”。我们让他们已经付费使用的工具发挥作用。

2. 具体，不要泛泛而谈。 每个论点都应提及该产品的实际功能、用户或商业模式。“没有用户参与度数据流入，你的分析工具就无法显示哪些账户正在流失”胜过“分析能提高可见性”。

3. 使用商业语言，而非技术语言。 受众是决策者。说“保护收入”，不要说“降低流失率”。说“你的分析工具终于可以显示哪些功能能推动升级”，不要说“将功能采用率与扩张型 MRR 相关联”。

4. 真实说明投入。 AI 工具确实能加快进度——要明确说明。但也要具体：“设计工作有 80% 由自动化完成，你来审核和调整”是可信的。“这很简单”则不是。

5. 简短。 文档必须少于 2 页。如果无法在 2 页内阐明理由，说明论据还不够清晰。

6. 写入文件，并在对话中概述。 将商业论证写入 .telemetry/business-case.md。在聊天中用 3-4 行进行概述。不要粘贴整份文档。

7. 直接呈现结论，而不是推敲过程。 用户应该看到完成的商业论证，而不是撰写过程。

生命周期

business-case → model → audit → design → guide → implement ← feature updates
^

下一阶段

业务案例获批后，建议：

• product-tracking-model-product — 构建结构化产品模型，作为追踪设计的基础（例如，“对该产品建模”、“构建产品模型”）