GA4 provides organisations with significant flexibility in event data collection. While this flexibility is advantageous, it frequently results in a measurement schema that expands without a defined structure.
Common symptoms include tracking similar interactions under different event names, distributing important context across inconsistent parameters, and requiring reporting teams to interpret data that lacks proper definition. As a result, the event list becomes increasingly difficult to maintain and utilise effectively.
A robust GA4 implementation requires that the measurement schema is designed prior to tag configuration. The objective is to collect a consistent set of events that address defined business questions and can be maintained as websites, applications, and customer journeys evolve, rather than attempting to track every possible interaction.
Start with the business questions.
Event design should be initiated based on the key decisions required by the organisation.
For example, an ecommerce business may need to understand:
- Which products are viewed but not added to cart?
- Where do users abandon the checkout process?
- Which promotions influence product selection?
- How does performance vary by product category?
A financial services organisation may instead need to measure:
- Which tools and calculators are used?
- Where do users start an application?
- Which forms are completed?
- How many submitted leads progress to a qualified opportunity?
These questions determine distinct measurement requirements. In the absence of this initial step, teams frequently track low-value interactions due to their technical simplicity. This approach can result in data that appears comprehensive but does not support meaningful analysis.
An inventory of key journeys, actions, and outcomes relevant to the organisation should be established. Each proposed event must have a defined purpose, an assigned owner, and a specified use within reporting.
Use a consistent event naming structure.
GA4 event names are required to describe the action being performed, rather than referencing implementation details or specific interface elements.
A common mistake is to create separate events for every variation of the same interaction:
- homepage_cta_click
- product_page_button_click
- header_demo_button
- footer_contact_click
This approach results in a proliferation of narrowly defined events and complicates the process of determining aggregate metrics, such as the total number of calls to action selected.
A more maintainable structure would use one event name with parameters that provide the context:
The event name should represent the common action, while parameters should provide contextual information regarding location and method.
A consistent naming convention must be applied throughout the schema. The snake_case format is generally appropriate for GA4 event and parameter names. Mixing formats such as formSubmit, form_submit, and Form_Submitted should be avoided. Names that reference tags, triggers, or developer implementations, such as gtm_button_listener_fired, should also be excluded.
Event names should remain stable regardless of changes to the underlying website technology.
Prefer recommended events where they apply.
Google provides recommended event names and parameter definitions for common use cases. These include events such as login, sign_up, search, generate_lead, purchase, add_to_cart and begin_checkout.
These event names should be used when they accurately represent the interaction. According to Google’s recommended events documentation, utilising the prescribed names and parameters enables GA4 to populate predefined dimensions and metrics and to support relevant reports and integrations.
For example, a completed purchase should not be collected as:
if the interaction aligns with the definition of GA4’s purchase event. The use of purchase establishes a standard structure for ecommerce reporting, incorporating parameters such as:
- transaction_id
- currency
- value
- tax
- shipping
- coupon
- items
Similarly, an enquiry form that creates a lead should generally be mapped to generate_lead, provided the event definition is appropriate for the organisation’s process.
Recommended events do not replace the need for planning. They require clear triggers, defined data structures, and validation. Nevertheless, they provide a useful standard and minimise unnecessary variation across implementations.
Custom events should be created only when no suitable automatically collected, enhanced measurement, or recommended event exists.
Design parameters as part of the schema
Event names alone seldom provide sufficient information for analysis. Parameters must be designed concurrently with the event.
A parameter should have:
- A clear definition.
- A consistent data type.
- A documented format.
- A defined set of allowed values where appropriate.
- A clear reporting use.
Consider an event called form_start. By itself, this tells you very little. The following parameters provide useful context:
However, parameters should not be used to collect every available value. Including details such as button_colour, element_position, font_size, and other interface attributes may increase data volume without contributing to decision-making.
Parameters should be used for dimensions that clarify the action or support analysis. Separate parameters should not be created for values that can be normalised into a single field. For instance, a single form_type parameter with controlled values is preferable to multiple parameters such as is_quote_form, is_application_form, and is_contact_form.
It is necessary to distinguish between parameters that are collected and those that are available for reporting. In GA4, custom parameters typically require registration as custom dimensions or metrics before they can be utilised in standard reports and Explorations. A comprehensive implementation must therefore address both data collection and reporting configuration requirements.
Never send personally identifiable information, form responses, email addresses or other sensitive values to GA4. The Google Analytics policy guidance should be considered alongside your organisation’s privacy requirements.
Keep the data layer independent from tags.
The data layer must serve as a stable interface between the website or application and the tagging implementation.
For an e-commerce item view, an implementation might use a structure such as:
This approach separates business data from GA4 tag configuration. The website is responsible for providing product information, while the tag management system maps this information to the relevant GA4 event and parameters.
The data layer must not be designed around individual tags. When product information is required by GA4, advertising platforms, and internal analytics tools, it should be exposed in a consistent structure that supports all destinations.
A well-defined data layer reduces reliance on fragile selectors, page scraping, and custom JavaScript. These alternative methods may function temporarily but are prone to failure when the website structure changes.
For larger organisations, the expected data layer object for each event should be documented. This documentation should include the event name, required fields, optional fields, data types, and examples of valid values.
Assign ownership before implementation.
A measurement schema is only complete once ownership has been formally established.
Ownership should cover at least four areas:
- Business ownership: confirms what the event means and why it is required.
- Development ownership: ensures the correct data is made available in the website or app.
- Analytics ownership: manages the GA4 configuration, reporting and documentation.
- Quality assurance ownership: validates that the event continues to work. In the absence of clear ownership, changes are frequently implemented without consideration of downstream effects. For example, a development team may rename a data layer key, a marketing team may introduce a new form, or an analytics team may create a new custom dimension without updating the central specification.l specification.
Maintain a version-controlled measurement plan. At a minimum, it should record:
Events should be deprecated through a formal process. An event should not be removed from documentation solely because it is no longer preferred. The retirement date and replacement event must be recorded. This process is essential when historical reporting relies on the previous event.
Validate the implementation at multiple levels.
Verifying that a tag fires is insufficient. The complete path from user interaction to final reporting output must be validated.
A practical validation process should include:
- Data layer validation
Confirm that the correct event is pushed and that all required values are present. - Tag manager validation
Check that the intended tag fires once, under the correct conditions, and does not fire for similar but invalid interactions. - Request validation
Inspect the network request to confirm that the event name and parameters are sent to the correct GA4 property. - GA4 validation
Use DebugView and Realtime reporting to confirm that events are received as expected. - Reporting validation
Confirm that registered dimensions, metrics, key events and ecommerce reports use the data correctly. - Regression testing
These checks should be repeated following website releases, consent changes, tag manager updates, and significant design modifications.
Automated monitoring can help identify missing events, duplicate events and unexpected parameter values. TagDataTrust’s analytics data quality service discusses the broader impact of collection issues and the importance of maintaining data quality after an implementation launches.
Understand the reporting consequences.
Inadequate event design extends beyond implementation and impacts reporting, analysis, and decision-making.
When the same action is recorded under multiple event names, reports require additional logic to consolidate the data. Inconsistent parameter values, such as Mortgage, mortgage, and mortgage_product, fragment analysis. Variations in data formats can also compromise the reliability of calculations.
An excessively detailed schema introduces maintenance challenges. Each additional event and parameter must be understood, tested, documented, and monitored. The associated cost includes not only implementation time but also the ongoing effort required for interpretation and preservation.
A well-designed schema enables straightforward answers to common questions:
- What action took place?
- Where did it take place?
- Which product, form or content was involved?
- What was the outcome?
- Which fields are required? If analysts are required to reconstruct these answers from multiple loosely related events, the schema should be revised. Needs further work.
A maintainable GA4 schema is intentionally limited in scope.
The most effective GA4 implementations are characterised not by the quantity of events, but by the presence of defined purposes, consistent parameters, and clear integration into reporting for each event.
Prior to introducing a new event, the following considerations should be addressed:
- Is there already an appropriate recommended event?
- Could an existing event and a parameter represent this?
- Is the interaction important enough to support a business decision?
- Can the data be made available consistently across relevant websites and apps?
- Who will own and validate it after launch?
Addressing these considerations will help ensure that the measurement schema does not devolve into a collection of isolated implementation requests.
In cases where the GA4 event structure has expanded without a unified specification, a review of the data layer, event taxonomy, and reporting configuration is recommended to identify areas requiring attention. TagDataTrust’s GA4 implementation service supports this process across Google Tag Manager, Tealium, and other implementation environments.
If you’d like to hear more on this topic and set up a 1:1 call with us, please use the contact form. Contact a Consultant
