A GTM container rarely becomes a mess in one bad decision. It happens through many reasonable ones: a tag for a campaign, a copy of a tag for a test, a quick fix nobody revisits. After a few years, nobody dares to delete anything, and each new request takes longer because no one knows what might break. Four habits keep this under control.
Check the request before you build
A request usually describes a solution: "Add a tag for PDF clicks." Before opening GTM, find the question behind it. Which decision will this number support? Who will use it, and how often? If no one can answer, the work may not be worth a permanent item in the container.
Then check whether the data already exists. In this hypothetical request, GA4 enhanced measurement can already collect file downloads as an event. If it is enabled and covers the file types involved, the answer may be a report, not a tag. A second tag would also risk counting the same action twice.
This is not about refusing work. It is about noticing when the cheapest correct change is no change, and writing that down as the outcome.
Make the smallest change that solves it
When a change is needed, keep it narrow. Each release should have one purpose, so that if something breaks, you know what caused it and what to reverse. Some useful defaults:
- Reuse an existing trigger or variable if it means exactly what you need. Create a new one if the meaning differs, even when the settings look the same today.
- Use a supported tag template where one exists. Google notes that this is usually more efficient than custom code, and a template is easier for the next person to read.
