GA4 Migration Audit Checklist: A Step-by-Step Workflow to Verify Data Quality

Overview

GA4 data quality depends on several connected layers. A page can load correctly while an important event fails to fire; an event can appear in DebugView while its parameters are missing from reports; and a conversion can be recorded accurately while being assigned to the wrong channel. A useful GA4 audit checklist therefore tests the complete path from business question to implementation, collection, processing, and reporting.

Start by documenting what the migration is expected to reproduce and what it is intentionally changing. Legacy analytics may use different session definitions, attribution logic, filters, naming conventions, or conversion rules. A direct one-to-one comparison can be misleading if the underlying measurement model is different. Record these differences in an audit log rather than treating every variance as an implementation error.

Before testing, gather four inputs:

• The current GA4 property, data streams, user access levels, and connected products.
• A tracking plan that maps business questions to events, parameters, and conversions. The tracking plan template can provide a starting structure.
• A list of priority journeys, such as lead submission, account creation, checkout, subscription, or article engagement.
• Reference figures from the previous setup, labeled with their date range, filters, timezone, and definitions.

For each audit item, record the status as pass, fail, blocked, or not applicable. Add the page or journey tested, the device and browser, the date, evidence such as a screenshot or request payload, the owner, and the remediation deadline. This turns a one-time review into a practical data-quality process.

Checklist by scenario

1. Pre-audit: confirm the measurement design

• Confirm the correct GA4 property and web data stream are being tested. Check that production and staging environments are not sending indistinguishable data into the same destination.
• Verify the stream’s measurement settings and enhanced measurement choices against the tracking plan. Do not assume an automatically collected interaction replaces a business-critical custom event.
• Review event names, parameter names, value formats, and required conditions. Use consistent lowercase naming where that is the convention in your plan.
• Mark which events are intended to become conversions. A conversion should represent a meaningful business outcome, not every interaction that might be useful for analysis.
• Document timezone, currency, internal traffic rules, unwanted referrals, cross-domain requirements, and any retention or consent-related assumptions.
• List integrations that depend on GA4 data, including advertising destinations, audiences, dashboards, exports, and warehouse pipelines.

2. Live verification: test collection on real journeys

• Open the site in a clean session and test the highest-value journeys from start to finish: landing page, navigation, form completion, purchase or subscription, and confirmation page.
• Use Tag Assistant, browser developer tools, and GA4 DebugView where appropriate. Confirm that the expected event is sent once, with the expected parameters and values.
• Check that page location, page title, hostname, user status, item data, transaction identifiers, and other required fields are populated correctly for the relevant event.
• Test duplicate actions, refreshes, back-button behavior, validation errors, and failed payments. These edge cases often reveal duplicate conversions or events that fire before the action is complete.
• Repeat priority tests on representative mobile and desktop layouts. Test more than one browser when the site uses different consent, checkout, or embedded-form behavior.
• For cross-domain journeys, verify that the user remains associated with the intended session and that the destination domain does not become an unwanted referral. See the cross-domain tracking guide for a focused testing sequence.
• For ecommerce, check item arrays, revenue, tax, shipping, currency, and transaction identifiers against the source system. Use the GA4 ecommerce tracking guide when validating purchase and item events.

3. Privacy and consent scenario

• Test the experience before consent, after consent, and after consent is withdrawn when the site supports those states.
• Confirm that tags and data behavior follow the organization’s documented consent requirements. Separate the question of whether a request is allowed from the question of whether the request contains the correct data.
• Check that consent signals are available before dependent tags fire and that a consent update does not unintentionally create duplicate pageviews or conversions.
• Record the browser state, consent choice, region assumptions, and tag behavior in the evidence. Consent Mode v2 implementations should be tested as a distinct workflow rather than inferred from ordinary page testing; use the Consent Mode v2 implementation guide as a companion reference.

4. Reporting validation scenario

