analytics-tracking
作者 alirezarezvanianalytics-tracking 可帮助 agent 规划、审计和调试 GA4 与 Google Tag Manager 实施，覆盖 event taxonomy、conversion tracking、UTM capture、custom dimensions、dataLayer 检查和 tracking QA。适合在依赖报表或归因分析之前，用于 Analytics Implementation 相关工作。
该 skill 评分为 84/100。对于希望让 agent 更稳妥地搭建、审计或调试 analytics tracking、减少泛用 prompt 猜测成本的目录用户来说，它是一个可靠的收录候选。仓库提供了内容充实的 SKILL.md，针对 GA4/GTM/event tracking 工作给出清晰触发词，并包含调试、taxonomy、GTM 模式等实用参考，以及一个 tracking plan 生成脚本。用户仍应预期需要把这些指导适配到自己的技术栈和安装流程中。
- 触发场景非常明确：frontmatter 清楚列出 GA4 setup、Google Tag Manager、event tracking、conversion tracking、analytics audits、missing events 等用例。
- 实操参考扎实：分别提供 tracking 问题调试、event taxonomy 标准和 SaaS GTM 实施模式的指南。
- 比单纯写 prompt 更能提升 agent 产出：tracking_plan_generator.py 可基于结构化输入生成 event taxonomy、GTM 配置和 GA4 dimension 建议。
- SKILL.md 未提供安装命令，用户可能需要根据仓库结构自行判断安装方式。
- 内容重点放在 GA4、GTM 和 SaaS 场景模式上；使用其他 analytics 技术栈的团队可能需要调整工作流。
analytics-tracking skill 概览
analytics-tracking 适合用来做什么
analytics-tracking skill 可帮助 AI agent 规划、审计和调试数据埋点实现，尤其适用于 GA4、Google Tag Manager、事件分类体系、转化追踪、UTM 采集、自定义维度和数据质量相关工作。它最适合那些在信任报表、广告优化、归因分析或漏斗分析之前，必须先确保埋点可靠的团队。
最适合的用户和任务
如果你是创始人、市场人员、产品经理、analytics engineer 或开发者，并且想回答这个问题：“我们是否在正确的工具里，用正确的名称和参数，采集了正确的用户行为？”那么可以使用这个 analytics-tracking skill。它最擅长 Analytics Implementation 类任务，例如制定 tracking plan、统一事件命名、审查 GTM 配置、排查 GA4 事件缺失，或把业务目标转化为可衡量的转化事件。
它相比通用提示词有何价值
这个 skill 不只是提供宽泛的数据分析建议，还包含带有明确倾向的实现参考。仓库提供了 debugging playbook、event taxonomy guide、GTM SaaS patterns，以及一个 Python tracking plan generator。这让 agent 有一套具体工作流：定义业务背景、映射事件、应用命名规则、推荐 GA4/GTM 配置，并从 app 的 dataLayer push 到 GA4 DebugView，逐层验证数据链路。
什么时候不适合使用这个 skill
如果你的主要目标是分析广告活动表现、设计 dashboard，或在数据已经干净之后解读产品使用趋势，就不建议安装 analytics-tracking。它关注的是埋点质量。做 campaign reporting 时，更适合使用 campaign analytics 工作流；做 BI 或产品分析探索时，更适合使用 product analytics 工作流。
如何使用 analytics-tracking skill
analytics-tracking 安装方式和仓库路径
通过以下命令从 GitHub 仓库安装该 skill：
npx skills add alirezarezvani/claude-skills --skill analytics-tracking
源码路径是 marketing-skill/skills/analytics-tracking。安装后，先阅读 SKILL.md，然后在要求 agent 输出实现方案之前，检查这些辅助文件：
references/event-taxonomy-guide.md：用于命名和参数标准references/gtm-patterns.md：用于 GTM tag、trigger 和 variable 模式references/debugging-playbook.md：用于排查事件缺失scripts/tracking_plan_generator.py：用于了解结构化 tracking plan 生成逻辑
让 skill 产出有用结果所需的输入
要更好地使用 analytics-tracking，不要只要求“做一个 GA4 setup”，而要提供实现背景。请包含：
- 业务类型，例如 SaaS、ecommerce、marketplace 或 lead generation
- 关键页面、路由、产品流程和表单
- 主要转化和次要 micro-conversion
- 当前技术栈：GA4、GTM、server-side tagging、Segment、RudderStack、自定义代码
- consent mode、GDPR/CCPA 或 cookie banner 是否会影响追踪
- 现有事件名称、已知缺口、重复事件或失效转化
- 需要保持 UTM 或转化一致性的付费渠道
较弱的提示词是：“Set up analytics for my app.”
更好的提示词是：“Use analytics-tracking to create a GA4 and GTM tracking plan for a B2B SaaS app with homepage, pricing, signup, onboarding, dashboard, demo request, trial start, and subscription purchase. We use GTM, need consent-aware tracking, and want event names that follow a consistent taxonomy.”
实施中的实用工作流
先确定事件分类体系，再配置 tag。可以要求 agent 按照仓库中的 object-action convention 定义事件，然后指定 trigger、必填参数、可选参数、是否作为 conversion、以及优先级。接着，把每个事件映射到一种 GTM pattern：对于重要行为，优先使用 app 层的 dataLayer.push() 事件，而不是容易失效的纯点击 trigger。
调试时，要求 agent 按照 playbook 中自底向上的链路排查：app code 或 dataLayer、GTM firing、network requests、GA4 processing，最后才是 GA4 reports 或 DebugView。这样可以避免一个常见错误：一开始就查看 GA4 报表，然后猜测数据为什么缺失。
一个能很好调用该 skill 的示例提示词
“Use the analytics-tracking skill as an Analytics Implementation guide. Audit our current GA4/GTM setup for a SaaS funnel: /, /pricing, /signup, /app/onboarding, /billing. Current events are SignUp, signup_complete, trialStart, and purchase. Problems: signup conversion is missing in GA4, pricing views are duplicated, and paid campaigns need reliable UTM capture. Produce: 1) corrected event taxonomy, 2) GTM tag/trigger/variable changes, 3) GA4 custom dimensions, 4) debugging checklist by layer, and 5) a rollout QA plan.”
analytics-tracking skill 常见问题
analytics-tracking 对新手友好吗？
是的，前提是你能描述自己的网站或产品流程。这个 skill 可以把粗略的业务目标转化为事件和参数，但你仍然需要拥有 GA4、GTM、网站代码的访问权限，或能联系到负责这些内容的开发者。新手可以要求它给出分步骤计划，并解释 dataLayer、custom dimensions 和 DebugView 等术语。
它比普通 GA4 提示词好在哪里？
普通提示词可能只会生成一份泛泛的事件列表。analytics-tracking skill 更偏向落地实现：它会推动 agent 统一命名、避免重复事件、定义 GTM 架构、考虑 consent 和 UTM 处理，并从源头事件开始向上调试。这一点很重要，因为数据追踪问题往往不会明显报错，而且高度依赖具体配置。
它能生成完整的 tracking plan 吗？
可以。内置的 scripts/tracking_plan_generator.py 展示了一套工作流，可基于结构化输入生成 event taxonomy、GTM 配置和 GA4 dimension 建议，这些输入包括业务类型、关键页面、转化行为、付费渠道和 consent 要求。建议把输出当作初稿，再与工程和市场相关负责人一起评审。
主要采用阻碍是什么？
最大的阻碍是上下文不完整、缺少工具访问权限，以及业务定义不清。如果团队还没有就 conversion、lead、signup、trial 或 purchase 的定义达成一致，这个 skill 可以提出一套 taxonomy，但不能替你解决业务归属问题。此外，除非你的网站有稳定的 selector 或 app 层事件 push，否则 GTM click trigger 可能并不可靠。
如何改进 analytics-tracking skill
用更充分的上下文提升 analytics-tracking 输出质量
提升 analytics-tracking 输出质量最快的方法，是提供真实流程和约束。补充 URL 或 route name、GTM tag 截图、当前 GA4 事件列表、失效事件示例、consent banner 行为，以及销售或市场实际使用的精确转化定义。这样 agent 才能产出可直接进入实施的建议，而不是停留在理论层面的 tracking plan。
需要警惕的常见失败模式
注意事件泛滥、命名不一致、参数缺失、过度依赖按钮点击 trigger、单页应用中的重复 page view，以及过早把旅程中的行为标记为 conversion。还要检查是否有个人身份信息可能泄露到 GA4 参数中。可以要求 agent 标记隐私风险，并定义哪些参数绝不能发送。
首轮输出后如何迭代
拿到第一版方案后，用三个视角做一次评审：业务价值、技术可靠性和报表可用性。可以问：“哪些事件对决策是必需的？”“哪些需要开发埋点，而不能只靠 GTM 追踪？”以及“哪些参数应该成为 GA4 custom dimensions？”随后再要求生成一份覆盖 GTM Preview、浏览器 network requests 和 GA4 DebugView 的 QA checklist。
值得考虑的仓库改进方向
如果要改进 analytics-tracking skill 本身，可以为常见场景增加示例输入/输出文件，例如 SaaS signup、ecommerce checkout 和 lead generation。一个示例 tracking-plan.json、一份 consent-mode checklist，以及一份简洁的 GA4 custom dimensions template，都会让这个 skill 更容易被采用。现有参考资料已经很有用；如果补充端到端示例，可以减少新用户在配置时的不确定性。