GA4 Audit Checklist: 12 Checks for Reliable Tracking

A GA4 audit checklist helps you answer a practical question: can you trust the tracking behind your next marketing decision? Start with one real customer journey, then inspect the settings and events that describe it. A healthy-looking dashboard is not enough. You need evidence that a successful enquiry or purchase reaches the right property once, with useful information attached.

This checklist is for a website-focused audit, whether you manage a small business site or oversee several marketing accounts. It covers collection, business actions, attribution and reporting limits. It is a working procedure, not a claim that every website needs every Google Analytics feature. Record what you tested, what failed and who will fix it.

Prepare your GA4 audit checklist before changing settings

Collect read access to the correct Analytics property, the website's tagging setup and any system that records completed enquiries or orders. Ask for change permissions only where needed. Record the property name, web stream, measurement ID, reporting time zone and currency. Confirm which production domains belong in scope and keep staging sites separate in your notes.

Next, write down the decisions the account must support. A service business might need to compare qualified consultation requests by campaign. A shop might need to understand completed orders. Those are different audit priorities. A click on a contact button can be useful, but it is not proof that somebody submitted a valid enquiry.

If the installation itself is unfamiliar, our GA4 setup guide for small businesses explains the starting point. This audit goes further: it asks whether the collected data matches the behavior you intended to measure.

GA4 audit checklist: 12 checks and the evidence to save

Copy this table into your working document. Use Pass, Fail, Not tested or Not applicable for each row. An unchecked item is not a pass. The evidence column should contain a dated screenshot, test note or record reference, without customer personal information.

1. Inspect how the website sends events

List every route that can install tracking: the theme, a CMS plugin, a tag manager container and any custom application code. Do not remove a route just because you found another one. First establish which destination and events each route sends. Two installation routes are a reason to investigate, not automatic proof of duplicate collection.

Test the homepage, a landing page and a page involved in the main conversion journey. Include a mobile visit. On a site that changes content without a full reload, also test movement between screens and the browser's back button. Write down the event sequence you expect before comparing it with the sequence you observe.

Google's DebugView documentation explains how to inspect events and their parameters after enabling debug mode. Tag Assistant or tag manager preview can enable debugging for your own device. Select that device in DebugView so you do not mistake somebody else's activity for your test.

For each test, note the action, event name and destination. If one page load appears to produce two matching events, trace both sends before making a change. Check whether a plugin and custom tag cover the same action. After a fix, repeat the original test and one adjacent journey to catch an unintended side effect.

2. Test successful and unsuccessful business actions

Make a short measurement plan for each important action. Specify the business definition, trigger, event name, expected count and owner. For a lead form, a sensible definition might be a submission accepted by the form system. A button press alone would not satisfy that definition.

Run a successful submission with clearly identified test data. Then test a validation error and a repeat visit to the confirmation page. If the system allows it, test a second genuine submission too. The purpose is to distinguish new outcomes from repeat displays of the same outcome. Keep test records separate from customer records and tell the operational owner what you created.

For a store, include a controlled test purchase using the store's approved testing procedure. Compare the event details with that test order and inspect repeat confirmation-page visits. Treat any specific ecommerce implementation repair as a developer task against Google's current ecommerce documentation. This general checklist does not replace the implementation specification.

Record failures in plain language. "Enquiry event fires when the form rejects an empty required field" tells a developer what to reproduce. "Conversions look wrong" does not. Save enough detail for another person to repeat the test without exposing customer information.

3. Review key events and the meaning of each count

In GA4, marking an event as a key event identifies an interaction that matters to the business. Google says you must first create or identify the event, then mark it. Review the current list against your measurement plan rather than marking every interaction as important.

Inspect the event's counting method and any default value. Ask whether the choice matches the reporting question. A repeated interaction and a distinct customer outcome are not always equivalent. Write the intended meaning next to the setting so the next analyst does not have to guess.

According to Google's key event guide, marking an event affects reports from that point forward; it does not rewrite historical data. Google also says to allow up to 24 hours for a newly marked key event to appear in standard reports. Do not declare the repair unsuccessful solely because a standard report has not updated immediately.

