How a custom event works
Analytics platforms collect a standard set of actions without being asked — a page loading, a file downloading, an outbound link being clicked. A custom event is one you define instead: you choose the name, you choose the parameters that travel with it, and you choose what has to happen on the page before it fires. Typical examples are a quote form submitted, a WhatsApp button tapped, a price list opened, or a video finished.
It reaches the platform the same way every other event does — through the site tag, through Google Tag Manager, or from your own server. Once it arrives it is treated no differently from a built-in event. The only thing that makes it custom is that you invented it. GA4 also publishes a list of recommended event names with expected parameters; if your action matches one of those, use the published name so the built-in reports recognise it rather than inventing your own.
Why custom events matter
Without them, analytics describes traffic rather than the business. Page views tell you where somebody went. A custom event tells you what they did when they arrived, which is the part a proposal, a budget decision or a bid strategy actually needs. On sites serving Nepal that gap is wide, because a large share of enquiries arrive as a phone tap or a WhatsApp message rather than a form submission, and none of that is collected by default.
Custom events are also the raw material for everything downstream. Audiences, key events and the conversions you send back to ad platforms are all built from events that already exist. If the action was never captured, no amount of reporting work will recover it later — the data simply is not there for the days before the tag went live.
Where custom events go wrong
The commonest failure is a name that only made sense on the afternoon it was created. Names like btn_click or event_two are unreadable a quarter later, and nobody can tell which button they refer to. Agree a naming pattern in lower case with underscores, write it down, and apply it to every property you own.
The second failure is packing detail into the name instead of into parameters. A separate event for every form on every page produces a long list of names that cannot be totalled or compared. One event with a parameter carrying the form name gives the same detail and still adds up. The third is quieter: a parameter that is never registered as a custom dimension is collected but never appears in standard reports, so people assume the tracking failed.
How to act on it
Start from the business, not the tag manager. Write down the actions that indicate someone is close to buying, decide which of them are worth counting, and only then build tags for those. Fire each one in a preview or debug view before publishing, and check both that it appears once and that its parameters carry the values you expect.
Then finish the job. Register the parameters you want to report on, mark the events that represent real outcomes as key events, and record what each event means in a short document a colleague could read. A tidy, documented GA4 and tag manager setup is what makes the rest of your reporting trustworthy.