GA4 problems don't always announce themselves. Sometimes the break is obvious — conversions disappear overnight, traffic drops by 40%, revenue stops recording. Those are the easy ones to catch because there's a clear before and after.
The harder ones are the slow leaks. Data that gradually degrades over weeks or months until someone looks at a trend line and realises the numbers have been quietly wrong for a long time. No obvious trigger. No changelog entry. Just a creeping divergence from reality that nobody noticed until it mattered.
Both types of problem respond to the same diagnostic process. The difference is how quickly the cause reveals itself.
Recognising the Symptoms
Before you can diagnose a problem you need to recognise that one exists. These are the most common presenting symptoms that send teams into troubleshooting mode:
- Sudden traffic drop — sessions or users fall sharply in a way that doesn't match known seasonal patterns or campaign changes
- Conversion events disappeared — a key conversion event stops recording, partially or completely
- Revenue mismatch — GA4 revenue doesn't reconcile with your payment processor, your CRM, or your internal sales data
- Ad platform disagreement — GA4 and Google Ads or Meta are reporting significantly different conversion numbers for the same period
- Unassigned traffic spike — a sudden increase in sessions attributed to the Unassigned channel, suggesting UTM or attribution breakdown
- Engagement rate change — a sharp drop in engagement rate often indicates bot traffic, a filter change, or a duplicate stream issue
- Numbers that just feel wrong — experienced analysts develop a sense for when data doesn't match what the business is actually doing, even without a specific anomaly to point to
The slow leak version of any of these is harder to catch — gradual revenue underreporting, slowly increasing unassigned traffic, conversion rates that drift downward without a clear break point. These often surface in quarterly reviews rather than daily monitoring, which means the problem has been running for weeks or months before anyone investigates.
Step 1: Quarantine the Problem Data
The first move is always to isolate exactly what is and isn't affected. Don't try to diagnose the whole property at once — narrow down to the specific data that looks wrong.
Start with these questions:
- Is it a specific event, or all events?
- Is it a specific page or section of the site, or the whole property?
- Is it traffic volume, conversion recording, or reported revenue?
- When exactly did it start — can you identify a date or a window?
- Is it affecting all users or a subset?
The more precisely you can define the problem, the faster the diagnosis goes. "Conversions are down" is hard to investigate. "Purchase event firing rate dropped by 60% on mobile starting April 7th" gives you something to work with.
Step 2: Segment to Find the Pattern
Once you've isolated what's affected, the next step is segmenting the data to find where the problem is concentrated. A problem that affects all devices equally points to something different than a problem that only shows up on mobile. A drop that's limited to one traffic source is a different investigation than a drop across all channels.
Work through these dimensions systematically:
- Device category — desktop, mobile, tablet. Is the problem isolated to one device type?
- Region / country — is it limited to a specific geography? This can indicate a consent issue, a localisation problem, or a regional campaign change
- Traffic source / medium — is it affecting all channels or specific ones? A paid search drop while organic stays stable points to campaign or tracking changes
- New vs. returning users — if only new users are affected, the issue is likely in acquisition tracking. If only returning users, it may be in session handling or cookie behaviour
- Landing page — is the problem concentrated on specific entry points? A template change or tag deployment on a particular page type often shows up here
The goal is to build a profile of the affected data. What does the broken segment look like? What does the unaffected segment look like? The contrast between them usually points toward the cause.
Step 3: Correlate with the Changelog
Once you have a profile of the problem — what's affected, when it started, which segments — the next step is correlating that with any changes that happened around the same time.
Changes that commonly cause GA4 problems:
- Site deployments or CMS updates
- GTM container changes — new tags, modified triggers, updated variables
- Campaign launches or changes in ad spend and strategy
- Consent management platform updates
- Third-party integrations — new payment processors, checkout changes, CRM connections
- Domain or subdomain changes
- Developer changes to the data layer
The problem is that most teams don't have a reliable changelog. Development deploys happen without analytics sign-off. GTM changes are made without documentation. Campaign changes aren't communicated to the analytics team.
Step 4: Investigate GTM
GTM is where most GA4 problems originate. Tags fire incorrectly, triggers get misconfigured, variables stop returning the right values. And because GTM changes are often made by multiple people — marketers, developers, agencies — without a formal review process, the container accumulates changes that nobody fully owns.
In GTM, look for:
- Tags modified around the time the problem started
- New tags that may be interfering with existing ones
- Trigger changes that may have narrowed or expanded when a tag fires
- Variable changes that may be affecting event parameters
- Tags that were paused or have firing rules that exclude certain conditions
Use GTM's preview mode to test the specific user journey where the problem is occurring. Watch the tag firing sequence in real time. If a conversion tag that should fire on your confirmation page isn't appearing in the tag firing list, you've found your problem.
If the GTM investigation doesn't surface anything, the issue may be upstream — in the data layer, in a site deployment, or in a consent configuration that's blocking tags from firing for certain users.
Common Causes by Symptom
After running this process across hundreds of GA4 properties, certain symptom-cause patterns emerge consistently:
| Symptom | Most Likely Causes | Where to Look |
|---|---|---|
| Conversion event stopped firing | GTM trigger change, data layer change, site deployment broke tag | GTM preview mode on the conversion page |
| Revenue underreporting vs payment processor | Payment processor referral exclusion missing, duplicate transaction IDs, currency mismatch | Referral exclusion list, purchase event parameters |
| Traffic drop on specific channel | Campaign paused, UTM parameters changed or missing, landing page issue | Campaign settings, UTM consistency report |
| Unassigned traffic spike | UTM parameters missing from campaign URLs, referral exclusion gap, dark social | Source/medium report, UTM audit |
| GA4 vs ad platform conversion discrepancy | Attribution model difference, conversion window mismatch, duplicate conversion counting | Attribution settings, ad platform conversion setup |
| Mobile-only drop | Consent mode blocking tags on mobile, page not mobile optimised, mobile-specific tag issue | Consent mode implementation, GTM preview on mobile |
| Slow revenue/conversion drift | Gradual consent rate decline, accumulating UTM inconsistency, slow data layer degradation | Consent signal trends, UTM consistency over time |
The Underlying Problem: No Baseline
The reason GA4 troubleshooting is hard isn't that the problems are technically complex — most of them aren't. It's that most properties have no established baseline to compare against.
If you don't know what your conversion rate normally is, you can't tell when it's drifted. If you don't know what your typical engagement rate looks like, a drop is invisible until it's severe. If you've never verified that your purchase event fires correctly, you won't notice when it stops.
The best time to establish that baseline is before a problem occurs — which is the argument for running a regular data health check rather than waiting until something looks wrong. A quarterly audit catches slow leaks before they become significant. It also creates the documentation that makes troubleshooting faster when something does break.
When to Run a Full Audit
If the troubleshooting process leads you to a specific broken tag or misconfigured setting, fixing it is straightforward. But if the investigation reveals that the property has multiple overlapping issues — or if the data has been unreliable long enough that you're not sure what baseline you're even comparing against — a full audit is the right next step.
A full GA4 audit doesn't just find the thing that's currently broken. It gives you a complete picture of everything that's misconfigured, so you're fixing the actual state of the property rather than patching individual symptoms.
