GA4 and Google Tag Manager implementation best practices

Start with a measurement plan. Before anyone opens Google Tag Manager, agree on the business questions the data has to answer and the events that answer them. Then have developers push that data into a data layer, keep the GTM container tidy, configure consent, key events and filters, and test against your CRM or order system before a number goes in front of leadership.

Universal Analytics stopped processing data on July 1, 2023, so most organizations have been on GA4 for a while. A lot of them migrated in a hurry and carried the old category/action/label events straight across. What follows is the setup we would put in place if our names were on the numbers.

Start GA4 with a measurement plan

A measurement plan is a short document that ties business goals to the data you collect. It heads off the two failures we see most: tracking everything and learning nothing, and finding out six months in that the one metric the CFO wants was never captured.

Build it in this order:

1. Business questions. Write down the questions leadership actually asks. "Which channels produce qualified pipeline, as opposed to form fills?" is useful. "How is the website doing?" is not.
2. KPIs. For each question, name the metric, define it and say where its source of truth lives. Revenue belongs to the order system or CRM. GA4 shows the path people took to get there.
3. Events and parameters. List the user actions behind each KPI and the context each one needs, such as form type, product, plan tier or content group.
4. Dimensions and audiences. Note which parameters have to be registered as custom dimensions, and which audiences marketing will want for remarketing or analysis.

Put the plan somewhere engineering, marketing and analytics can all read it. Later it doubles as the data layer specification and the QA checklist.

Event naming conventions and taxonomy for GA4

In GA4 every interaction is an event with parameters. That is flexible, and it is also how you end up with three teams naming the same action three different ways. A few firm rules prevent most of the mess.

• Use Google's recommended events when one fits. generate_lead, sign_up, login, purchase and begin_checkout fill standard reports and behave predictably with Google Ads. Invent a custom event only when nothing recommended matches.
• Use short snake_case names, verb first where you can. GA4 caps event names at 40 characters and reserves prefixes like google_, ga_ and firebase_.
• Put the variation in parameters. A single generate_lead event with a form_id parameter is far easier to report on than separate contact_form_submit, demo_form_submit and newsletter_form_submit events.
• Never send personally identifiable information (email addresses, names, phone numbers) in event names, parameters or page URLs. Google's terms prohibit it, and once it is collected it is hard to get out.

One thing catches people out: a parameter won't show up in standard reports until you register it as a custom dimension or metric in GA4 admin. Registration doesn't apply to data already collected, so do it the day the parameter launches.

Build the data layer first

The data layer is a JavaScript object where your site publishes structured facts about what just happened and the business context around it. GTM reads from it. The alternative is scraping CSS selectors and button text, which works until a designer renames a class or a copywriter edits a label.

In practice, developers push an event at the moment it becomes true (after the form validates, after the order is confirmed), and GTM maps those values into GA4. A lead form, for example, might push this after a successful submission:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'generate_lead',
  form_id: 'demo_request',
  lead_source: 'pricing_page',
  value: 0,
  currency: 'USD'
});

Keep a data layer specification that lists every event and key, and have developers maintain it next to their code. For ecommerce, clear the previous object with dataLayer.push({ ecommerce: null }) before pushing a new one, or stale items can leak into the next event. Fire purchase on the confirmation step with a unique transaction_id. GA4 uses it to drop duplicates when someone reloads the page.

Keep the Google Tag Manager container organized

A GTM container turns into a liability once nobody can say what a given tag does or whether it's still needed. We treat it like code.

• Name things consistently. A pattern like Platform - Type - Detail works: GA4 - Event - generate_lead for a tag, Trigger - CE - generate_lead for a custom event trigger, DLV - form_id for a data layer variable.
• Group tags, triggers and variables into folders by platform or function (GA4, Google Ads, Meta, consent, utilities) so anyone auditing the container can see what's there.
• Use one Google tag for the GA4 property. Event tags should pull its measurement ID from a constant variable rather than repeating a hard-coded string.
• Give each change its own workspace so unrelated edits don't go live together. Free containers only allow a few workspaces, so close them when the work is done.
• Test each version in a staging environment tied to your staging site before publishing it.
• Name every published version and describe what changed, why, and which ticket it relates to. When a number moves unexpectedly, this is your audit trail.
• Let many people edit, but only a few publish.

Consent mode v2 basics

Consent mode tells Google tags how to behave based on what a visitor agreed to. Version 2 added two signals, ad_user_data and ad_personalization, alongside the original ad_storage and analytics_storage. Google requires them for advertisers using its ad features with users in the European Economic Area, and they're sensible anywhere privacy law applies.

The usual GTM setup:

1. Pick a consent management platform (CMP) that has a GTM template, and fire it on the Consent Initialization trigger.
2. Set default consent states before any Google tag loads. What those defaults should be in each region is a legal call, so get counsel to make it.
3. Update consent when the visitor chooses, and check that the update fires before any tag that depends on it.
4. Choose basic mode (tags wait for consent) or advanced mode (tags load and send cookieless pings when consent is denied, which GA4 can use for modeling). This has legal and data-quality consequences, so write down who decided.

Non-Google tags ignore consent mode. Set their consent requirements in GTM's consent settings or in the CMP. Otherwise they fire whatever the visitor chose.

Configure key events, cross-domain tracking and filters

A handful of GA4 property settings decide whether your reports can be trusted, and most people don't look at them until something is off. Set them before launch.

• Key events. GA4 now calls conversions "key events" and keeps the word "conversions" for the ones used in Google Ads. Mark only real business outcomes (generate_lead, purchase, sign_up) as key events. If every click is a key event, the number means nothing. Import into Google Ads only the ones you want bidding to optimize toward.
• Cross-domain measurement. If a visit crosses domains you own, say a marketing site and a separate booking or checkout domain, list all of them in the data stream's domain settings. Otherwise the session restarts as a referral.
• Unwanted referrals. Add payment processors and identity providers that send people back to your site. If you don't, they get credit for your conversions.
• Internal and developer traffic. Define internal traffic by IP range and create a data filter. Leave the filter in testing state until you've confirmed it catches the right traffic, then activate it. Filters don't apply to past data, and anything they exclude is gone for good.
• Data retention. Exploration data is kept for two months by default. Most organizations should raise that to the longest period their account allows.

QA, governance and common mistakes

Publishing the tags doesn't finish the job. You're done when the data matches what actually happened. Run this checklist on every release:

• Use GTM preview mode (Tag Assistant) to confirm each tag fires once, on the right trigger, with the values you expect.
• Check GA4 DebugView to confirm events and parameters arrive with the right names and types.
• Test with consent granted and denied, on desktop and mobile, and through any cross-domain hops.
• Place a real test order or submit a real lead, and confirm exactly one event arrives with the correct transaction_id or form_id.
• After a few days, compare GA4 with the CRM or order system. The totals won't match exactly, because consent choices, ad blockers and attribution rules all get in the way. The gap should hold steady and be explainable, though. If it suddenly changes, assume a bug until you find otherwise.

After launch, someone has to own it. Name an owner for the GA4 property and the GTM container. Keep the measurement plan, data layer specification and tag inventory up to date. Review access every quarter and remove people who have left. Don't allow a publish without a ticket and a version note.

Once the data is clean, the next question is which metrics belong on the dashboard. Our guide on how to measure digital marketing performance covers that. And if you'd rather have experienced practitioners write the measurement plan, spec the data layer and audit your container, that's the bulk of our analytics and measurement services for GA4, GTM and data layers.