A Practical Guide to Custom Events in Google Analytics 4

GA4's automatic and Enhanced Measurement events cover a lot of ground, but sooner or later almost every site needs to track something specific to its own business — a demo request, a pricing tier selected, a specific feature used. That's what custom events are for. Getting them right isn't complicated, but there are a handful of structural conventions that make the difference between an event that's genuinely useful in reports and one that's technically "tracked" but awkward to actually analyze.

Naming Your Events Correctly

GA4 event names must:

• Be 40 characters or fewer
• Start with a letter, not a number or underscore
• Use only letters, numbers, and underscores (no spaces or special characters)
• Be case-sensitive (Signup and signup are treated as different events)

Google also reserves certain event names for its own automatically collected and recommended events (like purchase, login, search) — using these names for something unrelated to their intended meaning will confuse standard reports that assume specific parameters. Stick to snake_case, and pick names that describe the action, not the button: newsletter_signup rather than blue_button_click.

Designing Useful Parameters

Every event can carry up to 25 custom parameters (with some reserved for Google's own use). The parameters are where most of the analytical value actually lives — the event name tells you what happened, but the parameters tell you the context:

gtag("event", "demo_requested", {
  plan_interest: "enterprise",
  company_size: "51-200",
  lead_source: "pricing_page",
});

A few design principles that make parameters more useful later:

• Use consistent values across events. If lead_source can be "pricing_page" in one event, don't call it "pricing" in another — inconsistent values fragment your reporting.
• Avoid high-cardinality parameters (like a raw free-text search string or a unique order ID) as dimensions you plan to report on broadly — they don't aggregate usefully and can hit reporting limits on distinct values.
• Keep parameter names short and descriptive — you have a 40-character limit per parameter name as well.

Firing a Custom Event

The basic pattern with gtag.js:

gtag("event", "video_shared", {
  video_id: "intro-tour",
  share_platform: "linkedin",
});

Or via the dataLayer if you're using Google Tag Manager:

window.dataLayer.push({
  event: "video_shared",
  video_id: "intro-tour",
  share_platform: "linkedin",
});

In GTM, you'd then create a Custom Event trigger listening for video_shared, and a GA4 Event tag mapping the relevant dataLayer fields to event parameters.

Registering Custom Dimensions

Sending a parameter isn't enough on its own to use it as a report dimension or filter — GA4 needs it explicitly registered:

1. Go to Admin → Custom definitions → Create custom dimensions.
2. Give it a display name (e.g., "Plan Interest").
3. Set the scope — almost always Event scope for parameters attached to a specific event.
4. Map it to the parameter name exactly as sent (plan_interest).
5. Save.

Registration only affects data going forward — parameters sent before registering the dimension are stored in the raw event data but won't populate the dimension retroactively in standard reports built after the fact.

A Practical Example: Tracking a Multi-Step Signup Flow

Imagine a product signup flow with several steps. Rather than one vague signup event, model each step distinctly so you can build a funnel later:

gtag("event", "signup_step", {
  step_name: "account_details",
  step_number: 1,
});

gtag("event", "signup_step", {
  step_name: "plan_selection",
  step_number: 2,
});

gtag("event", "signup_step", {
  step_name: "payment_info",
  step_number: 3,
});

gtag("event", "signup_completed", {
  plan_selected: "pro",
});

Using one consistent event name (signup_step) with a step_name/step_number parameter, rather than a separate uniquely-named event per step, keeps your Events report from becoming cluttered with dozens of near-identical entries, while still giving you everything needed to build a step-by-step funnel exploration.

Verifying Custom Events

Always confirm a new custom event fires correctly before building anything on top of it:

1. Open Admin → DebugView.
2. Trigger the action on your site (with debug mode enabled via the GA4 debugger extension, or debug_mode: true passed with the event).
3. Confirm the event appears with the exact name and parameter values you expect.

It's worth checking parameter values, not just that the event fired — a common bug is sending the right event with an empty or undefined parameter value because the underlying data (like a selected plan name) wasn't available yet at the point the event fired.

Common Mistakes

• Firing events too early, before the data needed for parameters actually exists (e.g., firing a purchase event before the order confirmation is returned by the backend).
• Inconsistent event naming across a team, where different developers invent slightly different names for what's conceptually the same action (signup_complete vs. signup_completed vs. user_signed_up) — agree on a naming convention document before implementation spreads across a codebase.
• Overloading a single event with too many purposes, making later filtering awkward. If two use cases are conceptually different actions, give them different event names rather than trying to distinguish them purely through parameters.
• Not registering the custom dimension, then wondering why a parameter you're clearly sending doesn't show up as a usable report dimension.

FAQ about Custom Events in Google Analytics 4

How many custom events can I create in GA4?

There's no strict limit on distinct custom event names, but GA4 properties are limited to 50 registered custom dimensions and metrics (25 event-scoped custom dimensions plus additional user-scoped ones, depending on your GA4 tier), so it's worth being deliberate about which parameters you actually register for reporting.

Can I rename a custom event after it's been implemented?

Not directly — GA4 doesn't support renaming an event after data has been collected under it. You'd need to start sending a new event name going forward and treat the old one as historical data under its original name.

Do custom events automatically become conversions?

No — you have to explicitly mark them as conversions under Admin → Events, the same as any other event.

What's the difference between a custom event and a recommended event?

Recommended events are event names and parameter structures Google predefines for common use cases (like purchase or login), which come with dedicated standard reporting. Fully custom events use names and parameters you define yourself, with no dedicated built-in report beyond the general Events report.

Should I use recommended events instead of inventing my own where possible?

Generally yes, when your use case matches a recommended event's intended meaning — it gets you built-in reporting support. Only build a fully custom event when no recommended event fits your specific action.

How do I test custom events before deploying to production?

Use DebugView in a staging environment or with debug mode enabled in production temporarily, and verify both the event name and every parameter value before rolling out broadly.

Conclusion

Custom events are where Google Analytics 4 becomes specific to your actual business, rather than generic web analytics. Name them consistently, design parameters that aggregate well, register the dimensions you need, and verify everything in DebugView before trusting the data — that discipline is what turns custom tracking into something your team can actually build reports and decisions on for your website.