A custom event is an action you name and define yourself in Google Analytics 4 because none of GA4’s automatic, enhanced measurement or recommended events describes it. Typical examples are a completed quote calculator, a brochure download for a particular course or a click on a “book a survey” button.
How a custom event works
GA4 records everything as an event, and events come in four groups. Some arrive with no setup at all, such as page views and first visits. Enhanced measurement events add scrolls, outbound clicks, site search and file downloads when you switch them on in the data stream settings. Recommended events are names Google has already defined, such as generate_lead, sign_up and purchase, each with the parameters it expects.
A custom event fills the gap those three leave. You choose the name, decide when it fires and attach whichever event parameters make it useful. There are three common ways to send one:
- a GA4 event tag in Google Tag Manager, fired by a trigger such as a click or a data layer message;
- a line of gtag.js code added by a developer at the point the action completes;
- the “Create event” option in GA4’s admin, which builds a new event from an existing one when conditions match, for example a page view of a particular thank-you URL.
At the time of writing (October 2026), event names are case-sensitive, can be up to 40 characters long, must start with a letter and may contain only letters, numbers and underscores. Names beginning with “ga_”, “google_” or “firebase_” are reserved for Google’s own use.
Why it matters
The actions that make a UK small business money rarely match Google’s defaults. A London kitchen fitter might treat a completed room-size calculator as the strongest sign of intent on the whole site. A training provider might care most about prospectus downloads for one specific course. Neither shows up in GA4 until someone defines it.
Once the event exists, you can mark it as a key event, import it into Google Ads as a conversion and build remarketing audiences from the people who triggered it. That is the difference between reporting on traffic and reporting on the actions that lead to sales, which is why defining the right events is one of the first jobs in any performance marketing engagement I take on.
Common mistakes
- Inventing a name when a recommended one exists. If the action is a lead, use generate_lead rather than “enquiry_sent”. Recommended names feed GA4’s built-in reports and features that custom names do not.
- Inconsistent naming. “Form_Submit”, “form_submit” and “formSubmit” are three separate events in GA4. Pick one convention, usually lower case with underscores, and stick to it.
- Firing on the click instead of the outcome. An event on the submit button also counts failed and empty submissions. Fire it when the success message appears or the server confirms the form went through.
- One event per variation. Separate events for “quote_kitchen”, “quote_bathroom” and “quote_loft” clutter reports. One event called quote_request with a parameter for the room type is easier to read and compare, and that parameter can be registered as a custom dimension.
- No testing. An event that looks right in Tag Manager can still fail to reach GA4. Check each one in DebugView before relying on it.
How to act on it
List the five to ten actions on your site that signal real interest, then cross out any already covered by automatic, enhanced measurement or recommended events. What remains are your custom events. For each one, write down the name, the exact moment it should fire, the parameters it carries and whether it will become a key event.
Build them in Google Tag Manager where you can, so later changes do not need a developer each time. Test in preview mode and DebugView, publish, and check the Events report after a day or two. If any parameter needs to appear in standard reports, register it in GA4 at the same time as the event goes live.