Manually Collected Events in GA4: Audit and Optimization Guide

Written By Ali Izadi

The Case File: Understanding Event Collection Depth

Your GA4 property collects events in three distinct tiers. Automatically collected events track basic interactions like page views, session starts, and first visits without any configuration. Enhanced measurement events capture scrolls, outbound clicks, and video engagement when toggled on in your data stream settings. Then there are manually collected events—custom events you deliberately implement to track business-specific interactions.

The Watson Analytics Detective dashboard evaluates whether your implementation relies solely on automatic tracking or includes strategic custom event instrumentation. This check answers a fundamental question: Are you measuring what actually matters to your business, or just accepting Google's defaults?

A property with zero manually collected events signals missed opportunities. A property with hundreds of poorly planned custom events signals chaos. Both scenarios compromise data quality.

The Root Causes: Why Event Collection Varies

1. Implementation Maturity Gap

Many organizations migrate from Universal Analytics to GA4 and initially deploy only the base tracking code. The Google tag (gtag.js) or Google Tag Manager (GTM) container fires automatically collected events immediately, creating the illusion of complete tracking.

Teams often delay custom event implementation due to resource constraints, assuming enhanced measurement covers their needs. It doesn't. Enhanced measurement tracks generic interactions—90% scroll depth, outbound clicks—but cannot capture business logic like "filter applied," "calculator used," or "pricing tier selected."

2. Over-Implementation Without Governance

The opposite problem occurs when developers or analysts implement custom events without a tracking plan. Common patterns include:

  • Event sprawl: Creating separate events for minor variations (button_click_blue, button_click_red) instead of using event parameters

  • Duplicate tracking: Firing the same interaction through both gtag.js and GTM, or multiple GTM tags

  • High-cardinality event names: Using dynamic values in event names (product_123_viewed, product_456_viewed) instead of a single product_viewed event with an item_id parameter

According to Google's documentation, while there's no hard limit on distinctly named events for web data streams, best practices recommend avoiding more than 500 unique event names. App data streams have a stricter limit: 500 distinct events per user per day.

3. Confusion Between Event Types

GA4's event hierarchy confuses many implementers:

  • Automatically collected: page_view, session_start, first_visit, user_engagement

  • Enhanced measurement: scroll, click, view_search_results, video_start, file_download

  • Recommended events: Google's predefined event names with standardized parameters (e.g., purchase, login, sign_up, add_to_cart)

  • Custom events: Fully custom event names you create

The critical distinction: Recommended events are still manually collected. You must implement purchase or add_to_cart yourself—they don't fire automatically. Many teams assume these are built-in and discover months later they're not tracking eCommerce.

4. Technical Implementation Barriers

Custom events require one of three implementation methods:

Google Tag Manager (most common): Create a GA4 Event tag, configure event name and parameters, attach appropriate triggers. Requires GTM knowledge and access.

gtag.js (developer-dependent): Add gtag('event', 'event_name', {parameters}) calls in your codebase. Requires developer resources and deployment cycles.

Measurement Protocol (advanced): Send events server-side via HTTP POST requests. Used for offline conversions or server-side tracking but requires API knowledge.

Teams without GTM expertise or developer bandwidth default to automatic tracking only.

5. Data Layer Race Conditions

Even when custom events are implemented, timing issues cause tracking failures. If your GTM tag fires before the data layer populates with necessary variables (product IDs, user status, transaction values), the event fires with incomplete data—or doesn't fire at all.

This is especially common on single-page applications (SPAs) where page transitions don't trigger full page loads. The dataLayer.push() command and GTM trigger must synchronize perfectly.

The "So What?": Business Impact of Inadequate Custom Events

Insufficient Custom Events (Zero or Minimal)

Lost conversion intelligence: You're tracking pageviews but not form submissions, calculator interactions, or content downloads. Your funnel analysis shows drop-offs but not why.

Inability to measure engagement depth: Pageviews don't distinguish between a user who bounced immediately and one who spent 10 minutes interacting with your configurator tool.

Missed optimization opportunities: Without custom events, you cannot A/B test specific interactions, build audiences based on behavior, or attribute value to micro-conversions.

Reporting blind spots: Standard reports show traffic sources and page performance. Custom events power custom reports, Explorations, and BigQuery analysis that reveal true user intent.

Excessive or Poorly Structured Custom Events

Custom definition quota exhaustion: GA4 allows 50 event-scoped custom dimensions (125 for Analytics 360). Each unique event parameter you register as a dimension consumes this quota. Unplanned event sprawl burns through limits quickly.

