GA4 Custom Events Setup

Here is the thing nobody tells you when you open GA4 for the first time: the events it collects out of the box are almost never the events you actually care about. Page views, scrolls, outbound clicks — fine, but none of that is a lead, a booking or a sale. The money is in the actions GA4 doesn’t track until you tell it to. That’s what custom events are for, and setting them up properly is the difference between a GA4 property that reports your business and one that reports noise.

I set these up constantly, for our own properties and for people in the room at our trainings, and the same handful of mistakes come up every time. So this is the practitioner version: what custom events are, when to build one, the two ways to create them, and how to turn them into conversions without poisoning your historical data.

First, understand what an event actually is

In GA4 everything is an event. A pageview is an event. A scroll is an event. Every event is just a name plus a set of parameters that describe it. When someone submits your contact form, you want an event named something like generate_lead with parameters that say which form it was and what it’s worth. That’s all a custom event is: a name and parameters you define because they mean something to your business.

GA4 groups events into a few buckets. Automatically collected events fire on their own. Enhanced measurement events (scrolls, outbound clicks, file downloads, video engagement) you toggle on in the data stream settings. Recommended events are Google’s suggested names for common actions — use these names when one fits, because Google reserves them for future features. And custom events are the ones you build when nothing off the shelf matches. If you’re still fuzzy on how GA4 organizes any of this, start with our GA4 tutorial for beginners and come back — this guide assumes you can find your way around the interface.

The rule for when to build a custom event

Don’t track everything. I’ve inherited GA4 properties with sixty custom events, fifty-five of which nobody has ever looked at. Every event you create is something you have to name, maintain and reason about later. So the rule is simple: build a custom event when the action represents a step toward money, or a decision you’ll actually make based on it.

Leads, purchases, bookings, calls, quote requests, demo sign-ups, pricing-page visits with intent — yes. A click on your footer’s Instagram icon — probably not, unless social is a real part of your funnel. Before you build a single event, write down the five to ten actions that map to your business outcomes. That list is your tracking plan, and it saves you from the sixty-event swamp.

Two ways to create a custom event

There are two paths, and picking the right one up front saves a lot of pain.

Path one: the GA4 interface

Inside GA4, under Admin, there’s a Events section where you can create an event based on an existing event. This is the no-code route. It works when the action you care about already shows up as some other event you can filter on — for example, a pageview of your /thank-you/ URL. You create a new event called generate_lead that fires whenever a page_view happens with a page path containing thank-you. No developer, no tag manager.

The limitation: you can only build on data GA4 already receives. If the information you need isn’t already in an event, the UI can’t conjure it. For a thank-you page that’s fine. For a form that submits without a page change, it isn’t.

Path two: Google Tag Manager

This is the path I use for anything real. Google Tag Manager lets you listen for the actual interaction — a form submission, a click on a specific button, an element coming into view — and push a clean event into GA4 with exactly the parameters you want. It’s more setup, but it’s the only way to track actions that don’t map to a URL, and it keeps all your tracking in one maintainable place. If you haven’t got GTM installed yet, our Google Tag Manager setup guide walks the whole install, and the conversion tracking hub covers the broader plumbing this all sits inside.

Name events like you’ll read them in a year

This is the part people skip and curse themselves for later. GA4 event names are permanent in practice — you can’t rename an event after the fact without losing the continuity of its data. So decide your convention before you build anything.

My rules: use snake_case (lowercase with underscores), because GA4 does. Use Google’s recommended event names when one fits — generate_lead, purchase, sign_up, contact — so you inherit any automatic reporting Google builds around them. Be specific but not absurd: submit_contact_form beats both form and submit_contact_form_homepage_footer_variant_b. And carry context in parameters, not in the event name. One generate_lead event with a form_name parameter is far better than five differently named lead events, because you can still see them separately in reports while keeping the event list clean.

Parameters are where the value lives

An event name tells you something happened. Parameters tell you the story. A purchase event is useful; a purchase event with value, currency, and items parameters lets you report revenue, average order value and best sellers. For a lead, attach the form name, the page it happened on, and if you can, a value estimate. To use a custom parameter in reports, register it as a custom dimension or metric in GA4’s Admin, or it’ll collect but stay invisible in the standard reports.

Turning an event into a conversion (key event)

Once your event fires reliably, marking it as a conversion is almost anticlimactic. In GA4 these are now called key events. You find the event in the Events list and flip the “Mark as key event” toggle, or create the key event by name ahead of time. From that point forward GA4 counts it as a conversion, it becomes available in your reports and explorations, and it can be imported into Google Ads as a conversion action to optimize campaigns against.

One caution that bites people: marking an event as a key event only counts conversions going forward. It does not retroactively reclassify old data. So mark your key events as early as you can, and never assume yesterday’s numbers will fill in once you flip the switch today.

Verify before you trust a single number

The most expensive tracking mistake is believing data you never tested. Before any custom event feeds a report, a dashboard or an ad campaign, prove it works. Open GA4’s DebugView, trigger the action yourself, and watch the event land with its parameters attached. Fire it a few times and confirm it counts once per action, not three times from a trigger that’s too loose. Check it on mobile, not just your desktop.

This matters even more once that data flows downstream. A double-counted purchase event doesn’t just inflate GA4 — it corrupts your attribution and makes every channel look more profitable than it is. Clean events at the source are what let you tag campaigns with UTM parameters and actually trust which source drove the conversion. Garbage events in, garbage decisions out.

A sane setup sequence

If you’re starting fresh, do it in this order and you’ll avoid most of the rework. Write your tracking plan — the five to ten actions that matter. Confirm GA4 and GTM are installed cleanly. Build your events, recommended names first, custom where you must. Register the parameters you want in reports as custom dimensions. Test every event in DebugView until it fires exactly once with the right data. Then, and only then, mark the real outcomes as key events and connect them to Google Ads.

Done that way, GA4 stops being a confusing wall of defaults and becomes what it should be: a clean record of the actions that move your business. For the bigger picture of how events, reports and migration fit together, the GA4 hub ties it all together — and if you want to see this built end to end on real accounts, that’s exactly what we do on stage each spring.