The value of analytics data is contingent upon its accuracy, consistency and governance. Google Analytics 4 has replaced Universal Analytics as Google’s standard analytics platform, but a migration to GA4 is not a simple transfer of tags, goals and reports. The platforms use different data models, configuration options, and definitions of core metrics. A migration may improve the structure of analytics collection, but that outcome depends upon the quality of the measurement design, the implementation method and the validation process.

For enterprise organisations, an incomplete or weak migration may affect marketing reporting, financial reconciliation, product analysis and privacy governance. The risk is not limited to missing events. An implementation may appear complete within the interface while failing to accurately represent customer journeys, consent states, or commercial outcomes. GA4 migration services are not a replacement for measurement strategy, data governance, source-system reconciliation, privacy review or source data remediation.

This article sets out a due-diligence framework for assessing GA4 migration services or reviewing an existing migration. The purpose is to define the technical and governance controls that should be in place if GA4 is to produce reliable business information.

1. Discovery should cover the complete measurement environment

A migration should begin with discovery rather than implementation.

It is necessary to review the existing analytics environment across all relevant websites, apps and supporting systems. This assessment may include:

• Universal Analytics properties and views
• Existing GA4 properties and data streams
• Google Tag Manager, Tealium iQ or another tag management system
• The website and app data layers
• Consent management platforms and consent signals
• CRM, ecommerce and transactional systems
• Reporting tools, dashboards and data warehouses
• Marketing platform integrations
• Existing documentation and ownership arrangements

The discovery phase should also identify the internal stakeholders who use the data and the decisions that depend upon it. Marketing, product, finance, analytics, engineering and privacy teams may each have different requirements, and those differences can materially affect the design.

A suitable output is a documented assessment of the current state, including known gaps, duplicate tracking, unsupported assumptions and dependencies. It should also include a clear RACI covering implementation, approvals, data governance and ongoing maintenance.

• Recommended action: produce a discovery document before implementation begins.
• Recommended action: document dependencies, ownership, known data quality issues and approval routes.
• GA4 migration does not resolve pre-existing issues in the data layer, ownership model or reporting process. If the work proceeds directly from a list of UA tags to a new GA4 container, the due-diligence process is likely to be incomplete.

2. Measurement design should precede event configuration

GA4 is event-based, but not every interaction should become an event. The measurement framework should first establish the relationship between business objectives, key performance indicators, events and parameters.

For each measurement requirement, document:

1. The business question being answered
2. The KPI or metric required
3. The user interaction or system action that produces the data
4. The event name
5. The required event parameters
6. The source of each value
7. The intended report, audience or activation
8. The owner responsible for approving future changes

This approach helps prevent the implementation from becoming a collection of technically valid but commercially irrelevant events. It is also necessary to recognise that event design alone does not resolve deficiencies in business definitions, source-system logic or downstream reporting models.

The framework should distinguish between:

• Automatically collected events
• Enhanced Measurement events
• Recommended events
• Custom events
• Key events used for business reporting
• Parameters used for analysis or segmentation

Google’s documentation on events and key events should be used as a reference, but recommended event names should not be adopted automatically without considering the organisation’s reporting model, available data layer inputs and downstream reporting requirements.

• Recommended action: define business questions, required metrics, event definitions and parameter sources before configuration work begins.
• Recommended action: distinguish clearly between reporting events, analysis parameters and activation use cases before implementation starts.

3. Event mapping should not be treated as a like-for-like exercise

Universal Analytics used a category, action and label model for many interactions. GA4 uses event names and parameters. These structures are not interchangeable. A direct conversion may preserve labels from the legacy setup without preserving the underlying meaning.

A formal event mapping document should show the relationship between the legacy implementation and the new design. It should identify where:

• A single UA event becomes a GA4 event with multiple parameters
• Several legacy events can be consolidated
• A UA goal requires a new event or a different trigger
• Ecommerce tracking needs to be rebuilt using the GA4 item schema
• Existing custom dimensions require new event-scoped or user-scoped definitions
• Enhanced Measurement may duplicate manually configured events

