The GA4 Events Every Site Should Track (and the Ones Most Skip)

GA4 tracking setups come in two flavors: skeletal (page views and not much else) and bloated (hundreds of events tracking every conceivable interaction). Both fail for the same underlying reason — neither maps to the actual questions the business needs answered. The right taxonomy is smaller than most teams think, with a specific set of parameters that make reporting trivially easy instead of a weekly archaeology project.

This is the GA4 event schema we deploy on every client engagement. It covers roughly 95% of reporting needs, stays maintainable as the site evolves, and works with the kind of attribution reality GA4 actually has in a post-third-party-cookie world.

The core eight events every site needs

Start with these eight events, in this order of importance: page_view (already built into GA4, but ensure pathname is clean), click_cta (any click on a primary call-to-action button), form_submit (lead form, contact form, signup form), scroll_depth_75 (did the user get 75% down the page — a proxy for real engagement), video_play (if you have video content), file_download (PDFs, case studies, whitepapers), signup (account created), and purchase (transaction complete).

These eight cover the canonical marketing questions: are people arriving, engaging, converting, and buying? Every dashboard or report a marketing team actually needs can be built from these eight events plus consistent parameters. Ship them first, measure for 30 days, then add custom events only when you can articulate the specific decision they'll inform.

The three parameters that make reporting easy

Every event should carry three parameters: page_type (home, product, blog, category, checkout, etc.), section (which part of the page the interaction happened in — hero, pricing_table, faq), and item_name (the specific thing interacted with — 'pricing_cta', 'demo_video_intro'). These three parameters together let you answer almost any drill-down question without rebuilding the tracking.

Teams that skip parameters end up in a situation where they can see 'CTA clicks' in aggregate but can't tell which CTA on which page was clicked. That's useless for decision-making. By the time they realize, they've lost three months of parameter-less data that can't be retroactively enriched. Ship parameters on day one.

Naming conventions that prevent future pain

Use snake_case for event names, never camelCase or Title Case. GA4's reporting UI handles snake_case better, and inconsistent casing is the number-one source of broken dashboards 6 months into a tracking implementation.

Use verb_noun structure, past tense where it reads naturally: form_submitted, not 'Form Submit' or 'submitFormButton'. Make it obvious what the user did, not what the code did. Consistency across events means cross-event reports (funnels, paths) work out of the box.

Document the taxonomy somewhere non-GA4 — a Notion page or a README in the repo that ships tracking. When a new developer or marketer joins, they should be able to find the full event dictionary in one place. The cost of documenting is ten minutes; the cost of not documenting is measured in quarters of confused reporting.

What not to track — and why less is more

Don't track every mouse movement, every click on every link, every scroll event, or every form field focus. GA4's free tier caps events per month, and even if you're on the paid tier, data you don't use is data that makes reports slower and more confusing. Track what maps to decisions, nothing more.

Specifically: don't track outbound clicks to every external link unless you're debugging a specific partnership. Don't track scroll depth at every 10% increment — just 75% is enough signal for engagement. Don't track hover events unless you're doing specific UX research on a redesign. Don't track time on page as a custom event; GA4 engagement time is good enough.

The test we use: 'what decision would this event change?' If no one can answer it within 15 seconds, the event doesn't ship. This discipline keeps tracking sustainable and reports readable.

Key takeaways

• Eight core events cover 95% of needs: page_view, click_cta, form_submit, scroll_depth_75, video_play, file_download, signup, purchase.
• Three parameters on every event: page_type, section, item_name. Without these, drill-down reporting is impossible.
• snake_case, verb_noun, past tense. Document the taxonomy in a non-GA4 location so future team members can find it.
• If you can't articulate the decision an event would change, don't track it. Noise in tracking is the biggest source of future reporting pain.