01
How Google Tag Manager works
Tags send information, triggers determine when they run, and variables supply values. The dataLayer creates a stable contract between the site and tracking rather than relying on fragile button selectors.
Preview mode explains what fired and why. Named versions, notes and accountable publishing make changes traceable and reversible.
A robust dataLayer push can use event: 'generate_lead' with form_id and lead_type while excluding personal data. A Custom Event trigger listens for that name and Data Layer Variables pass fields into GA4. In Preview, confirm the event appears in sequence, variables are populated at that exact point and the destination tag appears under Tags Fired once rather than on both click and success.
02
Client-side vs server-side GTM
Client-side GTM runs in the browser. Server-side GTM receives selected signals on a first-party domain and forwards only what is required.
Server-side offers more control and may reduce browser scripts, but adds hosting and operational complexity. Many mature setups use both.
Keep client-side for straightforward measurement where browser tags can send approved events directly. Consider server-side when several platforms need one validated event, payload fields require central control or transport should use an owned subdomain. Measure performance before and after. A server container does not reduce browser work if all the same vendor libraries still load on the page.
| Area | Client-side | Server-side |
|---|---|---|
| Data | Browser dependent | Greater control |
| Speed | More browser scripts | May reduce scripts |
| Cost | No GTM licence | Hosting and operation |
| Complexity | Lower | Higher |
03
Checklist for a healthy GTM container
Consistent names, no duplicates, consent checks, documented dataLayer events and tested triggers make a container predictable.
Restrict publishing access, write useful version notes and conduct regular reviews of tags and users.
Begin an audit with Versions and Workspace Changes. Compare active tags with actual browser requests, pausing uncertain legacy tags before deletion. Names such as 'GA4 | Event | generate_lead' expose platform, type and purpose. Review built-in consent checks for every tag. A tag without an obvious trigger may still run through sequencing or a trigger group, so test behaviour rather than relying on the list view.
- 01Consistent naming
- 02No duplicates
- 03Consent controls
- 04Documented dataLayer
- 05Tested triggers
- 06Version notes
- 07Restricted access
- 08Regular reviews
04
Enhanced conversions and Conversions API
Enhanced conversions use consented, normalised and hashed first-party details to support Google Ads matching. Meta Conversions API sends corresponding events through a controlled server flow.
Consent, formatting and deduplication are essential. Match rate is diagnostic; the objective is more reliable measurement and qualified optimisation.
For enhanced conversions, collect email or telephone details only at the completed action, normalise them to Google's required format and avoid leaving them in the dataLayer. Review implementation status in Google Ads Diagnostics. Browser and server copies need the same event_id for deduplication. Never send placeholders to improve match rate because false identifiers weaken both reporting and optimisation.
05
GTM and consent
Consent Mode translates a visitor's choice into signals for Google tags. GTM must set defaults before other tags and update them after a choice.
Test first visits, changed choices and withdrawal in Tag Assistant and browser network tools. Document responsibilities across the banner, website and container.
Consent Initialization must precede ordinary Initialization. Set relevant defaults to denied, then let the CMP issue an update after the visitor chooses. Preview should show both On-page Default and On-page Update. A tag requiring analytics_storage must not fire after rejection. Test withdrawal as well as acceptance, because future requests must stop when the visitor changes their choice.