For example, a legacy product interaction may have been recorded using:

• Category: Product
• Action: Add to basket
• Label: Product name

In GA4, the recommended structure would normally use an add_to_cart event with parameters such as product ID, product name, price, quantity and item category. The correct design depends on the available data layer, the reporting requirement and whether downstream systems need the same business definition.

The mapping document should include event owners, implementation status, test cases and approval dates. It should be treated as a controlled project document rather than an informal spreadsheet used only during setup. GA4 event mapping does not, by itself, resolve inconsistent business definitions between analytics, BI and finance teams.

• Recommended action: maintain event mapping as a governed implementation artefact and require formal approval for material changes.
• Recommended action: include test cases, implementation status and ownership within the mapping document.

4. Property and data stream architecture requires an explicit decision

Enterprise organisations often operate multiple domains, regional sites, apps or brands. The GA4 property structure should reflect how data needs to be governed and analysed rather than defaulting to a single pattern.

The migration assessment should confirm:

• Which websites and apps require separate data streams
• Whether cross-domain measurement is required
• Whether subproperties or roll-up properties are appropriate
• How regional data access should be managed
• Which domains should be excluded from referrals
• How internal traffic will be identified and filtered
• Whether payment providers, authentication services or third-party platforms interrupt journeys
• Whether client-side or server-side collection is required

Official guidance on GA4 properties and data streams should be used alongside the organisation’s own governance and reporting requirements.

The implementation method should also be documented. Depending on the existing technology stack, this may involve gtag.js, Google Tag Manager, Tealium iQ, server-side tagging or a combination of these.

A robust implementation should apply a consistent architectural logic. The selected structure should be justified by reporting, governance and operational requirements rather than reused by default across all sites. Property design may improve governance and reporting clarity, but it is not a replacement for disciplined naming, access control and change management.

• Recommended action: document the rationale for the selected property, stream and collection model before implementation begins.
• Recommended action: record cross-domain logic, referral exclusions, internal traffic rules and collection method decisions as controlled implementation documentation.

TagDataTrust’s GA4 implementation with Tealium Server-Side case study provides an example of how server-side implementation and event parameter auditing can be combined for a data-sensitive organisation.

5. Historical data should be treated as a separate workstream

Universal Analytics data does not migrate automatically into GA4. The two platforms cannot provide a single continuous historical dataset simply by applying the same property or measurement ID.

Before migration, identify the reports and dimensions that must be retained. These may include:

• Sessions and users
• Transactions and revenue
• Goal completions
• Campaign performance
• Content performance
• Ecommerce product data
• Custom dimensions and metrics
• Audience definitions
• Data required for regulatory, financial or contractual reporting

The organisation should agree how this information will be exported, where it will be stored and who will have access to it. Options may include scheduled reports, API extracts, warehouse exports or an existing BI environment.

The historical data plan should also record the point at which reporting changes from UA to GA4. Because the platforms define users, sessions, engagement and attribution differently, year-on-year comparisons require explanation and, in some cases, a separate reconciliation model.

This is a structural limitation of any GA4 migration project. A migration may establish a new reporting baseline, but it does not recreate Universal Analytics history inside GA4.

• Recommended action: define archival, access and reconciliation requirements for UA data as a separate workstream.
• Recommended action: document the reporting transition point and the method used to explain year-on-year changes across platforms.

6. Retention settings require an early review

GA4 event-level and user-level data retention settings are separate from the availability of aggregate data in standard reports.

The default retention configuration may be unsuitable for an enterprise reporting requirement. In many cases, the event and user data retention setting should be reviewed and changed to the maximum period permitted by the property and the organisation’s legal and analytical requirements. For standard GA4 properties, this is commonly 14 months, as described in Google’s documentation on data retention controls.

Changes to retention settings are not retroactive. Data already deleted under the previous configuration cannot be restored through a later setting change.

The review should document:

• Current retention settings
• The retention period required by analysts and BI teams
• Legal and privacy approval
• Whether Explorations require longer access to granular data
• The warehouse archive strategy
• The process for deleting data when required

