A 300-tag container, audited before launch

The client is a US national health non-profit, ahead of a website redesign. Their tag manager container had grown for years under many hands: 300 tags, 293 triggers, 152 user-defined variables, 28 folders. The redesign team had been working in a second workspace, and the two had drifted apart. Nobody could say which version of any tag was right or what would stop firing when the redesign published. Before the launch committed anything, the team wanted an audit of what was actually in the container and what the two workspaces disagreed on.

• The container held 300 tags, 293 triggers, 152 user-defined variables and 28 folders, built over years by many hands, with no written description.
• The redesign team had been working in a second workspace that had drifted from the live one, and nobody could say which version of any tag was right.
• The team could not predict what would stop firing when the redesign published.
• No reconciled list existed between the live and redesign workspaces, so publishing one over the other was a guess.
• A redesign is when tracking breaks, and a 300-tag container is where the breakage hides.
• The client needed a technical, point-to-point report, not a narrative, so the redesign team could decide item by item.

• Audit the live workspace end to end: every tag, trigger, and variable checked for use, duplication, and consistency.
• Compare the live workspace against the redesign workspace, item by item, and classify every difference.
• Identify the live-only items that would be lost or orphaned if the redesign workspace was published over the top.
• Deliver a client-facing report with every finding, what is wrong, what to do, and which workspace wins.
• Give the container a written description for the first time, so every future change can be checked against a baseline.
• Hand the redesign team a reconciled, prioritised list to work through before publish.

• Exported and audited the live workspace: every tag, trigger and variable checked for use, duplication and consistency.
• Logged 329 findings across tags, triggers and variables in the live workspace.
• Compared the live workspace with the redesign workspace item by item and classified each of 62 differences: 21 changed in the redesign workspace, 1 added, 40 present only in live.
• Flagged the 40 live-only items as the ones that would be lost or orphaned if the redesign workspace was published blind.
• Wrote up every finding and difference as a client-facing Excel report, point to point: item name, what is wrong, what to do, which workspace wins.
• Delivered in the technical tone the client asked for, so the redesign team decides item by item instead of guessing.
• Delivered across two weeks: container export and audit (week 1), 329 findings logged (week 1), workspace comparison and 62 differences (week 2), Excel report with next steps.
• Framed the engagement as Audit + recommendations → Fix (clean-up and reconciliation) → Care, so the container never grows blind again.

• 329 findings logged across tags, triggers, and variables in the live workspace, each with the item name, what is wrong, and what to do.
• 62 workspace differences classified: 21 changed in the redesign workspace, 1 added, 40 present only in live.
• 40 live-only items caught before publish. Blind publishing would have dropped or orphaned every one of them.
• 1 reconciled, prioritized list handed to the redesign team, so each of the 62 items is decided on purpose instead of discovered after launch.
• 329 findings turned into a clean-up backlog with priorities, replacing a container nobody understood with a first, second, and third step.
• The container has a written description for the first time. Every future change now has a baseline to be checked against.