analytics-tracking

analytics-tracking 技能概览

analytics-tracking 技能可帮助你设计、审计并落地真正能回答业务问题的测量方案，而不是一味堆砌噪音事件数据。它尤其适合正在搭建 GA4、GTM、UTM 规范、转化追踪、产品使用事件，或为营销网站、SaaS 应用、电商流程制定 tracking plan 的团队。

analytics-tracking 技能适合谁用

如果你需要完成以下工作，建议使用这个技能：

• 在工程开始前先判断“到底该追踪什么”
• 修复定义不清或已经失效的 analytics 实现
• 为 GA4、GTM、Mixpanel 或 Segment 工作流建立可执行的事件 taxonomy
• 统一 paid、organic、email、partnerships 等渠道的 UTM 规则
• 把事件设计和业务决策挂钩，比如注册质量、漏斗流失、功能采用率或收入归因

它特别适合市场团队、增长团队、PM、创始人，以及同时处理产品与营销数据的 agents。

analytics-tracking 帮你完成的核心任务

这个技能真正解决的问题，不是“多加一些 analytics”，而是把“衡量我们的漏斗”这类模糊目标，转成一份可直接执行的 tracking plan，包括：

• 关键转化点
• 事件名称
• 参数
• 触发逻辑
• 实现说明
• 验证步骤

因此，当你需要一份可以直接交给 marketing ops、产品或工程团队的结构化输出时，analytics-tracking 比泛泛的提示词更有价值。

这个技能与普通方案的不同之处

这个技能在关键地方有明确的方法论，而且方向是对的：

• 它先从“数据要支持哪些决策”出发
• 会先检查现有的产品/营销上下文
• 会推动统一的事件命名方式，例如 object_action
• 同时包含 GA4 与 GTM 的实现指导
• 除了主文件 SKILL.md 外，还附带可直接参考的资料文件

这些参考资料正是它最核心的差异点。references/event-library.md 按业务类型提供实用的事件建议，references/ga4-implementation.md 和 references/gtm-implementation.md 则让这个技能不仅停留在策略层，而是真正适合需要执行细节的团队安装使用。

哪些场景下 analytics-tracking 特别合适

当你的需求听起来像下面这样时，优先考虑 analytics-tracking：

• “我们的 SaaS 漏斗到底该追踪哪些事件？”
• “注册和升级这类转化，GA4 和 GTM 应该怎么配？”
• “我们现在事件命名很乱，报表也不可靠。”
• “我们需要一套 UTM 命名规范。”
• “怎么审计事件有没有正确触发？”

如果任务重点是实验设计或 A/B test 测量，仓库本身也明确建议改用单独的 ab-test-setup 技能。

如何使用 analytics-tracking 技能

analytics-tracking 的安装上下文

从仓库安装 analytics-tracking 技能：

npx skills add https://github.com/coreyhaines31/marketingskills --skill analytics-tracking

安装后，先打开技能目录，优先阅读以下文件：

• skills/analytics-tracking/SKILL.md
• skills/analytics-tracking/references/event-library.md
• skills/analytics-tracking/references/ga4-implementation.md
• skills/analytics-tracking/references/gtm-implementation.md
• skills/analytics-tracking/evals/evals.json

这个技能里，参考资料比很多技能都更重要，因为事件示例、命名模式、实现说明以及调试建议都写在这些文件中，它们会直接影响输出质量。

先利用现有上下文，再补充提问

这个技能会明确要求 agent 先检查：

• .agents/product-marketing-context.md
• .claude/product-marketing-context.md

原因很简单：analytics 设计如果能绑定到已定义好的定位、漏斗阶段、ICP 和核心转化动作，质量会明显更高。如果这些文件已经存在，就应该先用它们，而不是反复向用户提一轮又一轮 discovery 问题。

analytics-tracking 需要哪些输入

想让 analytics-tracking 输出更可落地，最好一开始就提供这些信息：

• 业务类型：SaaS、ecommerce、lead gen、marketplace、media 等
• 核心转化：signup、demo booked、purchase、activation、upgrade
• 当前使用工具：GA4、GTM、Segment、Mixpanel、广告平台
• 站点/产品范围：仅 marketing site、仅 app，或两者都有
• 流量渠道：paid search、paid social、email、organic、partners
• 技术限制：SPA、server-side rendering、consent banner、dev access
• 隐私要求：GDPR、consent mode、PII 处理限制
• 当前问题：重复事件、归因缺失、命名混乱、没有 QA

没有这些信息，技能依然能给出帮助，但结果会更泛化，也更难直接进入实施。

把模糊目标改写成高质量提示

弱提示：

“Help me with analytics.”

强提示：

