Review a tag manager release the way you review a pull request: someone other than the author reads the version diff, checks every new domain and custom script, tests in preview, and records who approved it. OWASP recommends reviewing tag manager changes as application code because containers can run custom JavaScript.
Why a tag change is a code change
A tag looks like a marketing setting, but a Custom HTML tag is code that runs in your visitors' browsers with the same access as your own scripts. Google's help page for custom tags says the best way to avoid performance and malware issues is to use the templates built into Tag Manager. Anything custom deserves the scrutiny of a deploy.
A five step routine
- Describe the change. The author writes what is changing, why, and which pages are affected. One or two sentences is enough.
- Submit as a version, not a live edit. Tag Manager lets people with Approve or Publish create versions. Edit users work in a workspace and hand off.
- Read the diff. In Tag Manager, open Versions, choose the version, and use the Version Changes card to see what changed. For a Custom HTML tag you can expand the code with differences highlighted. Google notes that the code is minified, which can change single quotes to double quotes, so do not panic at cosmetic differences.
- Check the new reach. For each new or edited tag, ask four things. What domains does it contact? What data does it read? Which triggers fire it? Is it on a page with a form, a login or a payment step?
- Preview, then publish. Test in preview mode on the key pages. Publish only after a reviewer other than the author signs off, and note the version name in your change log.
What a reviewer looks for
| Red flag | Why it matters |
|---|---|
| A new third party domain | New party with code on your page |
| Code that reads form fields | Possible capture of typed data |
| A loader that fetches more script | Contents can change after review |
| Triggers on all pages | Wider reach than the stated purpose |
| Tags pasted without a vendor source | No one to ask if it breaks |
Rollback is part of review
Decide before publishing how you would undo it. Name the previous version, and make sure someone with Publish is reachable for the next hour. A tag that breaks checkout is cheaper to fix when the path back is known.
Make it stick
Small teams skip review because publishing is easy. Cut the friction instead of the step: use a short template, keep reviews to a few minutes, and limit Publish to the people who will actually read the diff. The publish access guide covers the permission side. To see what is loaded today, start with the script inventory method.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a change waits for a check before it can merge, then picture the same pause before a tag release.
Where Safeguard fits
For code in your repositories, Safeguard's policies and gates can require checks before a merge, and dependency scanning plus SBOM cover bundled packages. Run a free scan to see what your bundled dependencies contain.
Quick check
Is a tag manager change really a code change?
Yes when it includes custom JavaScript or HTML. OWASP notes containers can execute those tags in the browser.
Who should approve a release?
Someone other than the author, who has read the version diff and knows which pages the container covers.
Sources
- OWASP Third Party JavaScript Management Cheat Sheet
- Google Tag Manager Help: custom tags
- Google Tag Manager Help: user permissions
Last reviewed: 19 October 2026.