Google’s privacy controls in Google Analytics should be used alongside the organisation’s own data retention policy.

• Recommended action: confirm retention settings at the start of the migration and obtain legal and governance approval for the selected configuration.
• Recommended action: align retention settings with warehouse export strategy and internal deletion requirements.

7. BigQuery should be assessed as part of the migration

BigQuery export provides access to raw GA4 event data for analysis outside the GA4 interface. It can also support long-term retention, integration with CRM and transactional data, and automated validation.

The due-diligence review should confirm:

• Whether each relevant GA4 property is linked to BigQuery
• Whether daily export, streaming export or both are required
• Whether the expected event volume is within the applicable limits
• Who owns the Google Cloud project and dataset
• How access controls will be managed
• How data will be partitioned, modelled and documented
• How BigQuery costs will be monitored
• How raw events will be combined with non-Analytics data

Google states that standard properties have a daily BigQuery export limit of one million events. Streaming export provides current-day data but is a best-effort service and can produce different results from the completed daily export. The applicable limits and export behaviour should be reviewed in Google’s official documentation before the export is relied upon operationally.

The BigQuery export is not identical to the GA4 interface. The export contains raw event and user-level data, while the interface applies additional processing and reporting logic. Reconciliation therefore requires defined queries and documented expectations.

BigQuery may be useful, but it is not a replacement for implementation QA, governance or clear metric definitions. Access to raw data does not automatically resolve discrepancies or modelling issues.

The GA4 BigQuery Export documentation and BigQuery Export schema should be included in the technical handover.

• Recommended action: assess BigQuery requirements during scoping rather than after go-live.
• Recommended action: define dataset ownership, access controls, partitioning and query expectations before export is relied upon for reporting or QA.

8. Consent implementation should be tested as a data flow

Consent should not be treated as a banner configuration only. The migration should verify how the CMP communicates consent states to the tag management system and GA4. Reference should be made to Google’s official consent documentation where Consent Mode is in scope.

Testing should cover:

• Initial page load before a consent decision
• Acceptance of analytics storage
• Rejection of analytics storage
• Partial consent choices
• Changes to consent after the initial decision
• Regional consent rules
• Consent persistence across sessions
• Web and app behaviour where both are in scope
• Consent Mode v2 signals where applicable
• Data sent to GA4, advertising platforms and server-side endpoints

The implementation should document which tags require which consent categories and what happens when consent is denied. This is also an appropriate stage to review URL redaction, personal data handling, user IDs and the collection of sensitive values.

This work may reduce compliance and data quality risk, but it is not a replacement for legal review or internal privacy governance. Depending on the jurisdiction, sector and data model, additional controls may still be required.

A CMP or Google Consent Mode review should form part of the migration sign-off rather than being left to a later compliance exercise.

• Recommended action: test consent states as part of end-to-end data flow validation rather than limiting review to banner behaviour.
• Recommended action: verify what is sent to GA4, advertising platforms and server-side endpoints under each consent state.

9. QA should include functional testing and reconciliation

A migration is not complete when events appear in DebugView. Interface-level confirmation is not sufficient evidence of measurement quality, commercial accuracy or reporting fitness.

QA should test critical journeys across devices, browsers, regions and consent states. Key flows may include:

• Product views and searches
• Add-to-basket and checkout steps
• Purchases, refunds and cancellations
• Account creation and login
• Lead forms
• Downloads and outbound links
• App installation and key product actions
• Cross-domain journeys
• Payment and authentication redirects

Each event should be checked for correct naming, firing frequency, parameter values, timestamps and associated user or session information. Enhanced Measurement should be reviewed for duplicate collection.

Reconciliation should compare GA4 with systems that represent the underlying business outcome. For ecommerce, this normally includes order counts, transaction IDs, revenue, tax, shipping and refunds. For lead generation, it may include CRM records and qualified opportunities.

