关于 gtm-tracking-plan
gtm-tracking-plan 可根据网站 URL 生成 Google Tag Manager 实施规格,供规划测量方案的团队使用。它列出标签、触发器、变量和开发者可用的 dataLayer 代码片段,无需连接账户。
主要功能
- 01根据网站或现有方案推导事件分类
- 02编写 GTM 变量、触发器与标签规格
- 03生成含触发位置的 dataLayer.push() 代码片段
- 04提供实施顺序与 QA 检查
- 05纳入 Consent Mode 要求
适用场景
- 01根据网站 URL 起草 GTM 容器方案
- 02将 GA4 测量方案转为 GTM 配置
- 03为开发者准备 dataLayer 事件说明
- 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
给出构建顺序:
- 启用内置变量并创建用户定义的变量
- 创建触发器
- 创建 GA4 配置标签,然后创建事件标签,再创建 Ads 转化标签
- 将 dataLayer 代码片段添加到网站
- 在 GTM Preview 和 GA4 DebugView 中进行 QA — 验证每个事件只触发一次、参数均已填充,且不会在用户同意前触发
- 发布一个命名版本
指出常见故障原因:在 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
关键规则
- 只能有一个 GA4 配置标签。 明确说明这一点——重复配置标签是 GTM 中最常见的问题。
- 优先使用自定义事件触发器,而不是 DOM 触发器。 推送到 dataLayer 的方式可靠;抓取 DOM 则不稳定。只有在网站无法推送时,才使用 DOM 触发器。
- 每段 dataLayer 代码都必须可直接复制粘贴,并清晰标明占位符和触发位置。
- 遵守 Consent Mode——在受监管地区,分析和 Ads 标签必须在获得同意前保持不触发。
- 这会生成一份构建规范。如需审计正在运行的容器,请使用
/gtm-audit(需要 Cogny MCP)。