“Use the analytics-tracking skill to create a tracking plan for our B2B SaaS website and app. We use GA4 and GTM. Primary conversions are demo bookings, free trial starts, and paid upgrades. We want to measure CTA clicks, form starts/submits, onboarding completion, feature adoption, and plan upgrades. Please propose event names in object_action format, required parameters, GTM trigger ideas, GA4 conversion recommendations, and a QA checklist.”

为什么这个提示更有效：

• 明确了业务模式
• 点出了关键转化
• 说明了技术栈
• 要求输出采用可直接执行的实现格式

真实工作中推荐的输出格式

建议让技能返回一张表，包含以下列：

• event name
• business purpose
• trigger condition
• parameters
• destination tools
• conversion status
• notes / edge cases

这更符合团队实际落地 analytics-tracking 的方式，也能降低策略到实施之间的交接成本。

评估是否采用时，优先阅读哪些仓库文件

如果你是在正式采用前评估这个技能，建议按以下顺序阅读：

1. SKILL.md：理解整体工作原则
2. references/event-library.md：按使用场景查看候选事件
3. 如果涉及 GA4，再读 references/ga4-implementation.md
4. 如果涉及 GTM，再读 references/gtm-implementation.md
5. evals/evals.json：查看高质量输出应该是什么样子

evals 很有参考价值，因为它能直接体现这个技能在真实使用中要完成什么：先检查上下文、让 tracking 服务于决策、采用一致命名，并输出 tracking plan，而不是松散的建议列表。

如何把 analytics-tracking 用在 Data Analysis 之前

analytics-tracking 的主要用途是做实施规划，但它在 Data Analysis 的上游也很有价值，因为它能先把后续要查询的数据结构统一好。你可以用它定义：

• canonical event names
• 一致的参数体系
• funnel stages
• conversion points
• attribution fields

这样后续分析会更干净，也能减少花在清洗和对齐混乱事件数据上的时间。对 Data Analysis 团队来说，最佳用法是在开始做 dashboard 或 SQL 之前，先用 analytics-tracking 把 measurement schema 定下来。

analytics-tracking 在 GA4 和 GTM 场景下的实用建议

如果你的技术栈里包含 GA4 和 GTM，建议让技能同时输出 measurement plan 和 implementation notes。参考资料支持的内容包括：

• GA4 recommended events 与 custom events
• conversions setup
• custom dimensions 和 metrics
• DebugView 与 QA 工作流
• GTM data layer 模式
• trigger 设计
• variable 策略
• tags、triggers、variables 的命名规范

这比只问“我们应该追踪哪些事件”更有用，因为如果没有触发逻辑和验证步骤，很多事件方案最终都会卡死在实施阶段。

营销网站场景的 analytics-tracking 示例提示

“Use the analytics-tracking skill to define analytics for our lead-gen site. Track page views, CTA clicks, form starts, form submits, pricing page engagement, resource downloads, and outbound demo scheduler clicks. We use GA4 and GTM. Include event names, parameter recommendations, conversion settings, and GTM custom event suggestions.”

SaaS 产品场景的 analytics-tracking 示例提示

“Use the analytics-tracking skill to create a product analytics plan for our SaaS app. We need signup, trial start, onboarding completed, feature used, invite sent, integration connected, and plan upgraded. Suggest object_action event names, parameters, when to mark as conversions, and how to push these through GTM or a data layer.”

需要尽早解决的常见采用障碍

最大的阻碍通常是范围不清。很多团队会把三类不同工作混在一起：

• marketing attribution
• product usage analytics
• revenue/conversion tracking

要明确告诉技能，当前最重要的是哪一类。否则输出虽然可能看起来很全面，但很难一次性真正落地。

analytics-tracking 技能 FAQ

analytics-tracking 对新手友好吗？

友好，前提是你至少能描述自己的漏斗和工具栈。相比新手从零开始的空白页工作流，这个技能更有结构，也有参考资料可依。但如果没人能回答基本问题，比如核心转化、技术栈、实施归属，它的效果还是会打折扣。

analytics-tracking 技能的主要边界是什么？

它的作用是帮助你定义 tracking，并指导如何实现。它并不能替代在 GA4、GTM、Segment 或你的应用代码中实际完成 tag 部署、代码修改或账号配置。更准确地说，它是规划与执行辅助工具，不是自动安装器。

它和普通的 analytics 提示有什么区别？

普通提示往往只会返回一份泛泛的事件清单。analytics-tracking 更强，原因在于它建立在以下基础上：

• 以决策为先的 measurement 设计
• 统一命名规范
• 面向 GA4 与 GTM 的仓库参考资料
• 按业务类型整理的实用事件库
• 在 evals 中明确给出的期望输出模式

