How an event works
GA4 has one shape of data. A page view is an event. A click is an event. A purchase is an event. Each one is a name saying what happened, plus a set of parameters carrying the detail — which page, which button, what it was worth. Nothing else is collected, and everything you see in a report is built by counting and grouping those events afterwards.
That includes things which feel more solid than events. A session is not stored anywhere; it is worked out from a session identifier that travels with the events. A user is worked out the same way. When people say GA4 is harder to reason about than the analytics they had before, this is usually why: the old model recorded page views and treated everything else as an extra, and this one records actions and derives the rest.
Why events matter
Because they are the only lever you have. If an action is not sent as an event, no report, audience, funnel or advertising import can ever recover it — the data was never there. Deciding which actions matter is therefore a business decision made before any code is written, not a technical detail to be handed to a developer.
Events are also the currency shared with advertising platforms. Marking one as a key event is what makes it available for import into Google Ads, and the quality of that single decision shapes what automated bidding learns to chase. Choose an action that is easy to trigger and cheap to fake, and the bidding will faithfully buy more of it.
Common mistakes with events
The most common is bringing the old category, action and label habit into event names, producing a long list of near-identical names that no report can group. The pattern that works is a small set of stable names with the varying detail moved into event parameters: one form_submit event with a parameter for which form, rather than a separate event name for every form on the site.
The second is marking too many events as key events. If almost everything counts, nothing does, and reports fill with a conversion count that no longer means a sale or an enquiry. The third is tagging first and thinking later, which leaves a property full of events nobody can explain and nobody dares delete.
How to act on it
Write the list of actions that matter to the business on paper first, in plain language, then give each one a name and the parameters it needs. Keep the list short enough that you could read it aloud in a meeting. Only then open Tag Manager.
Once events are live, check them in DebugView before trusting a report, because a name that arrives slightly wrong looks perfectly healthy until you try to use it. If you want the tagging plan and the reporting to be built as one piece of work rather than two, that is what an analytics and tracking setup covers.