GA4 Event Tracking Blueprint

GA4 event tracking without a measurement plan produces data that looks complete but is not trustworthy. The events fire, the reports populate, the dashboards show numbers — and none of it tells you what you actually need to know because no one defined what "need to know" meant before the implementation began. A GA4 measurement plan is not a documentation exercise; it is the design specification that determines whether your analytics data can support real decisions.

GA4 is architecturally different from Universal Analytics in ways that make the measurement plan more important, not less. Universal Analytics was built around sessions — discrete bounded time windows that collected hits. GA4 is built around events — discrete structured signals where every interaction, every page view, every conversion is an event with a name and optional parameters. The flexibility is real. Events can carry any parameters you define, in any combination. That flexibility collapses into uselessness if the taxonomy isn't designed upfront, because once you have six months of event data with inconsistent parameter naming and undocumented intent, the data is irretrievable without a full reimplementation.

Designing a GA4 event taxonomy

A GA4 event taxonomy defines the complete set of events your property should fire, what each event means, what parameters it carries, and what business question each event answers. Without this definition, events are named by whoever implements them, parameters are added opportunistically, and the result is a schema that varies between developers and changes silently over time.

GA4 has four event categories in its data model. Automatically collected events — events that GA4 fires without any configuration, including session_start , first_visit , and user_engagement . Enhanced measurement events — events enabled through the GA4 admin interface, including scroll depth, outbound click, site search, video engagement, and file download. Recommended events — events with Google-specified names and parameters for specific verticals (ecommerce: add_to_cart , begin_checkout , purchase ). Custom events — events you define for business-specific interactions not covered by the other categories.

The taxonomy design principle is simple: use recommended event names whenever the interaction fits the definition, because recommended events unlock GA4's built-in reporting surfaces and BigQuery schema alignment without custom configuration. Deviate from recommended event names only when the interaction genuinely does not fit the recommended model, and document the deviation explicitly. Custom events named button_click or form_submit are not taxonomies; they are noise with labels.

For each event in the taxonomy, document: event name, trigger condition (exactly when this event should fire — not "when a user clicks a button" but "when a user clicks the primary CTA button in the hero section of the homepage"), parameters (with names, data types, and example values), business question answered, and which team owns the event definition.

Custom dimensions and the data model

Event parameters in GA4 are not automatically available in reports. A parameter named user_type sent with every event is invisible in GA4's standard reports until it is registered as a custom dimension. This is a common source of confusion for teams migrating from Universal Analytics, where custom dimensions were a configuration choice rather than a reporting prerequisite.

GA4 has two scopes for custom dimensions: event-scoped and user-scoped. An event-scoped custom dimension captures a value that is specific to a single event — for example, the item_category parameter on a view_item event. A user-scoped custom dimension captures a value that describes the user across their entire session history — for example, a subscription_tier parameter that reflects the user's current subscription status.

GA4 free properties are limited to 50 event-scoped custom dimensions and 25 user-scoped custom dimensions. GA4 360 properties have higher limits. These limits are not large. An organisation with a complex product and an undisciplined measurement approach will exhaust event-scoped custom dimensions within six months of implementation. The measurement plan should include a custom dimension budget — a deliberate accounting of which parameters are worth registering as dimensions — so that the implementation remains within bounds and high-priority dimensions are not unavailable because low-priority ones consumed the quota.

Server-side tagging: when it becomes necessary and how it changes the architecture

Client-side GA4 tagging — the standard implementation where the GA4 tag fires in the browser via Google Tag Manager — is the default for most properties. Server-side tagging is a different architecture: a tagging server, typically deployed on Google Cloud Run, receives events from the browser, processes them, and forwards them to GA4 and other destinations. The browser does not communicate with GA4 directly; it communicates with the server, which communicates with GA4.

Server-side tagging becomes necessary when: first-party data compliance requirements mean client-side tracking infrastructure is architecturally unacceptable; ad blocker prevalence is significantly degrading event collection rates (common in developer, security, and privacy-conscious audiences); cross-domain or cross-device identity resolution needs to be controlled server-side; data transformation or enrichment needs to happen before events reach GA4 (for example, enriching events with CRM data without exposing that data to the browser).

The server-side architecture adds cost and operational complexity. A tagging server requires infrastructure, deployment, and ongoing maintenance. For most properties, the data quality uplift from server-side implementation — typically 10–25% more events collected, depending on audience browser settings — does not justify the overhead until the property is at a scale where that 10–25% represents material revenue attribution. The measurement plan should include an explicit assessment of whether server-side tagging is warranted at current scale.

Consent mode, attribution models, and BigQuery integration

Consent Mode V2. Google's Consent Mode V2 — required for EEA properties running Google advertising — connects GA4 and Google Ads to a consent signal from the site's consent management platform. When a user declines analytics consent, GA4 does not fire events for that user. With Consent Mode V2 enabled and modelling active, GA4 uses behavioural modelling to estimate the behaviour of non-consenting users, filling the measurement gap that consent-based collection creates. Without Consent Mode V2 configured correctly, EEA properties lose ad personalisation and potentially face compliance exposure. The correct implementation requires bidirectional integration between the consent platform and Google Tag Manager, not just a default consent signal.

Attribution models. GA4's default attribution model is data-driven attribution — a machine learning model that distributes conversion credit across touchpoints based on their observed effect on conversion probability. This is contextually superior to last-click attribution for most conversion types. However, data-driven attribution requires a minimum event volume to produce stable models (approximately 400 conversion events per 30 days, per conversion event). Below that threshold, GA4 falls back to last-click. Properties below the threshold should configure this explicitly and choose an alternative model deliberately rather than accepting whatever the fallback produces.

BigQuery integration. GA4 offers daily (free) and streaming (GA4 360 only) BigQuery export. The BigQuery export contains the full event-level data, including all parameters, without GA4's standard UI sampling. For any property doing serious analysis — cohort analysis, funnel analysis, multi-touch attribution modelling, joining analytics data with CRM or revenue data — BigQuery is not optional. GA4's standard UI applies sampling at relatively low session thresholds. An analysis run in BigQuery on exported data will not sample. The standard BigQuery export schema is flat and event-centric: one row per event, with all parameters in a repeated record. Understanding this schema before writing queries is necessary to avoid expensive full-table scans.

Logic Grid Studio's growth systems and analytics practice covers GA4 measurement plan design, implementation, consent mode configuration, and BigQuery integration as a structured engagement, not a tag deployment service. The distinction is deliberate: analytics infrastructure that is deployed without a measurement plan creates technical debt in data — debt that compounds over time and is recovered only through reimplementation.