What counts as an event
An event is any single, nameable action you decide is worth a row in your data: a click on a specific button, a video reaching 75 percent watched, a file downloaded, a form submitted, an item added to a cart. Each one fires with a name and, usually, a handful of parameters attached, which page it happened on, which button, how far the video got. That structure is the entire point. A page view tells you someone arrived. An event tells you what they actually did once they got there.
Naming discipline matters more than people expect once a site has more than a handful of events. If one part of a site fires Button Click and another fires button_clicked for the functionally identical action, they show up as two separate rows in every report, and nobody remembers to add them back together six months later. The fix is boring and it works: pick one naming convention, snake_case or Title Case, decide it once, and write it down somewhere the whole team can see before anyone starts adding tags.
Event tracking vs page view, the actual distinction
This trips people up because in GA4 specifically, a page view is itself implemented as an event. There is no separate page view data type sitting outside the event system, page_view is just one event name among many that GA4 fires automatically. So the honest answer to event tracking vs page view is that page views are a subset of events, not a competing category. What people usually mean when they ask this is narrower: do you only know someone landed on a page, or do you also know what they did while they were there. That second question is what custom event tracking answers and a bare pageview count cannot.
| Page view | Custom event | |
|---|---|---|
| Fires on | Every page load | A specific action you define (click, submit, watch) |
| Tells you | Someone arrived at a URL | What they did once they arrived |
| Setup needed | None, works by default | Usually a code snippet or tag configuration |
| In GA4's model | Technically an event named page_view | A separate named event alongside it |
GA4 event tracking, what's automatic and what isn't
Most explanations skip this part, and it's the part that actually changes what you do next. GA4 ships with enhanced measurement turned on by default for new data streams, and it auto-captures a specific, limited list of events without you writing any code: page views, scrolls past 90 percent of a page, outbound link clicks, site search, video engagement on embedded YouTube players, and file downloads for common file types. Everything outside that list, an add to cart click, a signup form completion, a pricing tier selected, needs a custom event, which usually means either a tag in Google Tag Manager or a gtag('event', ...) call in your site's code. Checking which of your important actions already fall inside enhanced measurement, in Admin, Data Streams, your stream, Enhanced measurement, before building anything by hand saves a genuinely common wasted afternoon.
| Event source | Examples | Setup required |
|---|---|---|
| Enhanced measurement (automatic) | Page views, 90% scrolls, outbound clicks, file downloads | None, on by default |
| Recommended events | sign_up, login, purchase, search | You trigger them, GA4 predefines the name and parameters |
| Custom events | Anything specific to your product | You define the name and every parameter |
Why event tracking matters more than page views for most decisions
A page view answers a traffic question, how many people showed up. An event answers a behavior question, what they did once they got there, and behavior is what most teams are actually trying to change. Knowing how many people viewed a pricing page is close to useless next to knowing how many of those visitors clicked start free trial, because the second number is the one actually connected to revenue. Event tracking is also what makes conversion tracking possible in the first place, a conversion is just an event that has been marked as a goal. If that goal event has not been set up, the platform has no way to report it, no matter how much traffic data it is collecting in the background.
Where event tracking stops being useful on its own
Events tell you what happened on the page they are installed on. They do not tell you which post, ad, or bio link sent the person there in the first place, that is a separate layer, usually built from UTM parameters and referrer data captured at the click, before the visitor ever reaches the page with the event tag on it. The two need to be read together: campaign tracking data tells you where someone came from, event data tells you what they did once they landed. Raydar covers the first half specifically. It logs which link, in which bio page, produced the click that led to that pageview, a piece GA4's event data has no way to see once a visitor has already crossed from a platform like Instagram onto your site. For a fuller picture of how the two data sets connect, see link in bio analytics and what is click tracking.
Setting one up without overbuilding it
Most sites need far fewer custom events than teams initially plan. Start with the two or three actions directly tied to a business outcome, a demo request, a checkout, a signup, confirm they are not already covered by enhanced measurement, and add the rest only when a specific question comes up that the data cannot answer. Event trackers that log everything clickable tend to produce reports nobody reads, which is a worse outcome than tracking three things well.