GA4 Audit Checklist: 11 Common Setup Mistakes to Fix in 2026

Most GA4 properties run without breaking: the numbers move, the reports load, everything looks fine. And yet they lie. Internal traffic inflates sessions, the default two-month retention quietly truncates your explorations, and fake key events let a scroll pass for a conversion. A real GA4 audit doesn’t check whether the tool works, it checks whether you can trust its numbers. Here is a GA4 audit checklist in 11 points, ordered by impact, with the symptom, the exact place to look in the Admin, and the fix for each configuration mistake. In one hour, you’ll know whether your data holds up.

This article covers the property configuration layer: the GA4 settings inside Admin. If your problems come from the collection code instead (events firing twice, parameters misnamed at the source), start with our guide on the 7 data layer mistakes that distort your data. And if you’re starting from scratch, the natural counterpart to this audit is our guide to setting up GA4 from scratch.

How to audit fast: 3 habits before the checklist

Before you open any settings, arm yourself with three tools built into GA4. DebugView (Admin → DebugView) shows the events from a test device in real time: it’s your microscope to confirm an event fires, once, with the right parameters. The Realtime report confirms that an action triggers what you think it does. Finally, comparing against an external source (your back office, your CRM, your payment platform) stays the ultimate referee: if GA4 counts 100 orders and your back office counts 130, you have a leak to find. Keep these three habits within reach, because they validate every fix below.

The priority table: which mistake to fix first

The eleven points don’t carry the same weight. This table ranks the mistakes by business impact so you know what to tackle first.

1. Data retention is still set to 2 months

Symptom. Your explorations won’t go back beyond eight weeks. Any cohort, seasonality, or year-over-year analysis hits an invisible wall. This is the single most common mistake, because the default setting traps everyone.

Where to check. Admin → Data Settings → Data Retention.

Fix. Change event-data retention from 2 months to 14 months, then save. The change is not retroactive: data already deleted is gone, which is exactly why you fix this on day one. Note that this setting only affects explorations; standard aggregated reports remain available for longer.

2. Internal traffic is not filtered

Symptom. Your sessions are inflated by your own team, your developers, and your contractors. Conversion rate looks low because dozens of internal visits will never convert, and your staging pages pollute the reports.

Where to check. Admin → Data Streams → your web stream → Configure tag settings → Define internal traffic. Then Admin → Data Settings → Data Filters.

Fix. First define an internal traffic rule based on your IP addresses (the traffic_type parameter takes the value internal), including your agencies’ and consultants’ IPs. Then create the matching data filter. Crucial point: a newly created filter starts in “Testing” mode, not “Active”. Until you switch it to Active, it excludes nothing. Also enable the “Developer traffic” filter, which excludes hits sent in GTM preview mode. Check the state of both filters, because this is the classic oversight that cancels all the work.

3. Key events don’t reflect your real goals

Symptom. Your “conversions” count page_view, scroll, or worthless clicks, while your real business outcomes (quotes, purchases, bookings) never show up. Your decisions then rest on numbers that measure nothing useful.

Where to check. Admin → Events (or Key events) → the “Mark as key event” column.

Fix. Clean house. Keep as key events only the actions with real value to the business. Remember that every key event feeds the key event rate (the former conversion rate) and the Advertising reports: one event marked by mistake skews both metrics. Turn off navigation events marked by habit or by default. A healthy account usually has a handful of key events, not twenty. Fewer, but right.

4. An event exists but isn’t marked as a key event

Symptom. You can see your generate_lead event in the events list, but the key events report shows zero. The data is collected, it’s simply never counted as a conversion.

Where to check. Admin → Events → the “Mark as key event” toggle next to the event.

Fix. Flip the toggle on the right event. If the event isn’t in the list yet (it has to have fired at least once), create it manually or trigger it in test mode, then confirm in DebugView that it arrives before enabling it. Then wait a few hours: it isn’t counted instantly.

5. Your conversions are counted twice

Symptom. Your conversion count exceeds reality. The same lead is counted twice because a form_submit event and a custom lead event fire together, or because an e-commerce platform fires the purchase event on every reload of the confirmation page. Your ROAS looks better than it is.

Where to check. Admin → Events to spot redundant pairs, and DebugView to watch a real journey end to end.

Fix. Keep a single event per real conversion. For purchases, lean on transaction_id: GA4 deduplicates transactions that share the same ID, provided it is actually sent. The root cause often lives in the collection layer; to tackle it upstream, see the detailed deduplication walkthrough in our guide to data layer mistakes.

6. Your events don’t follow standard naming

Symptom. Your native e-commerce reports stay empty even though you’re sending the data. The cause: custom naming like addToCart or CheckoutDone instead of the names GA4 expects. The tool doesn’t recognize your events, so it never wires them into its out-of-the-box reports.

Where to check. Admin → Events, and DebugView to read the exact names coming in.

Fix. Adopt snake_case and Google’s recommended event names (add_to_cart, begin_checkout, purchase, generate_lead). Aligning the naming unlocks the native reports with no other change. For the full naming conventions at the source, our collection-layer article is the reference again.

