GTM stores your workspace state internally and presents it through a UI. The state is also exportable as JSON, which means you can put it in git and treat tag manager changes like any other code change. Most teams do not bother. The teams that do find it transforms how they manage tag complexity.

The export

In GTM, Admin > Export Container. You get a JSON file with every tag, trigger, variable, and built-in setting. It is verbose but human-readable enough to diff.

For sGTM specifically, the same export works on the server-side container. The structure is the same; the tag templates and clients are different.

A scheduled export job

Set up a daily job (cron, GitHub Action, your CI of choice) that:

1. Authenticates to the GTM API.
2. Pulls the current container state as JSON.
3. Writes the JSON to a file in your repo (e.g., gtm/server-container.json).
4. Commits and pushes if the file changed.

After a few weeks, your git history shows every change to the container, who made it, and when. Plus diffs.

Reading the diffs

The JSON is verbose but the meaningful diffs are small. A new tag adds 10-20 lines. A trigger change shows up clearly. Renamed variables, modified tag parameters, all visible in standard git diff output.

Add a CODEOWNERS file mapping the GTM JSON to the people responsible. Tag changes are now reviewable in pull requests.

Restoring from a previous state

If you need to roll back to a state in git, the GTM Import Container function takes the same JSON format. Import overwrites the workspace; review the diff before publishing.

This is a much more powerful rollback than the GTM Versions tab, because git history goes back further and includes the per-change context.

CI checks worth running

• Lint: every tag has a non-empty Notes field.
• Lint: no tag fires on the default "All Pages" trigger except where explicitly approved.
• Lint: hashed PII fields are referenced from a single approved hashing variable, not duplicated across tags.
• Verify: the diff between staging and production containers is non-zero only in expected ways.

For teams running multiple regional containers, the diff check is especially valuable as a drift detector.