GA4 (Google Analytics): Events Explained for Beginners

Google Analytics 4 tracks everything as an “event”: a page view, a scroll, a click, a form submission. That replaces the older idea of a “session” made up of separate page-view hits. This single structural difference explains most of what looks confusing to someone used to the previous tool, or to no analytics tool at all.

What GA4 actually is, and how its data model replaced Universal Analytics

GA4 is Google’s current analytics platform. It replaced Universal Analytics, which stopped processing new data in mid-2023. Every interaction in GA4 is recorded as an event — arriving at a page, scrolling, clicking a link, submitting a form. Each event carries parameters describing the detail: which page, how far scrolled, which link was clicked. This is different from the older model. That model recorded a session as a sequence of page-view “hits”, and treated events as a separate, secondary category. The practical effect is that a report in GA4 is really just a different filtered view of the same underlying event stream, rather than a fundamentally different data source. Every event sent to GA4, and every report built from it, is drawing on that same single stream of data.

What GA4 tracks automatically, out of the box

GA4’s “enhanced measurement” turns a set of common events on by default once the tracking code is installed correctly:

Automatic event	What it captures
page_view	Every page load
scroll	Reaching roughly the bottom of a page
click (outbound)	A click on a link to a different domain
site_search	Use of an on-site search box, if the URL parameter is recognised
video_engagement	Play, pause and completion of embedded video
file_download	A click on a link to a common file type (PDF, DOCX, etc.)

Form submissions and phone-call clicks are not captured automatically in the same way and need to be set up as conversion events — covered on conversion tracking and goals in GA4.

Data retention is not indefinite by default

GA4’s event-level data has a configurable retention period in Admin settings, with options up to 14 months for most properties. This governs how far back certain detailed exploration reports can look. Aggregated standard reports are generally retained longer. The detailed event-level data used in ad-hoc “Explore” analysis is subject to this setting. It is worth checking this setting is configured to the longest available period, rather than left on a shorter default. A lost year-on-year comparison cannot be recovered retroactively.

The five places most of the answers live

• Reports → Acquisition — where visitors came from
• Reports → Engagement — what pages they looked at and how they moved through the site
• Reports → Monetisation — for ecommerce sites specifically, revenue and product performance
• Explore — build-your-own reports for questions the standard reports do not answer directly
• Admin → Events — where automatically captured events are reviewed, and where a specific event is marked as a conversion

What “Real-time” and “DebugView” are for

The Real-time report shows activity from roughly the last 30 minutes. It is mainly useful for confirming tracking is actually firing after a change, not for ongoing monitoring. DebugView is available when a device is put into debug mode. It shows individual events as they fire, and is the practical way to confirm a specific new tracked action — a form submission, a click — is actually being recorded correctly, before you trust the report built on top of it.

Properties, data streams and where the confusion starts

GA4’s structure has two layers that are easy to conflate the first time they are seen. A property is the container for a business’s analytics configuration: its own settings, its own conversion events, its own retention period. A data stream is a specific source of data feeding into that property, typically a website, and separately an iOS app or an Android app if the business has one. One property can hold several data streams. That is how GA4 lets a business see a combined view of its website and its app in the same reports if it has both, or keep a single website as the only stream if that is all there is. For a small business with just a website, the practical consequence is simple: one property, one data stream. Most of the two-layer structure never has to be thought about again, once it is confirmed correctly set up. But if a report ever looks like it is missing data, checking whether the right data stream is selected is a genuinely common first diagnostic step.

Why some numbers show as “(not set)” or get grouped into “Other”

Two specific gaps show up often enough in GA4 reports that they are worth recognising, rather than treating as a fault. “(not set)” appears where GA4 expected a value for a dimension — a page title, a source, a location — and did not receive one. That commonly happens because a page was missing the relevant tag, or a visit came through a path GA4 could not fully categorise. An “(Other)” row, separately, appears where GA4 has applied data thresholding. That is a privacy safeguard that suppresses a breakdown when a specific combination of dimensions would otherwise describe a very small number of people precisely enough to risk re-identifying them. Thresholding shows up more on a low-traffic small-business site than a high-traffic one, because a small monthly total split finely by device, location and source can quickly reach a count small enough to trigger it. Neither pattern indicates broken tracking on its own. Both are worth checking the first time they appear. But an occasional “(not set)” row or thresholded breakdown is a normal feature of the tool, not a sign the whole report is unreliable.

Google Signals and why this site’s own build does not use it

GA4 offers an optional feature called Google Signals. It uses data from users signed into their Google account, with ads personalisation enabled, to add cross-device reporting and remarketing capability. Turning it on requires updating a site’s own consent and privacy disclosures to reflect the additional data use. It also reintroduces exactly the kind of persistent, cross-session identification that a cookieless measurement approach is built to avoid — covered on measurement without a cookie banner. A small business deciding whether to enable it should weigh the reporting benefit against the added disclosure obligation, rather than turning it on by default because it is offered.

Standard reports vs Explore

The pre-built reports under “Reports” in the left-hand navigation — Acquisition, Engagement and the rest — answer the most common questions in a fixed, pre-formatted layout. This is where most of the day-to-day checking in this cluster happens. “Explore” is a separate section of the interface. It lets a specific, non-standard question be built from scratch: a funnel showing where visitors drop off across a specific multi-step process, for instance, or a breakdown that combines two dimensions the standard reports do not pair together. Explore is genuinely more powerful, but has a steeper first-use curve. The practical approach for a non-analyst is to rely on the standard reports for routine monthly checking, per reading a traffic report without fooling yourself. Reach for Explore only when a specific question the standard reports cannot answer actually comes up.

Google Tag Manager, GTM and how a custom event actually gets configured

Google Tag Manager, usually shortened to GTM, is a separate Google tool that sits between a site and Google Analytics. Instead of editing a site’s code directly every time a new event needs tracking, a tag is configured once inside the GTM interface and published, without a developer touching the page again for the next change. A typical setup uses GTM to fire a custom event — a form submission, a phone-number click, a specific button, or a thank-you page load after a form submits — with parameters attached describing which form or which link. Registering that event inside GA4 is what then lets it be marked as a key event, GA4’s current name for what earlier documentation still calls a “conversion.” Custom dimensions extend this further. They let a business track a value GA4 does not capture by default — a service category selected in a form, for instance — attached to the event as its own named parameter. Every tag configured in GTM controls exactly what gets sent to GA4, and nothing else.

Naming events and parameters so a report is still readable in six months

An event needs a clear, consistent name — form_submit, not Form Submission #2 typed differently each time it is configured. GA4 treats every distinct spelling and capitalisation as a separate event, silently splitting one action’s data across several rows in a report. The same applies to parameter names attached to an event, and to the “item” parameters used on ecommerce sites for individual products. Run a DebugView check: watch a newly configured event fire in real time exactly once, with the parameters expected and no unexpected duplicates. That is the practical way to confirm how tracked events actually behave, before trusting a week of live event data built on top of it.

Before you configure anything: the one Google Analytics habit worth building

Before you configure a single new tag, name every event and every key event the same way a colleague reading the Google Analytics interface cold would expect. Do not name it the way that made sense while half-remembering GTM’s own menu structure at 4pm on a Friday. A business that treats event, tag and parameter naming as a one-off task, rather than a small standing discipline, is the business re-explaining its own GA4 setup from scratch a year later.

What to do next

If GA4 has never really been configured beyond the basic install, setting up GA4: the first week checklist is the practical next step. Marking form submissions and calls as conversions is covered on conversion tracking and goals in GA4. If this kind of setup is being scoped as part of a new build, web development services covers where analytics configuration typically sits in a project.