GA4 Custom Events: What to Track and How to Name Them

How GA4 events actually work

GA4 is event-based, which means everything that happens on your site is recorded as an event. A page view is an event. A scroll is an event. A form submission is an event. Unlike Universal Analytics, which had a separate concept of "hits" (pageview, event, transaction, social), GA4 treats everything as events with parameters.

GA4 collects some events automatically without any configuration: page_view, session_start, first_visit, scroll (fires at 90% page depth), click (for outbound links), file_download, and a few others. These auto-collected events are useful but rarely sufficient for a real measurement strategy.

Beyond auto-collected events, GA4 has "recommended events" — events Google suggests you implement in specific ways, with specific parameter names, because they unlock features like e-commerce reporting. And then there are custom events: anything you define yourself for your specific measurement needs.

Event naming conventions

GA4 event names use snake_case (lowercase with underscores): form_submit, content_download, demo_request. There are a few rules worth knowing:

• Event names are case-sensitive. Form_Submit and form_submit are different events in GA4.
• Names can't start with numbers or contain spaces or special characters (aside from underscores).
• Names are limited to 40 characters.
• You can't delete events from GA4 after they've been collected — you can only archive them. Bad names persist.

The most important rule isn't technical: name events so a stranger can understand what happened without any context. cta_click is not a good event name. nav_cta_click is better. contact_form_submit is better still.

Event parameters: the "what" that makes events useful

An event by itself tells you something happened. Event parameters tell you what specifically happened. A form_submit event without parameters tells you someone submitted a form. With parameters, it tells you which form, on which page, after how many sessions, with what referral source.

Parameters are key-value pairs attached to events. GA4 has some built-in parameters (like page_location and page_title, which are automatically included in most events), and you can define custom parameters for anything specific to your business.

For a contact form submission, useful custom parameters might include: form_name (contact, demo, download), form_id (if you have multiple forms on the site), and lead_source (if you're passing CRM attribution data through the form).

Important: custom parameters need to be registered in GA4 (Admin → Custom definitions → Create custom dimensions) before they appear in reports. Unregistered parameters are collected but not accessible in the standard reporting interface.

What to actually track on a B2B site

For a typical B2B marketing site, the event taxonomy I recommend usually covers three tiers:

Tier 1 — Conversion events (key events): Form submissions (contact, demo, download), direct contact actions (phone click, email click), calendar booking clicks. These become your GA4 key events and should be the primary metrics in any report.

Tier 2 — Engagement events: Scroll milestones on long-form content (50%, 75%, 100%), time on page milestones, video play and completion, PDF opens, outbound link clicks to partner or investor sites.

Tier 3 — Navigation events: Internal search queries, tab or filter interactions on product or pricing pages, accordion expansions on FAQ pages. These tell you about intent and confusion patterns.

Most B2B sites don't need more than 15–20 custom events total. More than that and you start measuring noise.

The event schema document

Before implementing anything, write your event schema. A simple spreadsheet works: event name, event category, what triggers it, what parameters it carries, whether it's a key event, and where it's implemented (GTM tag name). This document is your contract with your analytics implementation.

Without this document, your GA4 property becomes a mystery box inside six months. I've audited properties where no one on the current team knew what half the events were or whether they were still firing correctly.

The document also serves as the brief for whoever implements the tracking — whether that's your developer pushing data layer events, or you building triggers in GTM. Ambiguous briefs produce ambiguous data.

Testing before you trust

Every new event should be verified in GA4's DebugView before you start using it in reports. Check that the event fires at the right time, carries the right parameters, and doesn't fire more than once per intended action. Double-firing is a common issue with form submit tracking — the event fires once on submission and once on page navigation, leading to inflated conversion numbers.

Also check GA4's Realtime report after publishing. If an event should fire every time a certain page loads, visit that page a few times and verify you see the events appearing with a one-to-two minute delay.