The Real Problem With GA4 Event Tracking
GA4’s event-based model is fundamentally better than Universal Analytics’ session-based approach, but the migration broke most teams’ confidence in their tracking. If you feel like you’re drowning in events you didn’t ask for while missing the ones you actually need, you’re in good company. The fix isn’t learning every feature GA4 offers. It’s building a clear, minimal tracking plan that maps to business questions, then implementing it methodically with Google Tag Manager.
What we typically find on mid-market sites is a mess of automatically collected events, a handful of enhanced measurement events that may or may not be firing correctly, and zero custom events for the actions that actually matter to the business. The reports look busy but answer nothing. This article walks you through how to think about GA4 events, what to track, how to implement it cleanly, and how to avoid the mistakes that make teams abandon their analytics entirely.
Why GA4 Events Feel So Confusing
Universal Analytics had a rigid hierarchy: sessions contained pageviews, which could have events attached. Events themselves followed a strict Category / Action / Label structure. You could argue about naming conventions, but the framework was clear. GA4 threw all of that away. Everything is an event now. A pageview is an event. A scroll is an event. A purchase is an event. A custom button click is an event. They’re all just events with different names and different parameters.
This is actually a better architecture for modern web behaviour, where a user might interact with a single-page app, watch a video, fill out a multi-step form, and chat with a bot, all without triggering a traditional “pageview.” But the flexibility creates a problem: there’s no default structure forcing you to organise your tracking. If you don’t impose your own discipline, you end up with a sprawling, incoherent list of events that nobody can interpret.
The confusion is compounded by GA4’s three tiers of events, which behave differently and are set up in different places. Understanding these tiers is the first step to regaining control.
Automatically Collected Events
These fire without you doing anything. They include session_start, first_visit, and user_engagement. You can’t turn them off, you can’t rename them, and you shouldn’t try to replicate them. They provide baseline session and user data. Accept them and move on.
Enhanced Measurement Events
GA4 automatically tracks things like page_view, scroll, click (outbound links), file_download, video_start, video_progress, and video_complete. These can be toggled on or off in Admin > Data Streams > Enhanced Measurement. Our team recommends reviewing these carefully rather than leaving them all on by default. The scroll event, for example, only fires when a user reaches 90% scroll depth, which is nearly useless for most content analysis. The outbound click tracking captures every external link, which can flood your reports with noise from footer links, social icons, and third-party widgets.
Turn off the enhanced measurement events you don’t need and replace them with more precise custom implementations through Google Tag Manager. You’ll get cleaner data and more control.
Custom Events (and Recommended Events)
These are the events you create yourself to track specific user actions. GA4 also publishes a list of “recommended events” with predefined names and parameter structures, like generate_lead, sign_up, and purchase. Using recommended event names where they fit is smart because GA4’s built-in reports and audiences are designed to work with them. But don’t force your tracking into a recommended event name if the semantics don’t match. A whitepaper download is not a “purchase” just because you want it to show up in a monetisation report.
Start With Business Questions, Not Technical Features
The single biggest mistake we see teams make is starting with the GA4 interface and asking “what can we track?” Start with your business instead. Sit down with whoever owns revenue, pipeline, or customer experience and ask three questions:
- What are the three to five actions on our website that directly indicate someone is moving toward becoming a customer?
- What do we want to know about how people reach those actions?
- What content or pages should be driving those actions but might not be?
For a typical B2B company with 10 to 250 employees, the answers usually converge on a short list: form submissions (contact, demo request, quote request), resource downloads (case studies, guides, spec sheets), key page engagement (pricing page views, solution page scroll depth), and perhaps chat or phone interactions. That’s probably eight to twelve custom events, not eighty.
In our projects, we define measurement requirements during prototyping, well before development starts. This means the tracking plan is baked into the site architecture rather than bolted on after launch. If you’re retrofitting tracking onto an existing site, the same principle applies: define what matters first, then figure out how to capture it. Our measurement systems guide covers this methodology in more depth if you want the full framework.
Building a Tracking Plan That Stays Manageable
A tracking plan is a simple document, usually a spreadsheet, that lists every event you intend to track along with its parameters, trigger conditions, and the business question it answers. This is the single most important artefact in your analytics setup. If you skip this step, your implementation will rot within six months.
Each row in your tracking plan should include:
- Event name (snake_case, following GA4 conventions)
- Parameters (the additional data points sent with each event)
- Trigger condition (exactly when and where this event should fire)
- Business question (why you’re tracking this)
- Implementation method (GTM tag, GA4 interface, or code)
Here’s a practical example for a B2B services company:
Event name: demo_request_submitted
Parameters: form_id, page_location, traffic_source (pulled from UTM or referrer)
Trigger condition: User reaches the thank-you page after submitting the demo request form, OR the form fires a success callback
Business question: How many demo requests are we generating, and which pages and channels drive them?
Implementation: GTM trigger on form submission success
Notice the business question column. It seems trivial, but it forces you to justify every event. If you can’t articulate what decision the event helps you make, don’t track it. This discipline is what keeps your event list from ballooning into something nobody maintains.
Implementation: Google Tag Manager Is Your Best Friend
You can create events directly in the GA4 interface using the “Create events” or “Modify events” features, but these are limited and fragile. Google Tag Manager (GTM) should be your primary implementation tool for anything beyond the basics. It gives you version control, preview mode for testing, and the ability to manage all your tags in one place.
Setting Up Your GA4 Configuration Tag
If you haven’t already, create a single Google Analytics: GA4 Configuration tag in GTM that fires on all pages. This handles the basic page_view event and connects your data stream. Every custom event tag you create will reference this configuration. Keep it clean: don’t stuff user properties or custom dimensions into the configuration tag unless they genuinely apply to every single page load.
Creating Custom Event Tags
For each event in your tracking plan, you’ll create a Google Analytics: GA4 Event tag in GTM. The event name must match your tracking plan exactly. Consistency matters enormously here. If your tracking plan says “demo_request_submitted” but your GTM tag sends “demo_request_submit,” you’ve just created a data quality problem that won’t surface for weeks.
Parameters are added as event parameters in the tag configuration. You can pull dynamic values from GTM variables, like the page URL, a data layer variable pushed by your form plugin, or a click text variable. Keep parameter names short, descriptive, and in snake_case. GA4 allows up to 25 custom parameters per event, but if you’re using more than five or six on a single event, you’re probably overcomplicating things.
Triggers: Where Most Mistakes Happen
The trigger is the condition that causes your event tag to fire. This is where implementations go sideways. Common trigger types for B2B sites:
- Form submission: Use a form submission trigger if GTM can detect the form’s submit action, or use a page view trigger on a thank-you page URL. The thank-you page approach is more reliable across different form technologies.
- Button clicks: Use a click trigger filtered by CSS class, element ID, or click text. Be specific. A trigger that fires on “all clicks” and then filters by click text “Download” will break the moment someone changes the button copy.
- Scroll depth: Use GTM’s built-in scroll depth trigger, which lets you set specific percentages (25%, 50%, 75%) rather than GA4’s all-or-nothing 90% threshold.
- Data layer pushes: The most reliable approach. Have your developer push a structured event to the data layer when an action occurs, then trigger your GA4 tag on that custom event.
The data layer approach deserves special emphasis. If you’re tracking anything more complex than a simple click or pageview, use the data layer. It decouples your analytics from your page structure, meaning a redesign or content change won’t silently break your tracking. When we set up tracking for client sites, data layer events are our default recommendation for form submissions, interactive elements, and any action that happens asynchronously.
Testing Before You Trust the Data
Untested tracking is worse than no tracking, because it gives you false confidence. GA4 provides two testing tools, and you should use both.
GTM Preview Mode lets you browse your site with a debug panel showing exactly which tags fired, which triggers activated, and what data was sent. Before publishing any GTM container changes, open preview mode and walk through every scenario in your tracking plan. Click the button. Submit the form. Scroll the page. Verify that each event fires once (not twice, not zero times), with the correct parameters.
GA4 DebugView (found in Admin > DebugView) shows events arriving in near real-time, along with their parameters and user properties. You need to enable debug mode either through GTM preview, a browser extension, or a URL parameter. DebugView is particularly useful for catching parameter issues that GTM preview won’t show, like a parameter value arriving as “undefined” or a timestamp in the wrong format.
What we typically find on mid-market sites is that roughly 20% to 30% of events have some kind of implementation error on the first pass. Common problems include events double-firing on single-page apps, form submission triggers capturing partial submissions (where the user clicked submit but validation failed), and parameters pulling null values because a variable wasn’t correctly scoped. Testing catches all of this before it pollutes your reports.
Custom Dimensions and Metrics: Turning Parameters Into Reports
Here’s something that catches almost everyone off guard: sending event parameters to GA4 does not automatically make them available in your reports. You have to register them as custom dimensions or custom metrics in the GA4 interface (Admin > Custom definitions). Until you do this, the parameter data is collected but invisible in Explorations and standard reports.
GA4 gives you up to 50 custom event-scoped dimensions and 50 custom metrics on standard (free) accounts. That sounds generous, but it can fill up quickly if you’re not disciplined. Only register the parameters you actually need to analyse. If a parameter exists purely for debugging or downstream data warehouse use, don’t waste a custom dimension slot on it.
Registration is straightforward: you give the dimension a display name, select the scope (event or user), and map it to the parameter name you’re sending from GTM. Be aware that custom dimensions only populate going forward from the moment of registration. They are not retroactive. If you forget to register a parameter and only catch the gap two months later, you’ve lost those two months of data. This is why we build custom dimension registration into our implementation checklist rather than treating it as a post-launch task.
Conversions: Marking What Matters
In GA4, any event can be marked as a conversion. You do this in Admin > Conversions (or Admin > Key Events, as Google has begun renaming these). Simply toggle the event on. From that point forward, GA4 treats each occurrence of that event as a conversion and includes it in attribution reports, audience building, and Google Ads integration.
Resist the temptation to mark too many events as conversions. A conversion should represent a meaningful business outcome or a strong indicator of intent. For most B2B companies, you’ll have three to six conversions: demo or contact form submissions, phone calls, perhaps a pricing page visit or resource download that historically correlates with pipeline. If everything is a conversion, nothing is.
One technical note: GA4 counts conversions once per session by default for most event types, but you can change this to “once per event” in the conversion settings. For lead generation forms, once per session is usually correct. You don’t want a user who rage-refreshes the thank-you page to count as three leads.
Maintaining Your Tracking Over Time
Implementation is not a one-time project. Websites change. Pages get added, forms get replaced, buttons get redesigned, third-party widgets get swapped out. Every change to your site is a potential tracking break. Teams that don’t build maintenance into their workflow end up with data they can’t trust within six to twelve months.
Practical maintenance habits that work:
- Monthly data quality check: Pull up your event count report in GA4 and look for anomalies. Did a key event suddenly drop to zero? Did an event spike unexpectedly? These are early warning signs of broken or misfiring tags.
- Pre-launch validation: Any time a developer deploys a significant site change, someone should open GTM preview mode and verify that existing events still fire correctly on affected pages. Build this into your QA process.
- Quarterly tracking plan review: Revisit your tracking plan document every quarter. Remove events that nobody uses. Add events for new features or pages. Keep the plan aligned with current business priorities.
- GTM workspace discipline: Use GTM’s workspace and versioning features. Name your versions meaningfully (“Added pricing page scroll tracking, March 2024” not “Updates”). When something breaks, you can identify exactly which change caused it and roll back.
This maintenance overhead is minimal, typically a few hours per month, but the difference between maintained and unmaintained analytics compounds rapidly. After a year of neglect, most teams are essentially making decisions on fiction.
Common Pitfalls That Waste Your Time
Over dozens of GA4 implementations, we’ve seen the same mistakes recur. Avoiding these will save you significant frustration.
Tracking everything “just in case”: More events means more noise, more maintenance burden, and more chances for something to break. Track what you’ll actually look at. You can always add events later.
Ignoring the 24-48 hour processing delay: GA4’s standard reports are not real-time. Data can take a full day or more to appear in standard reports. DebugView and the Realtime report show recent activity, but don’t panic if your new event doesn’t show in Explorations immediately after publishing your GTM container.
Duplicating enhanced measurement with custom events: If you leave enhanced measurement’s page_view tracking on and also fire a custom page_view event through GTM, you’ll double-count. Audit which enhanced measurement events are active before building custom alternatives.
Using spaces or capital letters in event names: GA4 event names are case-sensitive. “Form_Submit” and “form_submit” are two different events. Stick to lowercase snake_case and enforce it in your tracking plan. One naming inconsistency can split your data in ways that are extremely annoying to reconcile.
Forgetting cross-domain tracking: If your forms live on a subdomain or third-party platform, users will appear as new sessions when they cross domains. Configure cross-domain tracking in your GA4 data stream settings and your GTM configuration tag. This is particularly common with HubSpot, Typeform, and Calendly integrations.
Keeping Your Sanity: A Practical Recap
GA4 event tracking is not inherently difficult. It’s badly documented, inconsistently named, and poorly explained by Google, but the underlying mechanics are straightforward once you strip away the noise. Start with a short list of business questions. Build a tracking plan that maps events to those questions. Implement through GTM with data layer events where possible. Test thoroughly before publishing. Register your parameters as custom dimensions. Mark genuine business outcomes as conversions. Maintain it monthly.
If you follow this process, you’ll have a clean, trustworthy analytics setup that actually tells you what’s working on your site. You won’t need fifty custom events or a data science team. You’ll need clarity about what matters and the discipline to track only that. Everything else is optional complexity.