A difference is not automatically evidence of an implementation error. However, the acceptable variance should be agreed in advance, investigated and documented. TagDataTrust’s analytics data quality service describes the importance of identifying data collection issues before they influence budget and operational decisions.

This is also where the limits of the platform become clearer. GA4 can support robust reporting, but it does not remove normal causes of variance such as consent behaviour, browser restrictions, payment redirects, identity gaps or delays in downstream systems.

• Recommended action: define QA scenarios, expected outputs and reconciliation tolerances before launch approval is granted.
• Recommended action: compare analytics outputs against source systems for the journeys that matter commercially and operationally.

10. Training and governance determine whether the implementation remains reliable

The final assessment should cover the organisation’s ability to operate GA4 after the migration.

Training should be role-specific. Analysts may require instruction on Explorations, event parameters, key events and BigQuery. Marketing teams may need guidance on campaign reporting and attribution. Product teams may require support with feature adoption and user journeys. Executives should understand why GA4 figures may not match historical UA reports.

The handover should include:

• Event and parameter documentation
• Property and stream architecture
• Consent and privacy configuration
• QA evidence and reconciliation results
• Tag naming and release procedures
• Change request and approval processes
• Ownership and escalation routes
• A schedule for ongoing audits and monitoring

Without governance, future website releases, campaign changes and platform updates will gradually reduce data quality.

Training and governance may make a migration more durable, but they are not a one-off fix. Depending on the release cadence and complexity of the organisation, periodic audits and controlled change processes may still be necessary.

• Recommended action: include documentation, ownership and audit processes within the implementation handover.
• Recommended action: define escalation routes, release procedures and a schedule for periodic implementation review.

11. When GA4 migration services are likely to be appropriate

GA4 migration services are generally appropriate where the organisation has moved beyond a basic website setup and requires a more deliberate approach to measurement design, implementation governance and validation. This is often relevant where multiple sites or apps are involved, where ecommerce or lead-generation reporting is business-critical, where consent controls require review, or where analytics outputs are subject to scrutiny by finance, BI or compliance teams.

They are less effective when the work is framed narrowly as a tag deployment exercise. A migration project may improve the structure and reliability of data collection, but it will not by itself resolve weak source systems, inconsistent KPI definitions, limited internal ownership, unresolved privacy questions or broader reporting governance deficiencies.

• Recommended action: assess whether the requirement is genuinely a migration programme or a broader measurement remediation project.
• Recommended action: confirm whether reporting, governance and privacy requirements justify a formal migration workstream.

12. A practical approach

It is generally advisable to treat GA4 migration as a structured measurement review rather than a one-time platform change.

A practical sequence includes:

1. Discovery across platforms, stakeholders and dependencies
2. Measurement design based on business questions and reporting requirements
3. Controlled event mapping from UA to GA4
4. Property, stream and collection architecture decisions
5. Historical data planning and reporting transition design
6. Retention, privacy and consent review using official platform guidance
7. BigQuery assessment where longer-term analysis or validation is required
8. Functional QA and reconciliation against business systems
9. Handover, training and governance planning

This approach may take longer than a simple retagging exercise, but it is more likely to produce a GA4 implementation that remains understandable and supportable after go-live. It should also be recognised that implementation quality depends upon the completeness of the data layer, the availability of internal ownership and the quality of source-system validation.

• Recommended action: sequence migration activity so that design, governance and validation are completed before launch sign-off.
• Recommended action: use official Google documentation as an implementation reference rather than as a substitute for solution design.

Conclusion

GA4 migration may be valuable for enterprise organisations, but the value of the resulting data is contingent upon implementation quality, governance discipline and validation against source systems. GA4 can support a more flexible measurement framework, but it is not a replacement for sound data architecture, privacy review, business definition alignment, source data remediation or reconciliation controls.

A measured migration should therefore include discovery, measurement design, controlled implementation, formal QA and operational governance. Where those controls are absent, a migration may produce technically valid data that is not sufficiently reliable for business decision-making. The benefits of GA4 migration are real, but so are its limitations, particularly in relation to historical continuity, source-system variance and ongoing operational ownership.

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