How to Set Up Event Tracking in Google Analytics 4

Why GA4 Event Tracking Feels Like Starting From Scratch (And How to Actually Make It Work)

If you've recently migrated from Universal Analytics to GA4, you've probably noticed that everything you knew about event tracking has been thrown out the window. The old category/action/label structure? Gone. The familiar interface? Completely redesigned. That comfortable feeling of knowing where everything is? Yeah, that's gone too.

Here's the thing: GA4 isn't just a UI refresh—it's a fundamental rethinking of how analytics works. Every interaction is now an event, whether it's a pageview, button click, or form submission. This event-centric model is actually more flexible once you wrap your head around it, but getting there requires unlearning old habits and building new mental models.

The good news is that GA4's event tracking is genuinely more powerful for understanding user behavior. You can track practically anything without hitting the arbitrary limits of Universal Analytics, and the integration with BigQuery means you can export raw data for deeper analysis. The bad news? The setup process is scattered across multiple interfaces, the documentation assumes you know things you probably don't, and one misconfigured event can throw off your entire reporting structure. Let's fix that.

Understanding GA4's Event Architecture Before You Break Something

Before diving into setup, you need to understand how GA4 thinks about events. This isn't optional knowledge—skip this section and you'll end up with a mess of duplicate events and conflicting parameters.

GA4 has four event types, and knowing which one you're working with matters:

Automatically collected events fire without any configuration. These include things like first_visit, session_start, and page_view. You can't turn these off, but you can modify them.

Enhanced measurement events are toggle-able tracking for common interactions like scrolls, outbound clicks, site search, video engagement, and file downloads. These live in your GA4 property settings under Data Streams, and they're a common gotcha—you might already be tracking something you're about to manually configure.

Recommended events follow Google's predefined naming conventions like login, sign_up, purchase, or search. Use these whenever possible because they come with built-in reporting features and easier integration with Google Ads.

Custom events are everything else. Name them whatever you want, but be consistent because you're building your own taxonomy here.

The critical insight: events now carry parameters instead of categories and labels. An event named button_click might have parameters like button_location: header, button_text: sign_up, and page_path: /pricing. These parameters become your filtering and segmentation dimensions in reports.

Before creating any events, document your naming convention. Use snake_case consistently. Keep names descriptive but not verbose. And most importantly, plan which parameters each event needs—you can track up to 25 parameters per event, but only 50 custom parameters total across your property (though you can request increases).

Setting Up the Google Tag Manager Foundation

Most hands-on implementations use Google Tag Manager (GTM) to fire GA4 events because hardcoding tracking directly into your site is a maintenance nightmare. If you're not using a tag manager yet, set that up first—this guide assumes you have GTM installed and your GA4 configuration tag firing on all pages.

Your GA4 Configuration tag is your base layer. This should fire on all pages with the "All Pages" trigger, and it handles the basic pageview tracking. Find this in GTM under Tags, and verify your Measurement ID is correct (it starts with "G-").

Here's a practical workflow for event setup in GTM:

First, identify what you want to track in your browser's console. Right-click the element (a button, link, form field, whatever) and inspect it. Look for unique identifiers—IDs are most reliable, but classes work if they're specific enough. For a pricing page signup button, you might see id="cta-signup-pricing" or class="btn btn-primary signup-cta".

