GA4 audit checklist: what to check and how to verify it

A GA4 audit answers one question: can the team make decisions on these numbers? Check it in six areas, in this order: the decisions the data feeds, collection, property configuration, consent, the reconciliation against your own systems, and what keeps it from breaking again.

Each check below says what to look at, how to verify it, and the red flag that means the number is wrong. It works for a one-off Google Analytics audit and as the baseline for a recurring one.

Why GA4 setups drift

GA4 is rarely wrong on the day it is implemented. It drifts afterwards, through ordinary work:

• Site releases change the data layer, rename a button or move the checkout, and an event stops firing or fires twice.
• Marketing launches campaigns with new UTMs, new landing pages and new payment or booking tools, and sources turn into "(not set)" or self-referrals.
• Consent banners get updated by legal, and the consent state stops reaching the tags.
• Defaults stay untouched: the retention period, the key events someone marked in a hurry, the parameters nobody registered.

None of these shows up as an error in the GA4 interface. The reports keep filling in, just with the wrong numbers. That is why an audit starts from the decisions, not from the admin screens.

1. Start from the decisions the data feeds

List the five to ten numbers that someone uses to decide something: revenue by channel, cost per lead, conversion rate by landing page, funnel drop-off. For each one, write down the event, the parameters and the report it comes from.

• How to verify: each decision maps to a documented event in your tracking plan or solution design document.
• Red flag: a number in the monthly deck that no one can trace to an event.

This list is the audit's scope. A check that doesn't protect one of these numbers goes to the end of the queue.

2. Collection: are the events right?

• The Google tag loads once per page. Two tags (one hard-coded, one in Google Tag Manager) double every event. Check the network requests on a few page types.
• The purchase event is complete. Google's event reference requires transaction_id and items, and says currency is required whenever you send value. Without currency, revenue isn't computed accurately.
• Each order is counted once. transaction_id is what lets GA4 avoid duplicate purchase events. It has to be your real order ID, not a timestamp or a fixed value. Count purchases per transaction_id in BigQuery: more than one is a duplicate.
• Enhanced measurement doesn't duplicate custom events. Automatic form or scroll events next to your own versions of them inflate counts.
• Sources make sense. A large share of "(not set)" or "Unassigned" traffic, or your own domain and payment providers appearing as referrers, points to missing UTMs, broken cross-domain setup, or a missing entry in the stream's list of unwanted referrals.
• Parameters are filled the same way everywhere. The same event has to carry the same parameters, with the same values, on every page and in every flow: page type, product category, identifiers. Compare the values of each parameter by page type and by platform; a category that is filled on product pages but empty in search results is a typical break.
• No personal data in URLs or parameters. Email addresses in query strings or in custom parameters go against Google's rules on personal data and your own privacy commitments.

The issue I find most often is exactly that inconsistency: the properties that travel with an event, such as page type, product category or identifiers, are filled at different moments or in different ways depending on the page. If the number isn't reviewed daily, it takes weeks to detect. Usually it surfaces when business stakeholders notice that the data doesn't add up.

To dig into a failing event, see how to debug analytics problems.

3. Configuration: does the property count what you think?

• Data retention. Standard properties retain user-level and event data for 2 or 14 months. The setting affects explorations and funnel reports, not standard aggregated reports. Red flag: a team that runs year-over-year explorations on a property set to 2 months.
• Key events. A standard property allows up to 30 key events. Check that each one is an outcome a decision depends on, not a page view someone marked to make a report look better.
• Custom definitions. A parameter you send isn't in standard reports until it is registered. The limits are 50 event-scoped and 25 user-scoped custom dimensions on standard properties. Red flag: parameters in the data layer that no report can show.
• Internal and developer traffic. The internal traffic filter is defined and active, not left in testing.
• Basics that skew every report: reporting time zone and currency, links to Google Ads and Search Console, and the attribution model and look-back windows in the property's attribution settings.

4. Consent: what you collect and what you model

• Consent Mode is implemented, with the four signals analytics_storage, ad_storage, ad_user_data and ad_personalization set from your consent platform before any Google tag fires.
• The mode is a decision, not an accident. In basic mode, Google tags don't load before consent. In advanced mode, they send cookieless pings when consent is denied, which GA4 and Google Ads use for modeling. Know which one you run and why.
• It works in practice. Accept and decline on your own site, in each region you serve, and check what each tag sends. How to verify Consent Mode v2 has the steps.

Red flag: tags firing with full identifiers before the user has chosen.

5. Reconcile against your own systems

GA4 will never match your order system exactly. Ad blockers, declined consent and browser limits mean some sessions are never measured. The audit has to know how large the gap is and whether it is stable.

• Compare purchases and revenue by day with the backend for the last 90 days. A stable gap is a known limit; a gap that jumps on a given date is a broken release.
• Compare the GA4 interface with the BigQuery export for the same events. Standard properties have a daily export limit of 1 million events; past it, the daily export can be paused.
• Agree the tolerance in writing, with finance and marketing, so a discrepancy triggers an investigation instead of a debate.

In my experience, a gap of around 10% is unavoidable: technical limits, ad blockers and users who decline tracking. Depending on the industry, it can reach 30%. Within that range, what matters is that the gap is stable.

6. Make the audit stick

An audit is a snapshot. The property starts drifting again with the next release. Three things keep it honest:

1. A tracking plan that changes before the code does. Every new event or parameter is specified first.
2. QA before each release on the events in your decision list from step 1, with an owner who signs off.
3. Monitoring in production, so a broken event shows up in hours, not at the next quarterly review. The options, from browser extensions to continuous monitoring, are compared in GA4 audit and error-detection tools.

The checklist on one page

When a checklist isn't enough

• No decisions depend on GA4. If the business reports from the backend or a warehouse model, audit those first and treat GA4 as a secondary source.
• The data layer is the problem. If events are wrong at the source, fixing GA4 settings changes nothing. Start from the data layer and the tracking plan.

What to check this week

• Write the decision list from step 1 and check that every item maps to an event.
• Count purchases per transaction_id for the last 30 days. Any order counted twice is the first fix.
• Check the data retention setting before someone builds a year-over-year exploration on 2 months of data.