• Confirm that important custom dimensions, metrics, and event parameters are registered where reporting requires them. A parameter in a request is not automatically equivalent to a usable report field.
• Compare event counts, conversion counts, users, sessions, revenue, and traffic sources using matching date ranges and filters. Explain expected differences before escalating them.
• Review channel grouping and campaign classifications. Check UTMs on paid, email, partner, and social links against your naming convention. The UTM naming guide can help standardize this review.
• Open the reports and explorations used by stakeholders. Verify that filters, comparisons, segments, date settings, and calculated fields still answer the intended business questions.
• Check downstream dashboards and exports for broken field names, changed scopes, null values, or unexpected increases in direct or referral traffic.

What to double-check

Some defects are easy to miss because the setup appears to work at a surface level.

1. Event volume: Look for sudden zeros, unexplained spikes, and identical counts across unrelated pages. A repeated event may indicate a tag firing on both a click and a confirmation state.
2. Parameter scope: Confirm whether a value is event-scoped, user-scoped, or item-scoped before using it in a report. Combining scopes without understanding them can produce misleading comparisons.
3. Conversion definition: Verify the trigger, counting behavior, and naming of each conversion. Test a successful completion and an incomplete attempt separately.
4. Identity and session continuity: Check login transitions, cross-domain movement, embedded payment providers, and redirects. These are common points where one journey becomes several apparent sessions.
5. Attribution inputs: Inspect landing-page URLs, UTMs, referrers, auto-tagging parameters, and redirects. A technically valid GA4 setup can still produce poor marketing attribution if campaign links are inconsistent.
6. Data latency: Separate live debugging from standard reporting validation. Real-time or debug surfaces are useful for implementation checks, while processed reports may require a later review.
7. Warehouse or API output: If the organization uses BigQuery or another export, verify table availability, event names, parameter extraction, timezone handling, and duplicate logic separately from the GA4 interface. Export schemas and query examples should be reviewed when platform changes affect them.

Keep a small set of known test cases with expected outcomes. For example: “one completed form creates one lead conversion,” “a rejected form creates no lead conversion,” and “a purchase includes one unique transaction identifier.” These cases make future regression testing faster and more objective.

Common mistakes

• Auditing only the tag container: Published tags do not prove that triggers, payloads, consent states, or downstream reports are correct.
• Comparing totals without matching definitions: Differences between legacy analytics and GA4 may result from changed attribution, filters, session logic, or timezone settings. Document the comparison conditions first.
• Testing only the happy path: Errors, refreshes, redirects, rejected payments, and repeated clicks often create the most costly data problems.
• Using inconsistent event names: Similar actions with several names fragment reporting and make conversion maintenance harder. Resolve naming decisions in the tracking plan.
• Marking every useful event as a conversion: Keep conversions focused on outcomes used for optimization or business reporting. Analyze supporting interactions as events or engagement measures.
• Ignoring internal and test traffic: Development activity can contaminate production data, especially during migration week. Define how test traffic is identified and excluded or segmented.
• Failing to assign remediation owners: An audit without owners, evidence, and deadlines becomes a list of observations rather than an improvement plan.

When to revisit

Run the complete GA4 migration audit before a major site release, a redesign, a checkout change, or the launch of a new marketing channel. A lighter version is appropriate for quarterly data-quality reviews and seasonal planning cycles. Re-test immediately after changes to Google Tag Manager, consent management, cross-domain configuration, ecommerce flows, advertising integrations, or channel-grouping rules.

Refresh the checklist’s recommended events, parameters, and troubleshooting scripts at least every six months, and sooner after significant GA4 interface, API, or consent-related changes. Review example warehouse queries and export table names annually or whenever the export schema changes. Revisit the checklist when reporting users introduce a new dashboard, conversion definition, audience, or attribution question.

For the next audit, begin with the unresolved items from this one. Select three to five priority journeys, run the known test cases, and attach evidence to each result. Then compare the current findings with the previous audit: which defects were fixed, which reappeared, and which new site or channel changes require coverage? This simple cycle turns a GA4 audit from a migration task into a repeatable control for trustworthy web analytics.