Google Tag Manager tracking-plan workflow
This doc explains the proposed workflow where a tracking plan in Google Sheets is compared against a Google Tag Manager (GTM) container, then implemented in a GTM workspace with preview-first validation.
Use this as the implementation reference for the first “tracking plan ←> container” MCP skill.
Acronym clarification
- GTM in this workflow means Google Tag Manager, not go-to-market.
- Go-to-market workflows are separate and are not part of this automation scope.
What this workflow is solving
Teams currently spend a lot of time in the GTM UI manually checking:
- whether planned events exist in the container
- whether tags fire correctly
- whether required properties are attached
- whether naming and trigger conditions match the plan
The goal of this MCP workflow is to reduce manual UI work by making the process deterministic:
- read plan (Google Sheet)
- read current GTM container state
- diff + report gaps
- create/update a GTM workspace
- generate preview URL for validation
- keep publish manual (safety gate)
Source-of-truth mapping table (Sheet → GTM)
This table shows a recommended column contract for the tracking-plan sheet and how each field maps to GTM entities.
| Tracking-plan column (Google Sheet) | Example value | GTM entity | GTM field(s) / usage | Notes |
|---|---|---|---|---|
event_name | signup_started | Tag | Tag name, event name parameter | Canonical key for matching expected vs actual implementation |
event_priority | P1 | Metadata only | Naming suffix/label conventions | Useful for rollout ordering; not required by GTM API |
event_type | track | Tag | Template selection and payload shape | Helps choose GA4/Segment/custom template |
trigger_type | custom_event | Trigger | Trigger type | Ex: custom event, click, page view |
trigger_expression | event equals signup_started | Trigger | Filter predicates/conditions | Used to detect trigger drift |
trigger_scope | all_pages | Trigger | Page/path constraints | Optional but important for false-positive prevention |
data_layer_event | signup_started | Trigger | Custom event name | Often primary binding key |
required_properties | plan_tier,country,signup_flow | Tag + Variables | Tag params populated from variables | MCP should assert all required properties are mapped |
property_allowed_values | `plan_tier=free | pro | enterprise` | Validation rule |
property_source | dataLayer.plan_tier | Variable | Variable definition path | Drives variable creation or update |
variable_name | dlv - plan_tier | Variable | Variable name | Recommended naming normalization target |
destination | segment | Tag | Tag template/type and destination config | Helps pick correct tag template |
workspace_hint | release-2026-05-signup | Workspace | Workspace name | Optional but useful for grouped changes |
status | planned / implemented | Derived | Diff output state | Usually computed, not authored in GTM |
owner | analytics_eng | Metadata only | Reporting | Useful for approvals/escalation |
Data pulled by the MCP workflow
From Google Sheets (tracking plan)
- planned event catalog
- required properties and allowed values
- trigger logic expectations
- variable source definitions (commonly dataLayer paths)
- implementation status/priority metadata
From Google Tag Manager (via MCP)
- account/container/workspace inventory
- tags (name, type/template, parameters, firing setup)
- triggers (type, conditions, event bindings)
- variables (name, variable type, source path/config)
- version/workspace metadata for comparison and preview flow
Important: this workflow mainly pulls configuration metadata, not product analytics event logs. Event-log QA is done downstream in tools like Segment/Mixpanel/GA4.
Why this is useful (business and engineering)
- Reduces setup and audit time for each new event
- Prevents silent tracking drift between plan and implementation
- Improves handoff quality across product, analytics, and engineering
- Creates repeatable, client-agnostic implementation quality
- Supports “close to no time in interface” as a measurable operating goal
Recommended v1 MCP skill outputs
For each run, return:
- Diff summary: missing, mismatched, extra entities
- Action plan: exact create/update sequence
- Applied changes: what was created/updated in workspace
- Preview link: GTM preview URL
- Validation checklist: GTM + downstream checks
- Publish reminder: manual publish required
Safety guardrails
- Never auto-publish GTM versions in v1
- Workspace-only writes
- Require explicit user confirmation before destructive changes (delete/rename)
- Record before/after snapshots for traceability