GTM Container Build on a Data Layer Your Devs Own

If your shop runs on Shopify, no container we build will ever see the checkout. checkout.liquid was retired in August 2025 and purchase events now come out of a Web Pixel running in a sandboxed frame with no access to the page. On Shopware 6 the checkout is yours, but the same principle decides the outcome: a container is exactly as reliable as the data layer underneath it, and a container built by reading the DOM breaks on the next theme deploy, silently, on a Friday. So the first deliverable is not a container: It is a data layer specification your developers implement in the shop code and keep in their release process. Event names, the object shape for each, which template pushes it, and when relative to the page render. A shop needs perhaps a dozen events that anyone will ever act on. We argue that list down with you rather than up, because every event that exists must be QA'd forever. The container itself: Built in one workspace per change, exported as JSON into your Git repository and reviewed as a pull request, so a year from now the question "who added this tag and why" has an answer with a name on it. Environments configured properly: development, staging and live, with the staging container wired to a test property rather than to production with a filter someone will forget. Consent handled at the source. Defaults denied, written in the page head before GTM loads — not in a tag inside GTM, which arrives too late — with wait_for_update tuned to your CMP's actual response time. We work with Usercentrics and Cookiebot most often; whichever you run, the consent categories map explicitly to individual tags, and we test the declined path, not only the accepted one. Most inherited containers we open have been tested only by someone who clicked Accept All. Custom templates instead of custom HTML wherever a vendor provides one, so the tag runs in the sandbox and your CSP stays meaningful. Tags fired on consent state changes rather than on page load with a prayer. The tag audit that comes with it: Every existing tag gets a named owner and a stated legal basis, and tags that fail both get switched off in a version you can roll back in one click. In every container of any age we have inherited, something is still firing for an agency the client stopped working with years ago. Handover includes a written QA protocol: the events, the trigger conditions, the expected data layer payload, and how to verify each in Tag Assistant and in the network tab, so your team can run the check after their next deploy without us. What we do not do: We do not scrape the DOM for revenue. Price parsed from a CSS selector is a defect waiting for a redesign. We do not use auto-event listeners and click triggers as a substitute for a developer ticket. It looks faster in week one and costs a quarter of an analyst's year afterwards. We do not install tags for vendors who cannot name a legal basis, regardless of who inside your business promised them the placement. We do not take container work where the development team has not agreed to own the data layer. That is not a scoping preference. Without it, the work degrades within two releases and we would rather not be the ones who delivered it. Who this is not for: Teams looking for a container to compensate for a front end nobody is allowed to change. Anyone who wants marketing to be able to add tags without review; we will set up that governance, but we will not pretend it is safe. Shops with one product page and no plan; the effort is not repaid. We work in English and German, and the specification is written so a developer who has never used GTM can implement it.