Cardinality issues: High-cardinality dimensions (those with thousands of unique values) trigger the dreaded (other) row in reports, aggregating data into an unusable bucket. This happens when event names or parameters contain unique identifiers, timestamps, or user-specific data.

BigQuery export bloat: Every event fires a row in your BigQuery export. Redundant or overly granular events inflate storage costs and slow query performance.

Analysis paralysis: When your Events report lists 200+ event names with inconsistent naming conventions (ButtonClick, button_click, btn_click, click_button), analysts waste hours deciphering what each event actually measures.

Duplicate event inflation: If both your hardcoded gtag.js and GTM fire the same event, your event counts double. A 5% conversion rate becomes 10%, breaking all downstream reporting and optimization decisions.

The Investigation: How to Audit Your Custom Events

Without Watson, you'll need to manually inspect your GA4 property to assess custom event implementation.

Step 1: Review All Collected Events

Navigate to Admin > Data display > Events. This interface lists every event your property has received in the last 30 days, including event counts and whether each is marked as a key event.

Scan the list. Identify which events are:

  • Automatically collected (e.g., page_view, session_start)

  • Enhanced measurement (e.g., scroll, click, file_download)

  • Recommended events you've implemented (e.g., purchase, add_to_cart)

  • Fully custom events (e.g., calculator_used, filter_applied)

Count your custom events. If you see fewer than 5, you're likely under-tracking. If you see more than 100, investigate whether consolidation is possible.

Step 2: Analyze Event Naming Patterns

Look for inconsistencies:

  • Mixed case conventions (ButtonClick vs. button_click)

  • Redundant variations (form_submit, form_submission, formSubmit)

  • High-cardinality names containing IDs or timestamps

GA4 event names are case-sensitive. Button_Click and button_click are counted as separate events, fragmenting your data.

Step 3: Check Event Parameters in Explorations

Go to Explore and create a Free form exploration. Add Event name as a dimension and Event count as a metric. This shows which events fire most frequently.

Select a custom event and add event parameters as secondary dimensions. Verify that parameters contain expected values, not nulls or "undefined" strings.

Step 4: Use DebugView for Real-Time Validation

Enable debug mode by installing the Google Analytics Debugger Chrome extension or adding ?debug_mode=true to your URL parameters (for gtag.js implementations).

Navigate to Admin > DebugView. Interact with your site and watch events fire in real-time. Check:

  • Are custom events firing at all?

  • Do they fire multiple times per interaction (indicating duplicates)?

  • Are event parameters populated correctly?

  • Are events firing in the correct sequence?

Step 5: Review GTM Container (If Applicable)

If you use Google Tag Manager, log into your GTM container and navigate to Tags. Filter by tag type Google Analytics: GA4 Event.

For each custom event tag:

  • Verify the event name follows naming conventions (lowercase, underscores, starts with a letter)

  • Check that triggers are configured correctly (not firing on every page load unintentionally)

  • Confirm event parameters pull from appropriate variables, not hardcoded strings

  • Look for duplicate tags firing the same event

Step 6: Audit Custom Dimensions Usage

Navigate to Admin > Data display > Custom definitions. This shows which event parameters you've registered as custom dimensions.

Count your event-scoped custom dimensions. If you're approaching the 50-dimension limit (or 125 for Analytics 360), prioritize which parameters truly need dimension registration. Parameters can still be sent with events and accessed in BigQuery without formal registration—they just won't appear in standard reports.

The Solution: Optimizing Your Custom Event Strategy

For Properties with Insufficient Custom Events

1. Develop a measurement plan

Before implementing anything, document:

  • Business objectives (increase conversions, reduce churn, improve engagement)

  • Key user actions that indicate progress toward those objectives

  • Which actions are already tracked vs. which require custom events

Use a spreadsheet or specialized tools like Avo, Segment Protocols, or Google Sheets templates to maintain this documentation.

2. Prioritize recommended events

Consult Google's recommended events list before creating custom event names. If a recommended event fits your use case, use it. Examples:

  • eCommerce: view_item, add_to_cart, begin_checkout, purchase

  • Lead generation: generate_lead, sign_up, login

  • Engagement: search, select_content, share

Recommended events come with predefined parameters that integrate with GA4's built-in reports and Google Ads conversions.

3. Implement strategically

