GTM Container Rebuilt Around a dataLayer Contract

A container we inherit usually carries between thirty and fifty tags, and on the last several audits roughly a third of them fired on every page for a vendor nobody in the meeting could name. The first deliverable here is normally a deletion list. The second is the document that stops the list growing back. We treat Tag Manager as strictly downstream. A container cannot create data. It reads what the page already pushed, and if the page pushes nothing, the alternative is scraping the DOM, which breaks the next time a developer renames a CSS class. So the work starts with a dataLayer contract: a specification your front-end team implements, versioned in your repository, reviewed like any other interface. The order of work: Audit first. Every tag, trigger and variable in the live container gets an owner, a business question it answers, and a firing count from the last 30 days. Anything missing all three is proposed for deletion and you approve the list before we touch anything. Payload matters at this stage: we hold the published container under 120 KB uncompressed and report the main-thread cost of what remains, because a container is a script that runs before your product does. Then the contract. Event names, parameter names, types, when each fires relative to render, and what the value is when a field is absent. For a furniture retailer that means the difference between a configurator step and an add to cart is settled in writing before either is tagged. For a lead generation business it means the form event carries the CRM record identifier, because without it nothing downstream can ever close the loop. Then the container, built in a workspace, named so it survives the next person: tags prefixed by destination, triggers by the event that fires them, variables by source. Nothing called GA4 new or test do not delete. Governance after launch: Publishing rights narrowed to named people. A two-workspace convention so an agency can stage without publishing. A changelog entry required in every version description, which sounds like bureaucracy until you are trying to work out which of last quarter's forty-one versions broke revenue. You get a one-page runbook covering how a tag gets added, what has to be true before it publishes, and who signs. Out of scope: Server-side containers. Different infrastructure, different cost model, and folding it into this statement of work makes both impossible to price honestly. Consent logic. We wire tags to respect consent signals, but the CMP choice, the LGPD position and the banner itself belong to the consent engagement. Pixels for channels you have not bought yet. We tag what runs. We will decline: Builds where the engineering team will not accept a dataLayer contract. We have taken that work before and it ends the same way every time: a container held together by CSS selectors, a redesign, and a client who concludes that measurement is unreliable by nature. If your developers cannot commit to implementing a specification, this is a development problem wearing an analytics costume and we will say so rather than sell you a container. Builds intended to add collection a privacy review has not seen. We are not the party who decides what your organisation may collect. We also do not install what we would not defend in front of the people who do decide.