Agency specialized inGoogle Tag Managerwith architecture, documentation and container governance.
We design and maintain GTM containers that can be audited: coherent naming, folders by domain, versioning with useful notes, and a clear separation between what marketing fires and what product fires. Client-side, server-side, or both as appropriate.
GTM is a powerful tool that turns into technical debt the moment maintenance stops. A container with two hundred ownerless tags is worse than not having GTM — because nobody dares clean it, and everybody keeps adding "just in case". Discipline is not optional.
Typical structure of a senior container
It adapts to the stack, but the pattern stays.
Analytics tags
GA4, Piwik, Matomo, Amplitude or whatever system you use. Configured with documented parameters and precise triggers, not generic ones.
Marketing tags
Meta, LinkedIn Insight, Google Ads, TikTok, Pinterest. With Consent Mode and Advanced Matching when they apply, and server-side events where it makes sense.
Structured data layer
Formal data layer definition with a contract between development and measurement. What can be read, what can be pushed, and who updates what.
Variables and lookup tables
Heavy use of variables and lookup tables to avoid repetition. A domain or channel change happens in one place, not fifty.
Consent Mode v2
Correct integration with CMP (OneTrust, Cookiebot, Didomi, custom). Different behavior by consent category.
Server-side container
When applicable: GTM Server on Cloud Run, Cloudflare Workers or similar. With fine control over what leaves the container and where it goes.
How to build an auditable container
From the business request to the tag in production — no shortcuts.
- L01
Contract
Every tag starts from a written business requirement: what’s measured, why and who’ll use it. Without a contract, we don’t implement.
- L02
Data layer
The page pushes information to the data layer with a documented schema. GTM only reads — it doesn’t guess — so the product team controls what’s exposed.
- L03
Container
Tags + triggers + variables organized in folders by domain (marketing / product / consent / debug). Every item with owner and description.
- L04
Server-side
When present, the server container acts as filter and router: receives events, enriches them, decides where to send them and with which transformations.
- L05
Publishing
Workflow with versioning, change notes, preview testing, approval and publish. Every change is reversible — production is never touched blind.
Tangible deliverables
Documentation and reusable assets — not blind trust in the consultant.
Exported container
Container JSON with all tags, triggers and variables documented. Yours forever — no dependency on us.
Data layer specification
Document with the contract between web/app and GTM. Which events exist, which parameters they carry, who’s accountable.
Written naming convention
Naming rules for tags, triggers and variables. Applicable by any new person without asking permission.
Publishing playbook
Written process for how a change is made: request → dev → preview → test → approval → publish. With clear roles.
Tag monitoring
Alerts when a critical tag stops firing or when an unexpected tag appears. GTM can also be watched.
Formal handover
Transfer session with the internal team (marketing, BI, IT) with practical cases. No "learn by reading the container".
GTM governance principles
A healthy container is not luck — it’s process.
- 01
One owner per tag
Every tag has an identified business owner. When it doesn’t, the tag goes to the "review" folder — and from there, deleted if no one claims it.
- 02
Periodic pruning
Every quarter we review which tags didn’t fire in 90 days. Most can be deactivated — and in the next review, deleted.
- 03
Reversible changes
Every publish has notes and can be reverted in one click. Nobody deploys "because they were in a hurry" without leaving a trace.
- 04
Limited roles and permissions
Not everyone publishes. Marketing can edit in preview and request approval. Publishing lives with a small team with judgment.
- 05
Annual audit
Once a year, a full review: what fires, where, with what consent and why. With minutes.
Honest questions before hiring
Can you audit our current GTM container before touching anything?
It’s the first thing we do. We deliver a report with: tags that can be deleted with no risk, tags that need review, critical mis-configured tags, and general structure. No proposal to rebuild everything — just what adds value.
When is server-side GTM needed and when is it hype?
Server-side adds value in three cases: critical business conversions (we want them to arrive even if the browser blocks), fine control over data leaving the site (GDPR, first-party data), and very heterogeneous stacks where we want a central router. Outside those cases, client-side is usually enough.
How do you coordinate with our development team?
Through a data layer contract. Development pushes events with an agreed schema; GTM only consumes them. Nobody has to "wait for the GTM person" to deploy the site, or vice versa.
What if we already have a partner managing GTM?
We can come in as second opinion, run an independent audit and return a report to the partner. Or we can take over if the partner no longer services. No conflict — each model has its place.
Do you work with Piwik PRO Tag Manager, Matomo Tag Manager or others?
Yes. We have experience with GTM (Google), Piwik PRO, Matomo Tag Manager and Tealium. The principle (clean container, contractual data layer, versioning) applies the same across all.
Is your GTM tidy — or a container nobody dares to touch?
Give us read access to the container and we’ll return a map: what can be deleted, what needs fixing and what’s missing.
Let’s talk?GTM audit under NDA. No default proposal to rebuild everything.