Start with high-impact events:

  • Form submissions (contact, newsletter, demo requests)

  • Button clicks on primary CTAs

  • Key content interactions (video plays, PDF downloads, tool usage)

  • Navigation events that indicate intent (opening pricing modals, viewing comparison tables)

Use Google Tag Manager for flexibility. Create a GA4 Event tag with:

  • Event name: Follow snake_case convention (e.g., form_submit)

  • Event parameters: Add context like form_name, form_location, form_type

  • Trigger: Fire on specific form submissions, not all forms

4. Test before publishing

Use GTM Preview mode to test tags locally. Then enable DebugView in GA4 to confirm events arrive with correct parameters. Wait 24-48 hours and check the Admin > Events list to verify the event appears.

For Properties with Excessive or Disorganized Custom Events

1. Conduct an event audit

Export your event list from Admin > Events or query BigQuery:

sqlCopy code

SELECT

  event_name,

  COUNT(*) AS event_count

FROM `your_project.analytics_XXXXXX.events_*`

WHERE _TABLE_SUFFIX BETWEEN FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY))

  AND FORMAT_DATE('%Y%m%d', CURRENT_DATE())

GROUP BY event_name

ORDER BY event_count DESC

Identify:

  • Events with zero or near-zero counts (candidates for removal)

  • Duplicate events with different names but same purpose

  • Events with high-cardinality names

2. Consolidate redundant events

If you have button_click_header, button_click_footer, button_click_sidebar, replace them with a single button_click event that includes a button_location parameter.

Use GA4's Modify event feature (Admin > Events > Modify event) to rename or consolidate events without changing your implementation. This creates a derived event in GA4's processing layer.

3. Fix high-cardinality issues

Never include unique identifiers in event names. Instead:

❌ Bad: product_12345_viewed, product_67890_viewed
✅ Good: view_item with item_id parameter

If you've already implemented high-cardinality events, create a new properly structured event and deprecate the old one. Use GTM to fire both temporarily while you migrate reporting, then remove the old event.

4. Establish naming conventions

Document and enforce:

  • Format: snake_case, all lowercase, no spaces

  • Structure: verb_noun (e.g., click_button, submit_form, view_product)

  • Prefixes (optional): Use category prefixes for organization (e.g., ecom_purchase, lead_form_submit)

Share this documentation with all team members who can publish GTM changes or deploy tracking code.

5. Implement governance

  • Require measurement plan approval before implementing new events

  • Conduct quarterly event audits to remove unused events

  • Use GTM workspaces and version control to track changes

  • Restrict GTM publish permissions to trained team members

6. Monitor custom definition quota

Regularly check Admin > Custom definitions to see how many event-scoped dimensions you've registered. Before registering a new dimension, ask:

  • Is this parameter necessary in standard reports, or can we access it only in BigQuery?

  • Does this parameter have reasonable cardinality (ideally under 500 unique values)?

  • Can we consolidate multiple similar parameters into one?

Universal Best Practices

Use event parameters, not event names, for variations: One event name, many parameters. This keeps your event list manageable and your analysis flexible.

Follow the event hierarchy: Exhaust automatically collected and enhanced measurement options first. Then check recommended events. Only create fully custom events when necessary.

Plan for BigQuery: Even if you don't use BigQuery today, structure events assuming you will. Clean, consistent event schemas make future analysis exponentially easier.

Document everything: Maintain a living measurement plan that lists every custom event, its purpose, parameters, and implementation method. Update it whenever you make changes.

Test thoroughly: Use GTM Preview, DebugView, and real-time reports to validate events before considering implementation complete. Check back after 48 hours to confirm data flows correctly.

Case Closed: Let Watson Do the Detective Work

Manually auditing custom event implementation requires navigating multiple GA4 interfaces, cross-referencing GTM containers, and analyzing event patterns across reports. For a property with dozens of events, this process takes hours.

The Watson Analytics Detective dashboard spots custom event imbalances instantly. It calculates your manually collected event count, flags properties with insufficient tracking, and highlights those with excessive event sprawl—all in a single view alongside 60+ other data quality checks.

Watson categorizes this as an Advice-level check because the optimal number of custom events varies by business. But whether you need to implement more strategic tracking or consolidate an unwieldy event taxonomy, Watson surfaces the issue immediately.

Stop manually hunting through event lists and GTM containers. Let Watson investigate your GA4 data quality automatically.

Explore Watson Analytics Detective →


Ali Izadi
Previous

Key Events Configuration: Setup and Best Practices
Next

User-ID Setup in GA4: How to Validate?