Gtm tracking plan

GTM Tracking Plan

Give it a site URL and get back a complete Google Tag Manager build spec — every tag, trigger, and variable to create, plus the exact dataLayer.push() snippets a developer drops into the site. It's the implementation half of a measurement plan. No account connection required.

Best run after /ga4-measurement-plan — pass the same URL and this skill builds the GTM container to deliver that plan. Run alone, it derives a sensible plan first.

Usage

/gtm-tracking-plan example.com — full GTM build spec for the site

Steps

1. Establish the events to implement

If a GA4 measurement plan already exists in the conversation, use its event taxonomy. Otherwise, WebFetch the site, infer the site type and funnel, and derive the event list yourself (the same logic as /ga4-measurement-plan, in brief).

For each event you need: name, when it fires, its parameters, whether it's a key event.

2. Variables

List every variable to create, by type:

• Data Layer Variables — one per parameter pushed to the data layer (ecommerce, value, currency, transaction_id, lead_source, …)
• Built-in variables to enable — Click Element, Click URL, Click Text, Form ID, Page Path, Page URL, plus the relevant ones per trigger
• Constant — the GA4 Measurement ID (G-XXXXXXX)
• Lookup / RegEx table — only if routing or value mapping is genuinely needed
• Consent state variables — if Consent Mode is in scope

Present as a table: variable name, type, configuration, used by.

3. Triggers

One trigger per distinct firing condition. For each: name, type, and conditions.

• Initialization / Consent Initialization — for Consent Mode default state
• Custom Event triggers — one per dataLayer event (event equals purchase, generate_lead, …) — the recommended approach for anything pushed to the dataLayer
• DOM-based triggers (click, form submission, element visibility) only where the site cannot push a dataLayer event
• History Change — for SPA page views

Name them consistently: CE - purchase, Click - CTA button.

4. Tags

List every tag to create. For each: name, type, what fires it, and key fields.

• GA4 Configuration tag — exactly one, on Initialization / All Pages, with the Measurement ID. (Calling out "exactly one" prevents the classic double-count bug.)
• GA4 Event tags — one per event from Step 1, referencing the config tag, with parameters mapped from the Data Layer Variables
• Google Ads Conversion tags — for key events that feed Ads bidding, with conversion ID/label placeholders
• Consent — Consent Mode default + update tags if in scope

Use a clear convention: GA4 - Event - purchase, Ads - Conversion - Lead.

5. dataLayer snippets

This is the developer handoff. For every event that needs site code, give a copy-paste dataLayer.push() snippet with realistic placeholders:

<!-- Fire on the order confirmation page, after the dataLayer is initialized -->
<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>

Include the snippet for each key event and the most important non-key events. Note the firing location (which page / which DOM event) for each.

6. Implementation order & QA

Give the build sequence:

1. Enable built-in variables and create user-defined variables
2. Create triggers
3. Create the GA4 config tag, then event tags, then Ads conversion tags
4. Add the dataLayer snippets to the site
5. QA in GTM Preview + GA4 DebugView — verify each event fires once, with parameters populated, and not before consent
6. Publish a named version

Call out the common failure modes: dataLayer pushed after the GTM snippet, stale ecommerce object not cleared, tags firing pre-consent, event-name typos.

7. Output

Deliver as one document:

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

Critical rules

1. Exactly one GA4 configuration tag. State it explicitly — duplicate config tags are the most common GTM bug.
2. Prefer Custom Event triggers over DOM triggers. A dataLayer push is reliable; scraping the DOM is brittle. Use DOM triggers only when the site can't push.
3. Every dataLayer snippet must be copy-paste ready with clearly marked placeholders and a stated firing location.
4. Respect Consent Mode — analytics and Ads tags must not fire before consent in regulated regions.
5. This produces a build spec. To audit a live container, use /gtm-audit (requires Cogny MCP).