这通常会产出更容易实施的方案，也能减少 vanity metrics。

什么情况下不该使用 analytics-tracking？

以下情况建议跳过 analytics-tracking：

• 你只需要一个快速的 GA4 UI 点击路径说明
• 你做的是实验设计，而不是 tracking 设计
• 你的真实问题是 BI 建模或 dashboard SQL，而不是事件埋点
• 你需要参考资料未覆盖的某个工具的 vendor-specific 配置

它依然能帮助你梳理 measurement 层，但不能替代更深入的平台级工程文档。

它是否只支持 GA4？

不是。GA4 和 GTM 是支持最完善的路径，因为参考资料对它们有直接覆盖。但这个技能同样适合更广义的事件规划，也可以把结果供给 Mixpanel、Segment 或广告平台。尤其当你先要求输出 tool-agnostic 的事件定义，再补 vendor 映射时，效果通常不错。

analytics-tracking 能用于审计已有但失效的配置吗？

可以。如果你现在面临的是事件不一致、重复、命名混乱，或者事件设计和业务问题脱节，这个技能非常适合。你可以让它基于目标决策、转化点、命名规则和参数一致性，审计当前事件清单。

如何改进 analytics-tracking 技能的使用效果

给出业务决策，而不只是 tracking 需求

想提升 analytics-tracking 输出质量，最快的方法就是明确说明数据要支持什么决策，例如：

• “We need to know which channels drive qualified demos.”
• “We need to see where trial users fail onboarding.”
• “We need to compare upgrade rates by acquisition source.”

这样能把输出推向真正有用的事件，而不是泛泛的 engagement 噪音。

如果已有事件清单，直接提供给技能

如果你已经埋过事件，把现有列表贴出来。然后让技能帮你：

• 去重命名
• 统一成 object_action
• 找出缺失参数
• 标记 vanity 或低价值事件
• 把旧事件映射到更干净的 taxonomy

如果团队本来就有一套混乱实现，这样做会比从零开始要一份新方案好得多。

不只要事件名，也要参数逻辑

一个常见失败模式是：事件列表看起来整齐，但参数设计很弱。要提升 analytics-tracking 的使用效果，建议明确要求：

• required vs optional parameters
• allowed values
• naming conventions
• 每个事件的示例
• 哪些参数要成为 GA4 custom dimensions

这能显著减少实施过程中的歧义，也会提升后续报表质量。

第一轮就要求 QA 和调试步骤

不要等到最后才考虑验证。应在第一次输出时就让 analytics-tracking 包含：

• 如何在 GTM Preview 中验证事件
• 如何检查 GA4 DebugView
• 如何测试重复触发
• 如何验证 UTM 捕获是否正确
• 上线前“done”的标准是什么

这是最有价值的优化之一，因为很多 tracking 方案不是死在规划阶段，而是死在 QA 阶段。

按漏斗层级拆分工作

如果第一版输出显得过宽，建议把 analytics-tracking 按更窄的范围分轮执行：

1. acquisition 与 UTM conventions
2. 网站转化事件
3. 产品 onboarding 事件
4. monetization 与 upgrade 事件
5. QA 与 reporting 检查

相比一次性提出一个超大的全量需求，这种方式通常能得到更清晰、更可用的方案。

用参考文件来反向检验输出质量

当生成的方案看起来“似乎合理”，但又有些空泛时，可以拿它对照这些文件：

• references/event-library.md：检查是否漏掉关键事件或参数
• references/ga4-implementation.md：检查是否缺少 GA4 特定设置细节
• references/gtm-implementation.md：检查 data layer 与 trigger 设计是否到位

这是在不靠主观猜测“什么算好”的前提下，提升 analytics-tracking 输出质量的最佳方法。

需要重点留意的常见失败模式

检查 analytics-tracking 输出时，要特别留意这些问题：

• 事件过多，但没有明确业务目的
• 没有区分关键转化事件和辅助事件
• 事件命名不一致，或过度贴近 UI 文案
• 缺少做分群分析所需的关键参数
• 没提 consent、PII 或 cross-domain 问题
• 实施建议没有结合你的真实技术栈

一旦出现这些情况，就应收紧提示词，并要求输出一套更精简、且与决策明确关联的事件集。

第一稿之后继续迭代

更稳妥的工作流通常是：

1. 先生成一版 tracking plan 草稿
2. 删除低价值事件
3. 补充缺失参数和 trigger rules
4. 标记 primary conversions
5. 加上 QA 步骤
6. 再交给实施团队

analytics-tracking 最适合作为迭代式规划工具，而不是一次性生成“魔法答案”的工具。