7. Your custom parameters aren’t registered as custom definitions

Symptom. You send a useful parameter (say payment_method or item_category), it’s clearly in the stream, but you can’t find it as a dimension in your reports or explorations. The data exists, it’s just invisible on the analysis side.

Where to check. Admin → Custom definitions → Custom dimensions (and Custom metrics).

Fix. Register every parameter you want to use, making sure the dimension name matches the exact key sent in the hit. Mind the quota (the number of custom definitions is capped per property): register only what genuinely serves analysis, and prune abandoned definitions. Collection starts at registration, so prior data won’t be backfilled.

8. Cross-domain and referral exclusions are misconfigured

Symptom. A single user journey splits into several sessions the moment it crosses a subdomain or an external payment domain. You see your own site, or your payment provider, show up as a traffic source: that’s self-referral, and it steals credit from your real sources.

Where to check. Admin → Data Streams → your stream → Configure tag settings → Configure your domains (cross-domain) and List unwanted referrals.

Fix. Declare all your domains and subdomains in the cross-domain configuration so a session crosses the whole set without breaking. There’s no need to add your own domain to the unwanted referrals list; do add your payment providers, though. When a payment domain is hard to pin down (common with 3D Secure), override the page_referrer parameter on the confirmation page instead, to neutralize the false referrer. Once it’s clean, cross-check your sources with the GA4 Source Group dimension for a consolidated read of your channels.

9. Personal data (PII) lands in your reports

Symptom. You see email addresses, phone numbers, or customer IDs in your page URLs or event parameters. Beyond the noise in your reports, this is a genuine compliance risk: GA4 prohibits collecting personally identifying information.

Where to check. Reports → Engagement → Pages and screens (look for emails or ?email= in the paths), and your custom event parameters.

Fix. Cut the problem at the source: clean URLs before collection (strip sensitive parameters) and never send PII in an event parameter. Turn on email redaction at the web-stream level, which exists for exactly this. For what’s already been collected, use redactions and data filters to mask what can be masked. Prevention is better: review what your forms and redirects place in the URL.

10. Consent mode and Google Signals are misconfigured

Symptom. Your conversions and audiences collapse for no obvious reason, or conversely you keep collecting despite a consent refusal. The consent signal isn’t passed correctly, and GA4 models what’s missing badly.

Where to check. Admin → Data Settings → Data Collection (Google Signals), and the consent signal on the tag or CMP side.

Fix. Confirm your banner passes the consent states (analytics_storage, ad_storage) before the tags fire, and that the default mode matches your policy. This area moves fast and deserves dedicated treatment: follow our complete guide to Consent Mode v2 in GA4 to validate the chain end to end.

11. A share of your traffic falls into “Unassigned” or “(not set)”

Symptom. A whole block of your traffic lands in the “Unassigned” channel, sometimes as your first or second acquisition source. Dig in and you find either UTMs GA4 can’t classify, or a source/medium of (not set), meaning an origin that’s simply been lost. Either way, your budget decisions rest on a blind slice of traffic.

Where to check. Reports → Acquisition → Traffic acquisition: sit on the “Unassigned” row and add “Source / Medium” as a secondary dimension. Then Admin → Data Display → Reporting Identity.

Fix. There are two causes, so two remedies. First, mislabeled UTMs that don’t match the default channel group rules: align your naming (a standard utm_medium like cpc, email, organic_social) and, if needed, build a custom channel group to catch the stragglers. Second, the (not set) source, the lost origin, which often comes from Consent Mode combined with a “Blended” reporting identity: GA4 models sessions from non-consented hits that carry no source. Switch the reporting identity to “Device-based”, a retroactive change that keeps only the real data of consenting users. Finally, rule out two classic technical causes: Measurement Protocol hits not tied to an existing session, and missing session_start events. A session timeout that’s too short can also push a landing page into (not set).

The GA4 audit checklist to copy

Keep this list handy for your next audit, in priority order:

1. Data retention set to 14 months.
2. Internal traffic defined AND the “internal” and “developer” filters switched to “Active”.
3. Key events cleaned up: real business outcomes only.
4. Every conversion event correctly marked as a key event (verified in DebugView).
5. No duplicate conversions (transaction_id sent for purchases).
6. Events in snake_case with recommended names for native reports.
7. Useful parameters registered as custom definitions (quota watched).
8. Cross-domain declared and payment referrals handled.
9. No PII in URLs or event parameters.
10. Consent mode passed correctly and consistent with the banner.
11. “Unassigned” traffic under control: clean UTMs, “Device-based” reporting identity.

In short

A GA4 audit isn’t there to confirm the tool runs, it’s there to tell you whether you can decide based on its numbers. The most expensive mistakes are silent: internal traffic inflating sessions, a default retention truncating your analysis, conversions counted twice, or a quarter of your traffic lost to “Unassigned”. Work the checklist in order, from critical to secondary, validate every fix in DebugView and against an external source, and you’ll turn a property that “lies” into a reliable basis for decisions. To go further, connect this audit to your initial setup with our guide to setting up GA4 from scratch.