mcpField
G
gtm-tracking-plan

gtm-tracking-plan

github.com/cognyai营销与增长11148 次安装2 周前更新
代码仓库

关于 gtm-tracking-plan

gtm-tracking-plan 可根据网站 URL 生成 Google Tag Manager 实施规格,供规划测量方案的团队使用。它列出标签、触发器、变量和开发者可用的 dataLayer 代码片段,无需连接账户。

主要功能

  1. 01根据网站或现有方案推导事件分类
  2. 02编写 GTM 变量、触发器与标签规格
  3. 03生成含触发位置的 dataLayer.push() 代码片段
  4. 04提供实施顺序与 QA 检查
  5. 05纳入 Consent Mode 要求

适用场景

  1. 01根据网站 URL 起草 GTM 容器方案
  2. 02将 GA4 测量方案转为 GTM 配置
  3. 03为开发者准备 dataLayer 事件说明
  4. 04规划 GTM 设置与发布前 QA

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/cognyai/claude-code-marketing-skills --skill gtm-tracking-plan

安装后在 Claude Code 中输入/gtm-tracking-plan确认已加载。

详细介绍

GTM 跟踪计划

提供网站 URL,即可获得一份完整的 Google Tag Manager 构建规范——需要创建的每个标签、触发器和变量,以及开发者可直接放入网站的准确 dataLayer.push() 代码片段。这是测量计划的实施部分。无需连接账户。

最好在运行 /ga4-measurement-plan 后使用——传入相同的 URL,此技能会构建 GTM 容器来实现该计划。单独运行时,它会先推导出合理的计划。

用法

/gtm-tracking-plan example.com — 获取网站的完整 GTM 构建规范

步骤

1. 确定要实施的事件

如果对话中已有 GA4 测量计划,请使用其中的事件分类。否则,使用 WebFetch 获取网站内容,推断网站类型和转化漏斗,并自行推导事件列表(简要而言,逻辑与 /ga4-measurement-plan 相同)。

每个事件都需要提供:名称、触发时机、参数,以及是否为关键事件。

2. 变量

按类型列出所有要创建的变量:

  • 数据层变量 — 每个推送到数据层的参数对应一个变量 (ecommerce、value、currency、transaction_id、lead_source 等)
  • 要启用的内置变量 — Click Element、Click URL、Click Text、Form ID、 Page Path、Page URL,以及各触发器所需的其他变量
  • 常量 — GA4 衡量 ID(G-XXXXXXX)
  • 查找表 / 正则表达式表 — 仅在确实需要路由或值映射时使用
  • 同意状态变量 — 如果涵盖 Consent Mode

以表格呈现:变量名称、类型、配置、使用方。

3. 触发器

每种不同的触发条件创建一个触发器。每个触发器都要列出名称、类型和条件。

  • 初始化 / 同意初始化 — 用于 Consent Mode 的默认状态
  • 自定义事件触发器 — 每个 dataLayer 事件创建一个(event 等于 purchase、 generate_lead 等);这是触发任何推送到 dataLayer 的事件的推荐方式
  • 基于 DOM 的触发器(点击、表单提交、元素可见)仅在网站无法推送 dataLayer 事件时使用
  • 历史记录变更 — 用于 SPA 页面浏览

采用一致的命名方式:CE - purchase、Click - CTA button。

4. 标签

列出所有要创建的标签。每个标签都要列出名称、类型、触发条件和关键字段。

  • GA4 配置标签 — 仅创建一个,在初始化 / 所有页面触发,并设置衡量 ID。(明确指出“仅创建一个”可避免经典的重复计数错误。)
  • GA4 事件标签 — 为步骤 1 中的每个事件各创建一个,引用配置标签,并将参数映射到数据层变量
  • Google Ads 转化标签 — 为用于 Ads 出价的关键事件创建,并提供转化 ID/标签占位符
  • 同意 — 如果涵盖 Consent Mode,则创建默认设置和更新标签

使用清晰的命名规范:GA4 - Event - purchase、Ads - Conversion - Lead。

5. dataLayer 代码片段

这是交付给开发者的内容。对于每个需要网站代码的事件,提供可直接复制粘贴的 dataLayer.push() 代码片段,并使用贴近实际的占位符:


<script>
  window.dataLayer = window.dataLayer || [];
  dataLayer.push({ ecommerce: null });   // clear the previous ecommerce object
  dataLayer.push({
    event: "purchase",
    ecommerce: {
      transaction_id: "{{ORDER_ID}}",
      value: {{ORDER_TOTAL}},
      currency: "{{CURRENCY}}",
      items: [
        { item_id: "{{SKU}}", item_name: "{{NAME}}", price: {{PRICE}}, quantity: {{QTY}} }
      ]
    }
  });
</script>

为每个关键事件以及最重要的非关键事件提供代码片段。注明每个事件的触发位置(哪个页面 / 哪个 DOM 事件)。

6. 实施顺序与 QA

给出构建顺序:

  1. 启用内置变量并创建用户定义的变量
  2. 创建触发器
  3. 创建 GA4 配置标签,然后创建事件标签,再创建 Ads 转化标签
  4. 将 dataLayer 代码片段添加到网站
  5. 在 GTM Preview 和 GA4 DebugView 中进行 QA — 验证每个事件只触发一次、参数均已填充,且不会在用户同意前触发
  6. 发布一个命名版本

指出常见故障原因:在 GTM 代码片段之后才推送 dataLayer、未清除过期的 ecommerce 对象、标签在用户同意前触发、事件名称拼写错误。

7. 输出

交付为一份文档:

GTM Tracking Plan — [site]

Container overview: X tags · X triggers · X variables

1. Variables table
2. Triggers table
3. Tags table
4. dataLayer snippets (per event, with firing location)
5. Build order
6. QA checklist

关键规则

  1. 只能有一个 GA4 配置标签。 明确说明这一点——重复配置标签是 GTM 中最常见的问题。
  2. 优先使用自定义事件触发器,而不是 DOM 触发器。 推送到 dataLayer 的方式可靠;抓取 DOM 则不稳定。只有在网站无法推送时,才使用 DOM 触发器。
  3. 每段 dataLayer 代码都必须可直接复制粘贴,并清晰标明占位符和触发位置。
  4. 遵守 Consent Mode——在受监管地区,分析和 Ads 标签必须在获得同意前保持不触发。
  5. 这会生成一份构建规范。如需审计正在运行的容器,请使用 /gtm-audit (需要 Cogny MCP)。

评论

支持 Markdown