Open GTM and create a new trigger. For click tracking, use the "All Elements" click trigger type (not "Just Links"—that's only for anchor tags). Set it to fire on "Some Clicks" and define your condition. If your button has id="cta-signup-pricing", use "Click ID equals cta-signup-pricing". Always test specificity—your condition should only match the element you intend.

Now create the event tag. Choose "Google Analytics: GA4 Event" as the tag type, select your GA4 Configuration Tag in the Configuration Tag field, and name your event. Let's say cta_click. This is where parameter planning matters.

Add parameters as event parameters in the tag configuration. Use the "Add Row" button to add each one. For our example, you might add button_location with value "pricing_page", button_type with value "primary_cta", and button_text with value "Sign Up Free". You can use GTM variables here too—{{Click Text}} captures the actual button text, {{Page Path}} grabs the current URL path.

Connect your new event tag to the trigger you created, save everything, and use GTM's Preview mode to test. Click your button in the preview browser and verify the event fires with all expected parameters in the Tag Assistant panel.

Creating Events for the Stuff You Actually Care About

Theory is great, but let's track some real-world interactions. Here are specific configurations that commonly matter for SaaS products, content sites, and web apps.

Form submissions are trickier than they appear because forms can behave differently. For standard HTML form submissions, create a Form Submission trigger in GTM, set conditions to identify your specific form (by form ID, form class, or page URL), then create a GA4 event tag. Use the recommended event name generate_lead if it's a contact form, or sign_up for registration. Include parameters like form_location, form_name, and page_path.

For forms that submit via AJAX without page reloads, you'll need a different approach. If your developers can add a data layer push when the form submits successfully, that's most reliable. Otherwise, you can trigger on a success message appearing using a Visibility trigger in GTM—configure it to fire when an element with your confirmation message ID becomes visible.

Scroll depth tracking is already available via Enhanced Measurement, but the default implementation fires at 90% scroll. For longer content, you might want more granular tracking. Create a custom scroll trigger in GTM firing at 25%, 50%, 75%, and 100%, then send those as a scroll_depth event with a parameter indicating the depth percentage. Use the built-in {{Scroll Depth Threshold}} variable to capture the percentage automatically.

Video engagement gets messy fast. Enhanced Measurement handles YouTube videos automatically (if enabled), but custom video players require manual setup. Most modern players fire JavaScript events you can listen for. For a typical HTML5 video, create triggers listening for play, pause, and completion. Use the Video trigger type in GTM if your player supports it, otherwise use custom JavaScript. Send events like video_start, video_progress, and video_complete with parameters for video title, duration, and percent watched.

User interactions with specific features often matter for product analytics. Tracking when someone opens a modal, activates a specific tool, or changes a setting requires identifying the interaction point. Use click triggers for buttons, form submission triggers for toggles and dropdowns, or element visibility triggers for modal appearances. Name these events descriptively—tool_activated, filter_applied, modal_opened—and always include context parameters like which tool, which filter values, or which modal.

Validating Your Events Actually Work (Before Your Boss Notices They Don't)

Publishing tracking changes without validation is how you end up with three months of bad data and no way to fix it. GA4's real-time reports and DebugView are your safety net.

In GTM, hit "Preview" and enter your site URL. This opens Tag Assistant in a new window showing your site with debugging active. Navigate to the page with your event trigger and perform the action. In the left panel, you'll see the event fire in real-time. Click it to expand details—verify your event name is correct, all parameters are present, and values look right. Common issues: parameters with undefined values, events firing multiple times per action, or events not firing at all because your trigger conditions are too specific.

For events that fire correctly in Tag Assistant, check GA4's DebugView. In your GA4 property, go to Configure > DebugView in the left menu. This shows a live stream of events from your debugging session. You should see your custom event appear within seconds with all its parameters. If Tag Assistant shows the event but DebugView doesn't, your Measurement ID might be wrong or your GA4 Configuration tag isn't firing properly.

Once events appear in DebugView, wait 24-48 hours and check the Events report under Reports > Engagement > Events. Your custom events should appear in the list with counts. Click an event name to see its parameters in the right panel. If parameters aren't showing, you might have exceeded the 50 custom parameter limit, or you need to mark them as custom dimensions.

Speaking of custom dimensions: any event parameter you want to use in exploration reports or as a filter needs to be registered as a custom dimension. Go to Configure > Custom Definitions, click "Create custom dimension", and map your parameter name to a dimension. You can have up to 50 event-scoped custom dimensions (125 for Analytics 360). Do this for your most important parameters like button locations, form types, or video titles.

Build a simple Exploration report to validate your tracking is usable for actual analysis. Go to Explore in the left menu, start a blank exploration, add your custom event as a dimension, drag relevant parameters as secondary dimensions, and add Event Count as a metric. If you can segment and filter your data meaningfully, your tracking is working.

Avoiding the Parameter Chaos That Destroys Your Reports Later

Six months from now, you'll have dozens of events with hundreds of parameters, and you'll forget what half of them mean. Trust me on this: documentation and naming conventions aren't optional.

Create a tracking specification document before you build anything complex. Use a spreadsheet with columns for event name, event type (recommended vs custom), when it fires, what user action triggers it, each parameter name, parameter value format, and why you're tracking it. This sounds tedious, but it takes 30 minutes now or 30 hours of detective work later when you're trying to figure out why your conversion funnel doesn't make sense.

Enforce consistent parameter naming across all events. If you use page_path in one event and page_url in another for the same thing, you've just made cross-event analysis unnecessarily complicated. Common parameters like location identifiers, user types, or page categories should use identical naming everywhere they appear.

Be strategic about event volume. Every event costs processing power and counts toward quotas (though GA4's limits are generous). Don't track every single click on your site—track the interactions that inform decisions. Ask yourself: what would I do differently if this number changed by 50%? If the answer is "nothing," you probably don't need that event.

Use event naming to create logical groupings. If you're tracking multiple calls-to-action, prefix them consistently: cta_header_signup, cta_footer_demo, cta_pricing_trial. This makes filtering easier and helps in Exploration reports where you can use "contains" filters.

Parameter values should be predictable and normalized. If a parameter can have ten values, document all ten. Don't let developers pass raw strings that might be "Pricing Page", "pricing_page", or "/pricing" for the same thing. Standardize the format (probably snake_case for consistency with event names) and enforce it in your GTM variables or through data layer specifications.

Making Your Tracking Scale Beyond This First Setup

You've got basic event tracking working, but your site will evolve. Here's how to build a system that doesn't break every time someone updates the website or launches a new feature.

Use GTM's data layer instead of relying on DOM scraping when possible. Have your developers push structured data when important events occur: dataLayer.push({'event': 'formSubmit', 'formName': 'newsletter', 'formLocation': 'blog-sidebar'}). Then create Custom Event triggers in GTM listening for these data layer events. This approach is more resilient to design changes and more accurate than trying to detect form submissions through DOM manipulation.

Create reusable variables for common values. If you're using {{Page Path}} in fifteen different events, that's fine. But if you're repeatedly extracting the same information—like determining the site section from the URL—create a Custom JavaScript variable that does this logic once and reuse it everywhere. This makes updates easier and keeps logic consistent.

Implement server-side tagging if you're dealing with serious traffic or need better data control. GA4 supports sending events from your server instead of the browser, which is more reliable (no ad blockers), more secure (sensitive data doesn't go through client-side JavaScript), and more accurate (no network failures). This is more complex to set up but worth considering for critical tracking like transactions or lead submissions.

Build monitoring into your workflow. Set up custom alerts in GA4 (Configure > Custom Insights) that notify you if critical events suddenly drop to zero or spike unexpectedly. This catches broken tracking before you lose weeks of data.

Version control your GTM container. Before making changes, use Versions in GTM to create a snapshot of your current setup. Name it descriptively with the date and what changed. If something breaks, you can roll back in seconds instead of trying to remember what you modified.

What to Do Right Now

You've got the framework—here's your immediate action plan. First, audit what's already tracking. Check Enhanced Measurement settings in GA4 and your existing GTM tags. You might already be collecting some of what you need.

Second, identify your top five critical user interactions. Don't try to track everything at once. Pick the actions that directly correlate with business outcomes: signups, purchases, demo requests, feature activations, whatever matters for your specific case.

Third, set up those five events properly with meaningful parameters. Test each one in Preview mode and DebugView. Register the parameters you need as custom dimensions. Build a simple Exploration report to verify you can analyze the data.

Finally, document everything in a tracking spec and schedule a monthly review. Check that events are still firing, data makes sense, and new features have appropriate tracking. GA4 event tracking isn't a set-it-and-forget-it task—it's an ongoing practice that improves as you learn what questions you actually need to answer.

The shift to GA4's event model is genuinely an improvement once you get past the learning curve. You have more flexibility, better data structure, and fewer arbitrary limits than Universal Analytics ever offered. But that flexibility requires intention—random tracking without planning creates noise, not insight. Build deliberately, validate constantly, and you'll actually understand what your users are doing instead of drowning in meaningless metrics.