GA4 switched from a session-based model to an event-based model. That is the right architectural decision for modern measurement. But the event-based model means that what you measure — and how you name it — becomes the entire foundation of your analytics. Get the taxonomy wrong on day one and you are building reports on corrupted data for months before anyone notices.
The duplicate event problem nobody checks for
When you install GA4 via Google Tag Manager without disabling GA4's built-in Enhanced Measurement, you get both firing simultaneously. Enhanced Measurement fires page_view events. Your GTM tag fires page_view events too. The result is double-counted pageviews that look plausible at aggregate level but are inflated by a factor you cannot calculate retroactively. The fix is straightforward but most setups skip it: when you manage GA4 through GTM, turn off Enhanced Measurement in the GA4 Admin UI for every event type you are controlling through GTM. This single configuration error corrupts session counts, bounce rates, pages-per-session, and every funnel step that depends on accurate pageview data. I find it in roughly two-thirds of GA4 accounts I audit.
Naming conventions that break everything downstream
GA4 event names are case-sensitive and must not contain spaces. Most implementations accumulate a mix of naming styles across different development phases: purchase (lowercase), Form_Submit (mixed case), Lead Qualified (with a space, which GA4 silently accepts but BigQuery cannot query without escaping). Six months into a typical GA4 implementation you find three different event names for 'form submission' depending on which developer last touched the tag. The downstream consequence: your conversions view shows three separate events, none individually looking significant. The fix is a taxonomy document written before any implementation begins — every event name and parameter name standardised in snake_case, documented with the triggering condition and the full parameter payload.
Choosing the wrong events as conversions
GA4 lets you mark any event as a conversion. Most teams mark form_submit or thank_you_page_view. This is correct behaviour but creates a serious problem when the same event fires across multiple form types: newsletter signups, demo requests, contact forms, and content downloads all triggering the same form_submit event, all counted as conversions in campaign reporting. The result is a conversion rate that treats a newsletter signup and a demo request identically despite one being worth nothing and the other being the primary revenue driver. The correct approach is unique event names for each form type — demo_request_submit, newsletter_signup_submit, contact_form_submit — with the intent quality built into the event name itself rather than inferred from field values.
Custom dimensions nobody registered
GA4 events carry parameters, but those parameters only appear in reports if they are explicitly registered as custom dimensions in GA4 Admin. Most implementations fire events with genuinely useful parameters — user_type, plan_tier, lead_score, content_category — that never get registered. The parameters exist in the raw BigQuery export, but they are invisible in every GA4 standard report. The consequence: your team builds reports that look fine on the surface but cannot answer the questions that matter: which plan tier do your most engaged users arrive on, which content category precedes demo requests. The fix is simple but requires discipline at implementation time. Every event parameter that anyone might want to filter or segment by in a report needs a matching custom dimension registered in GA4 Admin before the data is collected.