GA4 Analytics Audit Checklist: Find and Fix Tracking Gaps

Overview

A useful audit is more than checking whether the Google tag appears on a page. It tests the complete measurement chain: the business requirement, the tracking plan, the implementation, the consent state, the data received by GA4, and the reports used by stakeholders.

Start by defining the audit scope. A small marketing site may need to validate page views, form submissions, phone clicks, and campaign parameters. A subscription or ecommerce site may also need account creation, trial starts, purchases, refunds, revenue, and cross-domain journeys. Record the date, environments tested, tools involved, and person responsible for resolving each issue.

Keep an evidence log as you work. For every check, note the expected behavior, the observed behavior, the URL or test case, and the next action. This prevents an audit from becoming a list of vague concerns and creates a baseline for the next review.

If your event definitions need structure before testing, use a GA4 tracking plan template to document event names, parameters, owners, and conversion mapping. The plan should be the reference point for both implementation and reporting.

Checklist by scenario

1. Core GA4 setup

• Confirm the intended GA4 property and data stream are receiving traffic.
• Check that the Google tag is installed on every relevant page, including key landing pages, forms, checkout steps, and confirmation pages.
• Verify that internal, staging, or test traffic is identified and handled consistently.
• Review data filters, unwanted referrals, session settings, and cross-domain configuration where applicable.
• Confirm that the property timezone, currency, reporting identity, and retention settings match the measurement requirements.
• Check that linked products, audiences, and reports use the intended property rather than an old or duplicate account.

Do not treat the presence of a tag as proof that setup is correct. A tag can load while sending data to the wrong measurement ID, firing before the required values exist, or being blocked under particular consent conditions.

2. GA4 event tracking

• Compare the implemented events with the approved tracking plan.
• Check event names for consistent spelling, casing, and naming conventions.
• Verify that required parameters are present and contain useful values rather than empty strings, placeholder text, or unexpected objects.
• Test important actions on desktop and mobile, including validation errors, repeated clicks, refreshes, and back-button behavior.
• Confirm that events fire once per meaningful action unless repeated firing is intentional.
• Check whether events are sent from the browser, a server-side system, or both, and test for duplicate collection.

For practical debugging, use Tag Assistant, the browser developer tools, and GA4 DebugView together. Tag Manager can show whether a trigger fired; the network panel can show the request and parameters; DebugView can help confirm that GA4 received the event. A detailed workflow is available in How to Debug GA4 and Google Tag Manager Tracking.

3. Conversion tracking

• List the actions that represent meaningful business outcomes, not every interaction a user can perform.
• Confirm that each required conversion event is marked appropriately in GA4.
• Test the complete path from landing page to confirmation, including failed submissions and duplicate confirmations.
• Check whether a conversion can be triggered without a genuine outcome, such as by revisiting a thank-you page.
• Compare conversion counts with the relevant source of truth, such as a CRM, payment platform, or lead database, while allowing for differences in definitions and time windows.
• Document the conversion window, counting approach, and filters used in reports.

A discrepancy does not automatically mean GA4 is wrong. The systems may count different events, use different timestamps, exclude consent-denied users, or apply different attribution rules. The audit should identify the reason for the difference rather than force the numbers to match.

4. Ecommerce and revenue data

• Test product views, list selections, cart additions, checkout steps, purchases, refunds, and other events in the approved ecommerce plan.
• Check item IDs, names, categories, quantities, prices, discounts, tax, shipping, transaction IDs, and currency values where relevant.
• Verify that one purchase does not produce multiple transactions after refreshes, retries, or payment redirects.
• Test successful, failed, cancelled, and returned payment paths.
• Compare transaction IDs and revenue totals with the commerce or payment system using a clearly defined date range.

Revenue validation deserves a separate test record because a site can have accurate traffic and conversion counts while still sending incomplete item data or incorrect currency values.

5. UTM parameters and campaign attribution

• Use a shared naming convention for source, medium, campaign, term, and content values.
• Check links in email, paid media, social posts, partner placements, QR codes, and offline materials.
• Confirm that redirects preserve campaign parameters.
• Test landing pages for unwanted referral replacement, missing parameters, and inconsistent capitalization.
• Review whether internal links incorrectly use UTMs and overwrite the original campaign context.
• Keep a campaign tracking template or UTM builder with controlled values and an owner for governance.

Campaign data is only useful when naming is consistent. Decide whether values should be lowercase, how paid channels are represented, and which fields are mandatory before reviewing reports.

6. Consent and privacy signals

• Test the site with consent granted, denied, withdrawn, and left undecided where those states are available.
• Confirm that the consent management platform communicates the expected state to Google tags and other analytics tools.
• Check that tags requiring consent do not fire prematurely under the organization’s chosen configuration.
• Verify that consent changes are reflected when a visitor updates preferences during a session.
• Document which data may be reduced or unavailable when consent is not granted, so stakeholders do not interpret lower volumes as an implementation failure.

Consent behavior is part of measurement design, not just a banner review. Your audit should record the tested states and the expected reporting effect. For broader platform decisions, compare the implementation requirements with a privacy-focused alternative in GA4 vs. Matomo.

What to double-check

When a report looks wrong, begin with the simplest explanations. Confirm the date range, timezone, comparison settings, filters, segments, attribution model, and data freshness. Check whether the report uses event count, users, sessions, or active users; similar labels can answer different questions.

Then inspect implementation details:

• Is the event name exactly what the report expects?
• Are parameters registered or otherwise available for the analysis being attempted?
• Did a recent release alter button selectors, data layer keys, form behavior, or checkout redirects?
• Are browser consent settings, ad blockers, content security policies, or network failures affecting collection?
• Are both a hardcoded tag and a Google Tag Manager tag sending the same event?
• Are server-side and browser-side implementations using compatible event IDs or deduplication logic?
• Are cross-domain links preserving the intended session and campaign context?

Separate collection problems from reporting problems. If the request is absent in the browser, investigate the implementation. If the request is present but the report is empty, investigate processing, configuration, dimensions, filters, and timing. This distinction makes “GA4 not working” a testable problem rather than a general diagnosis.

Common mistakes

Auditing only the homepage. Tracking often fails on templates, logged-in areas, checkout steps, or confirmation pages that use different code paths.

Testing only the happy path. Add invalid forms, cancelled payments, consent changes, slow network conditions, repeated clicks, and page refreshes to the test set.

Changing production tags without a record. Use a documented workspace, review changes, and retain a clear publish history. The tag management governance checklist can help structure those controls.

Counting every event as a conversion. Keep business outcomes separate from diagnostic interactions so reports remain interpretable.

Comparing systems without comparing definitions. Write down what each platform counts, when it counts it, and which users or transactions it excludes.

Ignoring documentation. An undocumented fix can become the next unexplained discrepancy. Record the issue, root cause, change, test evidence, and owner.

When to revisit

Run a focused analytics audit after any release that changes navigation, forms, checkout, consent management, domains, tag management, or data layer variables. Also review tracking before seasonal planning, a major campaign, a site migration, a CRM integration, or a change to conversion definitions.

For routine maintenance, schedule a lightweight monthly or quarterly review based on the importance and complexity of the property. A lightweight review can check data volume, key conversions, campaign parameters, and recent implementation changes. A deeper review should repeat the scenario checklist and include browser tests across important journeys.

Finish each audit with three outputs: a list of confirmed working checks, prioritized defects, and a date or trigger for the next review. Fix issues that affect business decisions first, such as missing purchases or lead submissions, then address naming, documentation, and lower-priority reporting improvements. Reusing the same checklist makes changes easier to compare and gives your team a practical baseline for reliable GA4 setup and reporting.