GA4 and Tag Manager setups that answer business questions

Most GA4 properties I look at have plenty of data and very few answers. Dozens of events, some custom dimensions nobody remembers creating, a Tag Manager container with tags named "New Tag (3)", and a dashboard someone built once and nobody opens. The tracking is busy. It just isn't useful.

The problem is usually the order things were done in. Someone started with the tool, tracked what was easy to track, and hoped the questions would sort themselves out later. I do it the other way around: start with the decisions the business needs to make, then design the measurement to support them.

Start with decisions, not events

Before touching GA4 or Google Tag Manager, write down the handful of decisions measurement should inform. For a lead-generation site, that list is often something like:

• Which channels and campaigns produce leads that become clients, not just form fills?
• Which landing pages convert, and which only attract traffic?
• Where do people drop out of the lead path?
• Are phone calls or forms the bigger channel, and does that differ by source?
• Did the site change we made last month help or hurt?

Each question implies specific data. "Where do people drop out" means you need events for starting a form, not just finishing it. "Which leads become clients" means GA4 alone can't answer it; you need the CRM, which I covered in following one click from ad to CRM. Knowing that early saves you from pretending GA4 can answer questions it can't.

Design a small event model

Once the questions are clear, the event list is usually short. GA4 already collects page views, sessions, and some interactions through enhanced measurement. Use those, and add custom events only where a question needs them.

A lean model for a lead site might look like this:

Event	When it fires	Key event?
generate_lead	Successful form submission	Yes
form_start	First interaction with a lead form	No
phone_click	Tap on a tel: link	Yes, if calls matter
click_chat	Chat widget opened	No

generate_lead is one of Google's recommended event names; using recommended names where they fit makes the data easier to work with later. Add parameters for things like form_name and lead_type, and register any parameter you want to report on as a custom dimension, or it won't show up in standard reports.

GA4 calls the events you care most about "key events" (they used to be called conversions). Mark only the few that represent real business value. If everything is a key event, nothing is.

Naming conventions and GTM hygiene

Analytics gets messy the same way code does: slowly, through small inconsistent decisions. A few rules keep it readable:

• Event names: lowercase with underscores, verb or object first, consistently. form_start, not FormStart in one place and start-form in another.
• GTM tag names: platform, type, and detail. For example GA4 - Event - generate_lead or Ads - Conversion - Lead form.
• Triggers and variables: named for what they detect, like Form Submit - Case Review or DLV - form_name.
• Folders grouped by platform or purpose.

In Tag Manager itself:

• Use workspaces for separate pieces of work, so half-finished changes don't ship with someone else's publish.
• Name and describe every version when you publish. "Added phone_click event, removed old chat tag" is a changelog. "Version 47" is not.
• Remove what's dead. Paused tags from a campaign two years ago are risk with no benefit.
• Limit publish access to people who understand what they're publishing.

Where possible, fire events from a data layer push after a confirmed server response, not from a button click. A click on "Submit" isn't a lead; a successful submission is.

Consent is part of the design

Depending on where your visitors are and what you collect, you may need consent before setting analytics or advertising cookies. That's a legal decision, and it's worth getting advice on. Technically, it means your consent tool and Tag Manager need to talk to each other.

Google's Consent Mode lets tags adjust their behavior based on the visitor's choices, using signals such as analytics_storage, ad_storage, ad_user_data, and ad_personalization. Set defaults before any tags fire, update them when the visitor chooses, and test both paths. A common mistake is a banner that looks compliant while tags fire before the visitor has clicked anything.

Verify before you trust

Every change should be tested before it's published, and again after.

1. Use GTM Preview mode to confirm the right tags fire on the right triggers, and only once.
2. Open GA4 DebugView to watch events and their parameters arrive in real time.
3. Submit a real test lead and confirm generate_lead fires on success, not on a failed validation.
4. Test with consent declined and accepted.
5. Check the reports a day or two later to confirm the data landed as expected.

Inspect the system before trusting the symptom. When a number looks odd in a report, the answer is usually in the tag configuration, not in user behavior.

Don't build dashboards nobody reads

The last trap is building reporting for its own sake. A dashboard is only useful if someone looks at it on a regular schedule and makes a decision from it.

I'd rather have one short weekly view that answers the questions from the first section, including leads by source and landing page, form drop-off, and key events trend, than a dozen polished reports. If a chart hasn't changed a decision in a quarter, delete it or stop maintaining it.

The short version

• Write down the decisions first.
• Track the few events those decisions need.
• Name things so the next person can understand them.
• Treat consent as part of the build.
• Test every change in Preview and DebugView.
• Report on what people will actually act on.

If it isn't measured, you're guessing. But measuring everything without a question behind it is just a more expensive way of guessing.