Google Tag Manager

GTM is the default answer to “how do we get tags on the page,” and its vocabulary — container, dataLayer, trigger, variable — has become the shared language of web tracking. Sites push events into the dataLayer array; triggers listen for them and fire tags, with variables resolving values at fire time. Versioned workspaces, preview/debug mode, a community template gallery, and built-in consent checks per tag round out a mature, well-documented toolchain that nearly every vendor ships a template for.

How it models data. The dataLayer is a message queue, not a database: Google’s docs are explicit that messages are processed first-in, first-out, one at a time. A push with an event key can fire triggers; pushes without one just set variable values. Pushing a variable with the same name as an existing one overwrites it, and values persist only for the current page — anything you need on the next page must be pushed again, ideally above the container snippet so it’s available before the first tags fire. Only one dataLayer object is supported per page, and the name is case-sensitive (dataLayer, not datalayer), though it can be renamed in the snippet if something else already claims the name.

Implementation notes. The classic dataLayer mistake is assigning dataLayer = [...] after the container loads, which replaces the instrumented array and silently kills tag firing; Google’s docs tell you to always use window.dataLayer = window.dataLayer || []; and then push(). Consent mode is wired in at the platform level: pages declare defaults for ad_storage, analytics_storage, ad_user_data, and ad_personalization before any measurement runs, update them when the user interacts with the banner, and Google’s built-in tags respect the resulting state automatically — custom templates use the setDefaultConsentState/updateConsentState APIs instead of gtag commands to avoid timing conflicts. CMP vendors like OneTrust, Cookiebot, and Usercentrics ship consent templates that drive these signals.

The server-side option. The web container loads client-side from Google’s domain, which is exactly what content blockers and browser tracking prevention target. Google’s answer is the separate server container: it runs in your own Google Cloud project (Cloud Run is the recommended deployment) or another environment you choose, receives hits via “clients” that transform requests into events, and Google strongly recommends serving it from your first-party domain before sending production traffic. That buys first-party delivery and control over what leaves the browser — at the cost of cloud hosting you now operate and pay for, since the free product ends at the container software itself.

Governance is the real long-term cost. Ubiquity means containers accumulate stale tags, untracked custom HTML, and permissions sprawl. Workspaces, versioning, and granular access controls exist, but the free product won’t enforce hygiene for you; that discipline is on your team.

Use it when you need a free, universally supported container with the largest template and hiring pool in the category. Look past it when you need contractual SLAs beyond the free tier, first-party control over tag delivery without running your own server container, or your stack is already committed to Adobe or Tealium end to end.