Tutorial: Using Claude Code to Prepare and Review Google Tag Manager Changes

Google Tag Manager (GTM) changes are usually small in code but large in consequence. A mistyped trigger condition, a duplicate tag, or a data layer key that does not match the one pushed by the website can quietly break conversion tracking for weeks before anyone notices. Claude Code, Anthropic’s agentic coding tool, does not connect to GTM directly; there is no built-in Google integration. It is well suited to the work that surrounds a GTM change, though: reading the exported container, drafting or reviewing custom HTML tags, checking a data layer implementation against what a tag actually expects, and documenting what changed and why.

The following overview covers what Claude Code actually does, what the Windows 11 desktop app adds on top of the command-line tool, and a concrete workflow for using it around a GTM implementation.

What Claude Code Is

Claude Code is an agentic coding tool: it reads a local codebase or folder, edits files, runs shell commands, and calls external tools through the Model Context Protocol (MCP). It ships in several forms — a terminal CLI (macOS, Linux, and Windows via PowerShell or Git Bash), a desktop application for macOS and Windows, extensions for VS Code and JetBrains IDEs, and a browser-based version at claude.ai/code. None of these forms include a native Google Tag Manager connector; every GTM-related task goes through general capabilities such as file access, scripting, and browser automation rather than a dedicated plugin.

Claude Code for Desktop on Windows 11

On Windows 11, the desktop application adds a graphical layer over the same underlying agent: a file editor, an integrated terminal, a diff view for every proposed change, and a browser preview pane for testing pages without leaving the app. Git for Windows is required for the Bash tool; without it, the application falls back to PowerShell. No WSL installation is required for local work, though a WSL2 distribution can be attached as an environment if one is already in use.

Two aspects matter specifically for tracking work: permission modes and the browser pane. Permission modes range from manual approval of every file edit and command to a plan-first mode that lays out the intended changes before touching anything — useful when a script is about to modify a container export or call the GTM API. The browser pane makes it possible to open a staging page, inspect network requests and the data layer, and check whether a tag actually fires, all inside the same window used to write the tag.

Where Claude Code Fits Into a GTM Change

A GTM implementation usually has three parts that are only loosely connected: the container configuration, the code the website exposes (the data layer, DOM elements, or a REST endpoint), and the destination the tag sends data to. Claude Code is useful at each of the first two, and at the seam between them:

• Reading an exported container (Container.json from GTM’s export function, or the response of the GTM API) and summarizing tags, triggers, and variables in plain language, which makes it easier to spot near-duplicates or inconsistent naming.
• Drafting or reviewing the JavaScript inside a Custom HTML tag or a Custom Template, including edge cases such as a data layer key that has not fired yet.
• Comparing what a trigger condition expects against what the website’s data layer actually pushes, using the browser pane or an MCP-connected browser to inspect a live or staging page.
• Writing small scripts against the GTM API (with a service account) to export a container, diff two versions, or check for tags without a matching trigger — none of this is built in, so the script itself is written and reviewed like any other piece of code.
• Producing documentation: a short markdown page listing what a tag does, which data layer keys it depends on, and why a trigger is scoped the way it is, so the next person touching the container does not have to reverse-engineer it.

A Concrete Example: Reviewing a Custom HTML Tag

A common task is validating a Custom HTML tag before it goes live — for example, a tag that reads a data layer variable and forwards it to a destination only if the value looks valid. Asked to review such a tag, Claude Code can point out the kind of issue that is easy to miss when copying a snippet from a forum post:

<script>
(function() {
  var dl = window.dataLayer || [];
  var lastEvent = dl[dl.length - 1] || {};
  var orderId = lastEvent.order_id;

  if (typeof orderId === 'string' && orderId.length > 0) {
    gtag('event', 'purchase_confirmed', { order_id: orderId });
  }
})();
</script>

Reading the data layer from dl[dl.length - 1] silently breaks if any other tag pushes an event between the purchase event and this tag firing, since the tag then reads the wrong object. A review would flag this and suggest reading the value from a Data Layer Variable configured in GTM instead, which does not depend on array position. Catching this kind of ordering assumption before publishing is exactly the sort of check that is easy to automate around GTM but is not something GTM’s own interface points out.

Staying Inside the Guardrails

Two things do not change no matter how the workflow is set up. First, publishing stays a manual, human action. Claude Code can prepare a container export, generate the JSON for a new tag, or write the script that calls the GTM API. The actual publish click — or the API call that triggers it — is a deliberate step taken by whoever is responsible for the account, ideally after checking the change in GTM’s own Preview mode.

Second, anything Claude Code appears to know about a specific GTM account is only what was explicitly given to it in that session — an exported file, a pasted snippet, or a page opened in the browser pane — not a persistent connection to the account itself.

Used this way, Claude Code does not replace GTM’s interface or its preview and debug mode; it removes a layer of manual re-reading and copy-paste work around it, on a container that a person still reviews and publishes.