Stop tracking everything: a sane GA4 event strategy

I recently audited a GA4 property that had 347 distinct events. Three hundred and forty-seven. The team had spent months implementing them. They had events for every button click, every scroll depth, every form field interaction, every tooltip hover, every accordion expand.

When I asked what decisions they’d made based on this data in the last quarter, the room went quiet. Nobody had looked at most of it. The reports were so cluttered that finding the signal in the noise took more effort than the data was worth. They’d built a surveillance system when what they needed was a dashboard.

The “track everything” approach feels safe. You tell yourself you might need the data later. But GA4 has hard limits, the noise drowns out the signal, and maintaining hundreds of events across every site update becomes a full-time job. I want to make a case for tracking less, and tracking it well.

GA4’s hard limits (and why they matter sooner than you think)

GA4 isn’t unlimited. It has constraints that punish over-tracking:

• 500 distinct event names per property. Sounds like a lot. But if you’re auto-generating event names (like click_header_nav_products_dropdown_item_3), you’ll burn through this fast. Once you hit the limit, new events are silently dropped.

• 25 event parameters per event. Each event can carry up to 25 key-value pairs. If you need more context than that, your event is doing too much.

• 50 custom dimensions and 50 custom metrics per property. This is the real bottleneck. Every custom parameter you want to use in GA4 reports needs to be registered as a custom dimension or metric. Fifty sounds generous until you realize that a single ecommerce setup can use 15-20 of them.

• 10 custom conversions (was limited, now expanded, but still worth being intentional about).

These limits mean you can’t track everything even if you want to. And hitting the 50 custom dimension limit mid-project is painful. You end up choosing between removing a dimension you’re already using in reports or not being able to add a new one you actually need.

The decision framework

Before tracking any event, I ask one question: will someone make a decision based on this data?

Not “could someone theoretically find this interesting.” Not “marketing might want this someday.” Will a specific person, in a specific role, look at this data and change what they’re doing because of it?

If the answer is no, don’t track it.

If the answer is “maybe,” write down the specific decision it would inform. If you can’t articulate the decision, you don’t need the event.

Here are some examples:

Event	Decision it informs	Track it?
Button click on “Add to Cart”	What products are people interested in but not buying?	Yes
Scroll depth on blog posts	Are people reading our content or bouncing at the intro?	Yes, but only at 25%, 50%, 75%, 100% thresholds
Click on footer link to Privacy Policy	Almost none. Who cares?	No
Form submission on lead gen form	What’s our conversion rate? Which channels drive leads?	Absolutely yes
Hover over tooltip	None. This is curiosity, not data.	No
Video play on product page	Does video engagement correlate with conversion?	Yes, if you’re testing video content
Click on every navigation menu item	Very little. Use the page_view data you already have.	No

The footer link example is one I see constantly. Someone decides to track every link on the page “for completeness.” Those events add noise to every report and never get looked at.

Event taxonomy: building a naming system that scales

Before you start implementing events, you need a naming convention. GA4 is case-sensitive. add_to_cart, Add_To_Cart, and addToCart are three different events. I’ve seen all three in the same property.

My recommended approach uses a simple, consistent structure:

[action]_[object]

Examples:

• submit_form
• play_video
• click_cta
• download_file
• share_article

Keep event names lowercase with underscores. This matches Google’s recommended event naming and prevents case-sensitivity issues.

Use parameters, not event names, for specificity. Don’t create click_cta_homepage_hero and click_cta_pricing_page_sidebar as separate events. Create one click_cta event with parameters that get pushed through the dataLayer:

dataLayer.push({
  event: "click_cta",
  cta_location: "homepage_hero",     // or "pricing_sidebar"
  cta_text: "Start Free Trial",
  cta_destination: "/signup"
});

This approach keeps your event count low while preserving the detail you need for analysis. You can filter and break down by parameters in reports and explorations.

Recommended events vs. custom events

GA4 has a set of “recommended events” that come with predefined parameter structures. These include things like login, sign_up, search, share, purchase, and about 40 others.

Use recommended events whenever they fit your use case. Here’s why:

1. GA4 can use them for automatic reporting and audience building
2. Google’s ML models use them for predictive metrics (purchase probability, churn probability)
3. They integrate with Google Ads conversion tracking without extra mapping

But don’t force a recommended event where it doesn’t fit. I’ve seen people use the search event for filtering product categories because “it’s kind of like a search.” It’s not. It confuses your reports and breaks the semantic meaning of the event.

Custom events are for anything that doesn’t map to a recommended event. Most business-specific interactions will be custom events, and that’s fine. Just follow your naming convention.

The minimum viable event plan

Here’s what I recommend as a starting point for three common business types. Start with these and add events only when you can articulate the decision they’ll inform.

Ecommerce

Required events:

• view_item_list (with item_list_name for category/search/recommendations)
• view_item
• add_to_cart
• begin_checkout
• purchase
• refund

Recommended additions:

• add_to_wishlist (if you have wishlist functionality)
• view_promotion and select_promotion (if you run on-site promotions)
• search (site search, with search_term parameter)

