GA4 Debugging Guide: 10 Common Issues and How to Fix Them

GA4 is working until it is not. The tag looks installed, the reports show numbers, everything seems fine. Then someone asks why last Tuesday's sessions are half what they usually are, or why the form submission event stopped firing, or why the source/medium report shows "(not set)" for 30% of traffic. And you realize the data has been wrong for weeks.

These are the ten issues that come up most often across analytics accounts. Each one includes what it looks like in the data, what causes it, and how to fix it.

1. Duplicate events inflating conversion counts

What it looks like: Form submissions are double what the CRM shows. DebugView shows two form_submit events when you submit one form.

What causes it: Two mechanisms firing the same event. The most common combination: GTM has a form submission tag AND enhanced measurement's form tracking is enabled. Both fire form_submit on every form interaction. Less common: two GTM containers on the same page, or the GA4 tag installed both through GTM and as a hardcoded script.

How to fix it: Pick one mechanism. If you use GTM for form tracking (because you need custom parameters), disable enhanced measurement's form tracking in the data stream settings. Then open DebugView, submit a test form, and count the events. You should see exactly one.

2. Missing conversion events after a CMS update

What it looks like: Form submissions in GA4 drop to zero overnight. The CRM still receives leads. The form works for visitors, but GA4 does not see it.

What causes it: The CMS update changed the form's HTML structure. Enhanced measurement detects forms by listening for the native form submit event. If the updated CMS renders differently — a JavaScript component without a native submit, or a new form builder with a different DOM structure — detection breaks. GTM triggers also break if they matched a specific form ID or class that changed.

How to fix it: Re-inspect the form's HTML and update the GTM trigger to match the new structure, or fire the GA4 event from the form's submission handler rather than from a DOM event.

3. "(not set)" flooding the source/medium report

What it looks like: A large percentage of sessions show source/medium as "(not set) / (not set)" or unexpected "(direct) / (none)" when you expected campaign attribution.

What causes it: Broken UTM parameters (misspelled names, malformed URLs, redirects stripping query parameters), Consent Mode blocking attribution, or cross-domain tracking not configured.

How to fix it: In Explore, add "Landing page" alongside source/medium. If campaign landing pages show (not set), the UTMs are broken. If they are cross-domain pages, configure cross-domain measurement.

4. Sessions do not match between GA4 and Google Ads

What it looks like: Google Ads reports 3,200 clicks. GA4 shows 2,400 sessions from google/cpc.

What causes it: Clicks and sessions are different metrics. The visitor's browser might block the GA4 tag, the page might not load before the visitor bounces, duplicate clicks create one session, or bot clicks inflate the Google Ads count. A 10 to 30 percent gap is normal. Over 40 percent warrants investigation. See our GA4 vs Google Ads discrepancy guide for details.

5. Engagement rate suddenly drops

What it looks like: Engagement rate falls from 55% to 35% over a week without site changes.

What causes it: Usually bot traffic. Bots generate zero-engagement sessions that dilute the metric. Less common: a tag change firing page_view on non-page-views.

How to fix it: Filter by city or source to locate the bot traffic. Exclude it at the CDN level or add a reporting filter.

6. Key events not appearing in Google Ads

What it looks like: GA4 shows 30 key events. Google Ads shows zero imported conversions.

What causes it: The conversion import is not configured, or it targets a different action. Verify the event is marked as a key event, then check Google Ads under Goals > Conversions to confirm the correct property is linked and the key event is imported as Primary. Imported conversions can take up to 24 hours to appear.

7. Revenue data showing as zero

What it looks like: Purchase events fire, but revenue is $0.00 in reports.

What causes it: The purchase event is missing the value parameter, or the value is sent as text instead of a number. GA4 requires value to be numeric and currency to be a valid ISO 4217 code.

How to fix it: In DebugView, inspect the purchase event's value and currency parameters. Fix the implementation to send a number, and add currency if missing.

8. User count is much higher than expected

What it looks like: GA4 shows far more users than the client believes they get, or the count is significantly higher than what Universal Analytics showed.

What causes it: In daily-grain data, "Users" is a daily active user count not deduplicated across days. Summing daily counts overcounts returning visitors. Compare against GA4's monthly "Users" figure in the standard report, which is deduplicated.

9. Page path data showing wrong URLs

What it looks like: The same page appears under multiple URL variants (/pricing, /pricing/, /pricing?utm_source=google).

What causes it: GA4 records full page paths including query parameters. Fix by cleaning page_location before sending. Fix trailing slash inconsistency at the server level with a 301 redirect.

10. Data stops flowing with no error

What it looks like: Reports show data through last Tuesday, then nothing. No error in GA4. The site is up.

What causes it: The GA4 tag was removed during a site redesign or CMS update. The data stream was deleted or modified. A new content security policy blocks the tag from loading. Or a Measurement Protocol secret was rotated (affects server-side events only).

How to fix it: Open the site with DebugView enabled. If no events appear, the tag is not firing. Check the HTML source for the tag. Check the browser console for errors. Check the network tab for blocked requests to Google's domains.

The debugging mindset

These ten issues share a pattern: they are all silent failures. GA4 does not email you when the tag breaks. It does not warn when events are double-counted. It does not flag that revenue is zero because a parameter is the wrong type. The data just quietly goes wrong, and the first person to notice is usually the client, at the worst possible time.

The defense is verification. DebugView after every implementation change. A freshness check every day. A monthly audit of event counts, source/medium distributions, and conversion trends. The five minutes you spend checking saves the five hours you would spend debugging — and the trust you would lose explaining why the last three reports were based on wrong data.