If Google Ads is linked, review which Analytics-based conversions are actually used in the advertising account. The audit should record the connection and its purpose. Do not assume that a key event setting alone proves the campaign's bidding configuration is correct.

4. Check consent behavior and traffic filters carefully

Document the site's intended consent behavior with the person responsible for privacy requirements. Test a fresh visit, each available choice and a changed choice. Record the browser, device and results. Do not alter consent settings simply to make an Analytics total agree with a sales total. This technical audit is not a legal compliance assessment.

Debugging has limits here. Google notes that events may not be visible in DebugView when client-side privacy controls apply or when consent mode is implemented and Analytics-cookie consent has not been given. Investigate the consent state before concluding that an absent debugging event proves a broken tag.

Review internal, developer and any hostname traffic filters present in the property. Google's data filter guidance says filters apply forward, not to historical data. Excluded data is never processed and cannot later be recovered from Analytics or BigQuery. Inspect the rule and test the intended behavior before activating an exclusion; do not experiment with a broad production rule.

As an audit precaution, inspect URLs and event parameters for names, email addresses or other personal details. Ask the implementation owner to resolve any exposure through the appropriate privacy process. Save redacted evidence, not another copy of the sensitive value.

5. Follow campaign links and off-site journeys

Choose one active email link and one paid campaign link, where applicable. Record the intended source, medium and campaign before visiting. Check redirects and the landing page, then inspect the relevant acquisition reporting after processing. Use the same date window and reporting question when comparing results.

Google's Analytics configuration checklist recommends campaign URLs for non-Google sources and says Google Ads campaigns work best with auto-tagging. Record the actual tagging method in use. A naming standard is useful only when everyone who creates links follows it.

Trace journeys that leave the main website for a checkout, booking tool or another business domain. Google's checklist identifies cross-domain measurement as a configuration to consider when a business has more than one domain. It separately identifies unwanted referral settings for sources such as external payment processors. These settings address different questions; do not treat a referral exclusion as proof that the complete journey is measured correctly.

If you cannot access a third-party checkout or booking configuration, mark that step Not tested and assign an owner. Do not invent continuity from an attractive acquisition report. A documented gap is more useful than a false pass.

6. Check retention, integrations and reporting differences

Review retention against the analyses the team needs and the organization's approved data policy. Google's retention documentation lists 2-month and 14-month options for standard property event data, with additional qualifications and limits described on that page. Avoid changing the setting without checking the property's actual options.

The distinction matters: Google says this retention setting affects explorations and funnel reports, not standard aggregated reports. Increasing retention applies to collected data that has not already been deleted. It does not bring deleted data back. Record the current setting and any resulting reporting limitation in your handoff.

Inventory relevant product links and exports. Check that each connection is intentional, points to the correct account and has an owner. Google's configuration checklist covers links such as Search Console and Google Ads. You do not need to enable every integration to finish an audit.

Finally, compare a small, documented test set with the corresponding form or order records. Note time zones, date ranges, consent conditions and event definitions before comparing totals. Do not demand identical customer-system and Analytics totals without considering those differences. Once the measurement is understood, choose a suitable layout from our marketing dashboard examples for the decisions the team needs to make.

Turn the audit into a repair plan

For every failure, save the symptom, reproduction steps, evidence, business consequence, assigned owner and acceptance test. Prioritize broken outcome tracking and unintended data collection before cosmetic report changes. Make one controlled change at a time, keep the previous configuration available and retest the affected journey.

For example, a fictional audit finding might read: "The enquiry event fires on a rejected submission. The website developer will change the trigger. Acceptance: one accepted test submission produces one intended event; the rejected submission produces none." This is an illustrative test specification, not a result from an Aslan client account.

Repeat the relevant checks after a website release, checkout change or consent implementation update. Set a review cadence that fits how often the site changes. Close the audit only when each unresolved issue has a named owner and a clear reporting limitation. That gives the next marketing decision an honest foundation.