What you probably don’t need:

• select_item (unless you’re actively analyzing which list positions get clicks)
• remove_from_cart (rarely actionable)
• Individual click events on product page elements (images, tabs, size selectors)

That’s roughly 8-10 events. Not 200. For the full implementation details on setting up these ecommerce events correctly, see my GA4 ecommerce tracking guide.

SaaS

Required events:

• sign_up (with method parameter: google, email, sso)
• login (to track active usage)
• submit_form (for contact/demo request forms, with form_name parameter)
• Feature activation events specific to your product (keep these to 5-10 key features)

Recommended additions:

• upgrade or subscribe (custom event for plan changes)
• invite_user (tracks viral growth mechanics)
• search (if your product has search functionality)

What you probably don’t need:

• Click events on every UI element
• Navigation events (page_view already tells you where people go)
• Hover or focus events
• Individual field-level form interactions

That’s roughly 8-12 events for most SaaS products.

Lead generation

Required events:

• submit_form (with form_name, form_location parameters)
• click_cta (with cta_text, cta_location, cta_destination parameters)
• generate_lead (recommended event, fire when a qualified submission happens)

Recommended additions:

• download_file (for gated content like whitepapers, case studies)
• play_video (if video is part of your conversion strategy)
• search (site search)
• scroll (GA4 enhanced measurement handles this automatically at 90% depth; customize thresholds only if content engagement is a core KPI)

What you probably don’t need:

• Click events on non-CTA links
• Accordion or tab interactions
• Social media icon clicks (these are outbound, you can’t track what happens after)
• Chat widget open/close events (your chat tool has its own analytics)

That’s roughly 5-8 events. For a lead gen site, that’s all you need.

Parameters: where the real value lives

A lean event strategy doesn’t mean less data. It means the same (or more) data, organized more efficiently.

Here’s how I structure parameters for maximum flexibility:

Content context parameters (applied across multiple events):

• content_type: “blog_post”, “case_study”, “product_page”
• content_category: The topic or category of the content
• content_id: A unique identifier for the specific piece of content

Interaction context parameters:

• element_location: “header”, “sidebar”, “footer”, “inline”
• element_text: The text of the button/link clicked

User context parameters:

• user_type: “free”, “trial”, “paid” (set as a user property, not an event parameter)
• user_industry: Segment if relevant to your business

By reusing parameters across events, you get consistent dimensions for analysis without burning through your 50 custom dimension slots.

What to do with the events you already have

If you’ve inherited a property with 200+ events, don’t panic. And don’t delete everything at once.

Step 1: Export your event list from GA4 (Admin > Events). Sort by event count over the last 90 days.

Step 2: For each event, answer two questions. Has anyone looked at this data in the last 90 days? And can you name a specific decision this data informed?

Step 3: Categorize events into three buckets:

• Keep: Actively used in reports, dashboards, or decision-making
• Archive: Not currently used but might be needed (stop collecting but keep historical data)
• Remove: Never been useful, never will be

Step 4: For the “Remove” bucket, simply remove the GTM triggers that fire those events. Don’t delete the events from GA4 itself. They’ll age out of the interface after a few months of inactivity.

Step 5: For the “Keep” bucket, audit the parameters. Are they all registered as custom dimensions? Are any of them redundant? Can you consolidate?

This cleanup usually reduces event count by 60-70%. The remaining events become much easier to maintain and analyze.

Naming conventions that prevent chaos

I want to spend a bit more time on naming because bad naming is what turns a manageable event plan into a mess over time.

Rule 1: Use snake_case, always. submit_form, not submitForm or Submit_Form. GA4’s own events use snake_case. Match the convention.

Rule 2: Start with the verb. play_video, not video_play. submit_form, not form_submit. This groups related actions together in alphabetical lists.

Rule 3: Don’t encode context in the event name. click_cta with a cta_location parameter of “pricing_page” is better than click_pricing_page_cta. The first approach keeps your event count low. The second creates a new event for every page.

Rule 4: Document your events. Maintain a spreadsheet or document that lists every event, its parameters, when it was added, why it was added, and who requested it. When someone asks “why are we tracking this?” you should have an answer. I share my full measurement plan template in a separate guide.

Rule 5: Review quarterly. Every three months, look at your event list and ask: are we using all of these? Has anything changed in the business that means we need new events or can drop old ones? Event plans should evolve with your business, not fossilize.

The hard truth about data hoarding

There’s a psychological comfort in tracking everything. It feels like insurance. What if we need that data later? What if someone asks a question we can’t answer because we didn’t track it?

In my experience, that scenario almost never plays out. When someone asks a question about an obscure interaction from six months ago, the answer is usually “we didn’t track that specific thing, but we can infer it from the data we do have.” And if you really can’t answer it, you add the event going forward. You lose a few weeks of data, not months.

The cost of tracking everything is real and ongoing: more complex GTM containers, more QA time on every site update, more noise in reports, faster approach toward GA4’s hard limits, and higher chance of tracking bugs going unnoticed because there’s too much to monitor.

Track what matters. Ignore the rest. Your future self will thank you for the clean data.