GA4 Not Tracking? UK Agencies Run These Five Checks in Five Minutes

Most GA4 not tracking problems are not GA4 problems at all. They come down to a tag that never fired, a consent banner blocking analytics_storage, or a filter someone forgot about in Admin. Open Realtime right now, visit your own site in an incognito window, and see if you show up. If you do, GA4 is working and the issue is somewhere in reporting or filtering, not collection.

TL;DR:

• Most GA4 tracking issues result from misconfigured tags, consent settings, or filters, not problems with GA4 itself, and can be identified within minutes through quick checks.
• Using Realtime and DebugView confirms whether hits reach Google’s servers and if event payloads are correct, making them essential tools during troubleshooting.
• Ensuring the measurement ID matches between GA4 admin and your site’s code, avoiding duplicate tags, and confirming GTM publish status can prevent common setup errors.
• Consent Mode misconfigurations or delayed consent signals often cause data drops, especially if the CMP is improperly configured or loads after GA4 tags, which can be fixed by reordering tags.
• Data thresholds and filtering, like Google Signals or internal traffic rules, often hide small segments, with solutions including switching to device-based identity or exporting raw data to BigQuery.

Priority checklist: five checks to run in the first five minutes

Before you touch code, run these five checks in order. Each one takes under a minute and rules out the most common causes fastest.

1. Open Realtime and DebugView. Load your site, click through a couple of pages, and watch for your own session. If nothing shows within 30 seconds, the problem sits upstream of GA4 entirely.
2. Verify your measurement ID and GTM publish state. Confirm the G-XXXXXXXX string in GA4’s Admin matches the one firing on the page, and check that your Google Tag Manager container has an actual live “Published” version rather than one sitting in Preview mode.
3. Test in a clean browser profile. Use incognito with no extensions installed. This removes ad blockers and stale cookies as variables in one move.
4. Inspect DevTools network requests. Filter for “collect” and check whether requests to google-analytics.com are firing and returning a success status.
5. Check your consent banner and any active GA4 filters. Accept cookies, then confirm analytics storage actually updates, and glance at Admin to see whether a data filter or internal traffic rule is quietly excluding you.

Run through these five and you will usually know within minutes whether you are dealing with a broken tag, a consent issue, or simply a filter hiding your own traffic from view. The complete troubleshooting checklist from Nice Looking Data backs up this ordering: routine, fastest-to-verify checks first, code changes last.

What do Realtime and DebugView actually prove?

Realtime tells you whether a hit reached Google’s servers in the last few minutes. DebugView goes further and shows you the actual event payload, including every parameter attached to it. Together they are the fastest way to prove whether GA4 tags are firing, and if you see your own visit in Realtime, the tag itself is working, which means the problem is very likely downstream in reporting or filters rather than in collection, according to Google’s own troubleshooting guidance.

To use DebugView properly, install the GA4 Debugger extension (or add ?gtm_debug=x to a GTM preview link), then browse your own site. You should see:

• A live feed of events as you trigger them, tagged with your device
• Each event’s parameters listed underneath, so you can confirm things like page_location or transaction_id are populated correctly
• Any duplicate or misfiring events appearing twice, which flags a tag configuration problem immediately

Here is the outcome that trips people up: your event shows up perfectly in DebugView, but it is nowhere in the standard reports 24 hours later. That is not a tracking failure. Standard reports run on a processing delay, often 24 to 48 hours for younger properties, so DebugView and Realtime are the only reliable read on “is this actually firing” during active debugging, while the standard reports catch up later, per Google’s Data API reporting guidance.

Pro Tip: Screenshot the DebugView session with a visible timestamp before you close the tab. If you end up escalating to a developer or an agency, that screenshot saves you from re-running the same test twice.

Is your measurement ID or GTM setup actually the problem?

Tag installation issues sound basic, which is exactly why they get missed. Go to GA4 Admin, open Data Streams, and copy the measurement ID shown there. Now view your site’s page source (or the GTM Preview panel) and confirm the exact same G-XXXXXXXX string is what fires on the page. A surprising number of “GA4 tracking code errors” come down to a staging ID left live on production, or a second GA4 property added months ago that nobody removed.

Duplicate tags are the next culprit. If your GA4 config tag fires twice, whether from a legacy hardcoded snippet plus a GTM tag, or two GTM tags with overlapping triggers, DebugView will show the same event firing back to back within milliseconds. That inflates your numbers rather than hiding them, but it is just as much a data integrity issue as missing data, and it is worth fixing at the same time you are auditing everything else.

Then there is the GTM publish trap. Making changes in the GTM workspace and testing them in Preview mode feels like the job is done, but Preview only shows what would happen if published. If you close the tab without clicking “Submit” and “Publish,” the live site keeps running whatever the previous version was doing. Check the container’s version history and confirm the version number live on your site matches what you think you built.

• Confirm the measurement ID on the page matches Admin exactly, with no trailing characters
• Search your page source for more than one instance of gtag( or a second GTM container snippet
• Open GTM’s version history and check the timestamp of the currently live version against your last edit
• Check that no custom event exceeds GA4’s parameter limits, since events with too many parameters or over-length values get silently stripped by Google’s own gtag.js constraints

Pro Tip: Keep a plain-text log of every GTM version number and its publish timestamp. When someone asks “did we change anything last Tuesday?” three weeks from now, you will actually know.

Why does GA4 miss data even after consent is accepted?

This is one of the most common causes of GA4 event tracking problems, and it is almost never obvious from the front end. Consent Mode v2 controls whether analytics_storage is granted or denied, and if your Consent Management Platform sends the wrong default, or sends the grant signal too late, GA4 may drop the hit entirely or record it as a cookieless ping with far less identifying detail.

Open DevTools console after accepting your cookie banner and look for a consent update call firing with analytics_storage: granted. If that call never fires, or fires with denied even after you clicked “Accept,” the CMP is misconfigured, not GA4. Analytics Mania’s breakdown of missing GA4 events flags Consent Mode issues as one of the most frequent causes of sudden reporting drops, alongside incorrect date ranges.

Common CMP misconfigurations worth checking:

• Default consent set to “denied” before the banner even loads, with no update call firing on acceptance
• The consent banner script loading after the GA4 tag, so early pageviews fire before any consent signal exists
• Region-based consent rules that accidentally apply EU defaults to UK or US visitors, or vice versa

If sequencing is the issue, the fix is usually reordering tags in GTM so consent defaults load first, before any measurement tag can fire. If you are working through your CMP setup from scratch, AMW Media’s guide to Consent Mode v2 walks through the implementation details properly. And if a meaningful share of your traffic sits behind consent walls regardless of how well it is configured, server-side tagging becomes worth considering, since it lets you apply consent decisions more consistently across first-party infrastructure rather than relying purely on client-side signals.

Are ad blockers or a security policy quietly blocking your tag?

There is a clear difference between “an extension is blocking this” and “your own security headers are blocking this,” and mixing the two up wastes hours.

Ad blocker symptoms usually look like: tracking works fine for you in a normal browser, but a chunk of your audience never shows up, and the drop correlates loosely with how tech-savvy your visitors are. Test this by opening a clean browser profile with zero extensions installed and confirming the tag fires normally there. If it does, blockers are your answer, and no amount of GTM tweaking fixes that from your side.

Content Security Policy (CSP) issues look different and hit everyone, not just blocker users. Open DevTools console and look for an error mentioning “Refused to connect” or “violates the following Content Security Policy directive,” typically pointing at google-analytics.com or googletagmanager.com. This happens when a security team tightens a site’s connect-src header without checking it against every third-party script the marketing team relies on.

• Test in incognito with all extensions disabled to isolate blocker-related loss
• Search DevTools console specifically for CSP violation errors, not just failed network requests
• Ask whoever manages security headers to add the required analytics domains to connect-src
• Treat server-side tagging as the pragmatic long-term fix once blocker-driven undercounting becomes a persistent, ongoing headache rather than a one-off puzzle

Pro Tip: If your CSP keeps getting tightened every time your security team runs an audit, that is worth a standing agreement rather than a repeated fire drill. Get analytics domains whitelisted permanently, once, rather than re-fighting the same fix every quarter.

Why do rows disappear even when tracking works fine?

If a metric shows an orange triangle icon, or a huge chunk of your traffic gets lumped into a row labelled “(other),” that is not GA4 not tracking. That is data thresholding, and it happens after collection, at the reporting stage, when GA4 decides a data slice is too small to display without risking user identification.

Thresholds are applied specifically to prevent identification of individual users, and Google Signals is one of the most common triggers for aggressive thresholding, because it layers in cross-device and demographic data that narrows audience slices further. Turn on Signals for richer remarketing audiences, and you often trade away visibility into smaller segments as the cost.

There are two practical fixes. Switching your reporting identity setting from “Blended” to device-based removes Google Signals from the identity calculation entirely, which tends to eliminate most thresholding immediately, though it also means you lose the cross-device modelling Signals was providing. The second option, exporting to BigQuery, gives you row-level, unthresholded data regardless of how the standard reports choose to aggregate it.

• Watch for the orange triangle icon next to any metric, which is GA4’s explicit flag that thresholding is active
• Check whether Google Signals is enabled under Admin before assuming your tag is broken
• Switch reporting identity to “Device-based” if losing some cross-device modelling is an acceptable trade for visibility
• Set up a BigQuery export early, even before you need it, so historical unthresholded data exists when you do

Disabling Signals entirely is acceptable if your business does not lean on Google’s audience-based remarketing features. If it does, the device-based reporting identity switch is usually the better middle ground.

How do you inspect collect requests properly?

Network-level checks give you the most concrete evidence of all, because they show you exactly what left the browser and what came back.

1. Open DevTools, go to the Network tab, and filter by typing “collect” into the filter box.
2. Reload the page and trigger the event you are debugging. You should see a request to google-analytics.com/g/collect or a similar path.
3. Click the request and check the status. A 200 or 204 response means the hit reached Google successfully. A failed, red, or “(blocked)” entry means something intercepted it before it left, whether that is an extension, a CSP rule, or a network-level block.
4. Cross-reference the request’s timestamp with what DebugView showed at the same moment. If the network request succeeded but DebugView shows nothing, the issue sits in how the event was structured, not whether it was sent.

If collect requests consistently fail across a meaningful share of sessions, whether from blockers, browser privacy features, or third-party cookie restrictions, that is the point where falling back to server-side tagging or the Measurement Protocol becomes the sensible move, since both route hits through infrastructure you control rather than relying purely on the browser to deliver them intact.

Does your single-page app actually send page_view events?

Single-page apps are a frequent, quiet cause of GA4 data not updating correctly, because GA4’s default page_view trigger fires once, on initial load, and never again. Every subsequent “page” a visitor sees inside a React, Vue, or Angular app is really just a URL change handled entirely in JavaScript, and GA4 has no automatic way of knowing that happened.

The fix is either sending a manual page_view event through gtag() or dataLayer.push() every time your router changes route, or configuring a History Change trigger in GTM that fires a page_view tag on each virtual navigation. Neither is complicated, but both require someone to actually set them up. This is one of the most common gaps AMW Media finds when auditing e-commerce sites built on modern JavaScript frameworks.

• Confirm whether your framework’s router fires any event on navigation that GTM can listen for
• Set up a History Change trigger in GTM if you rely on client-side routing rather than full page reloads
• Navigate through several routes yourself with DebugView open and count whether each one produces a matching page_view event

What GA4 admin settings can quietly hide your data?

Sometimes tracking is completely fine and the data is simply filtered out before it ever reaches your reports. GA4’s Admin panel has two settings worth checking every time someone says data “vanished”: Data Filters and Internal Traffic definitions, both under Admin > Data Settings.

Internal traffic rules exclude visits matching a defined IP range, usually your office or agency network, and they can run in either “Testing” mode, which tags but does not remove traffic, or “Active” mode, which strips it from reports entirely. If someone switched a filter from Testing to Active months ago and forgot, that explains a sudden and permanent-looking drop that has nothing to do with tags.

• Check Admin > Data Settings > Data Filters for anything set to “Active” rather than “Testing”
• Confirm the internal traffic IP ranges still match your current office or VPN setup, since IP addresses change more often than people update the filter
• Document any period affected by an incorrect filter so stakeholders understand why that stretch of data is incomplete, rather than assuming the whole property is broken

Reverting a filter does not retroactively restore missing data. The rows excluded while it was active are gone for good, which is exactly why this check belongs early in any audit rather than as an afterthought.

AMW Media’s five-step debugging routine

A well-structured GA4 audit process often follows a five-step order that helps resolve the overwhelming majority of cases without needing to touch a line of code first.

1. Realtime. Reproduce the visit and confirm whether anything shows up at all within the first minute.
2. DebugView. If Realtime shows something, drill into DebugView to check the event’s actual parameters and confirm nothing is malformed or duplicated.
3. GTM Preview. Connect Preview mode to see exactly which tags fired, which triggers activated them, and whether the live container version matches what Preview shows.
4. Network inspect. Filter DevTools for collect requests and confirm the hit left the browser and returned a successful status.
5. dataLayer / server-side fallback. If everything above checks out and data is still inconsistent, inspect the raw dataLayer object for structural issues, or consider whether server-side tagging is the more durable fix given the traffic profile.

At each step, capture the evidence: a screenshot with a visible timestamp, the GTM version number in play, and the specific network request or DebugView entry involved. That trail is what turns a vague “analytics is broken” complaint into something a developer can actually fix in one pass rather than five.

Pro Tip: Send the developer the screenshot and the version number in the same message. “Something’s wrong with analytics” gets deprioritised; “GTM version 47, published 14:32, event fires in DebugView but the network request returns blocked” gets fixed today.

If this routine turns up something beyond a quick fix, that is usually the point to bring in a proper audit rather than keep guessing, such as a comprehensive SEOAudit that includes technical checks alongside analytics and measurement.

A realistic take on how much data you should expect to lose

Some measurement loss is simply the cost of doing business online now, and pretending otherwise sets everyone up for disappointment. Consent requirements, ad blockers, and Google’s own privacy-driven thresholding all chip away at coverage, and no amount of tag hygiene reverses that entirely. What you can control is knowing exactly how much you are losing and why, rather than discovering a gap six months later during a board review.

Returning-user metrics and small audience segments take the biggest hit from thresholding, so if those numbers matter for your reporting, get device-based reporting identity or a BigQuery export sorted before you need it, not after. Server-side tagging earns its complexity once ad blockers or consent walls are consistently costing you a meaningful, ongoing slice of traffic, rather than as a first move for every minor discrepancy.

If you have run every check here and something still does not add up, that is usually the moment to get a second pair of eyes on the setup rather than keep second-guessing your own GTM container. Our Google Ads and Meta Ads management is priced as a flat monthly fee, from £599 and £299 a month, never a percentage of your advertising budget.

Amir

How AMW Media fixes GA4 tracking properly

Most of the fixes above cover the checks you can run yourself in an afternoon. When the problem turns out to be structural, a CMP fighting your tags, a GTM container left unattended, or ad blockers costing you a real chunk of conversion data, that is when a professional audit becomes valuable. Our Oxford page starts with a number, 157 leads at £4.59 each for Cotswold Gloss, because that is the only part of an agency page you can check.

AMW Media handles GA4 tag audits, Consent Mode and CMP integration, and server-side tagging builds for businesses that have outgrown “just check Realtime and hope.” An audit typically starts with the same five-step routine covered above, run properly across your actual traffic rather than a single test session, with every finding documented so your team (or ours) can act on it straight away. If tracking issues are also muddying your paid campaign data, it is worth pairing that audit with a look at how your PPC campaigns are attributing conversions, since broken analytics and broken ad tracking tend to arrive together. Get in touch through AMW Media’s contact page and we will tell you whether you need a full audit or just a couple of hours sorting the consent sequencing out.

Sources

For readers who want to go straight to the source material rather than take troubleshooting advice on faith, these are the references behind this checklist.

• Troubleshoot collections and tags, Google Analytics developers
• About data thresholds, Analytics Help
• Google Analytics 4 events not showing up in reports?, Analytics Mania
• GA4 not tracking? The complete troubleshooting checklist, Nice Looking Data

FAQ

Why has my Google Analytics stopped working?

It almost never stops working outright. The usual causes are a consent default blocking analytics_storage, a GTM container edited but never published, or a data filter switched to Active in Admin, all covered in the priority checklist above.

Why is GA4 so hard to use compared with Universal Analytics?

GA4’s event-based model and reporting delays (often 24 to 48 hours) feel opaque next to Universal Analytics’ simpler session model, and thresholding hides small segments that older Analytics never suppressed the same way.

Is Google Analytics 4 down right now?

Rarely, and a full outage affects everyone globally at once. If it is just your property, run Realtime and DebugView first, since an isolated problem almost always traces back to your own tag, consent setup, or filters rather than Google’s infrastructure.

Why did Google Maps or location tracking stop working, and is that related?

Location tracking failures on mobile are usually down to device-level permission settings or app-specific location access being revoked, which is a separate system from GA4’s web-based analytics_storage consent signal, though both stem from the same broader trend toward tighter privacy defaults.

How long should I wait before assuming GA4 data is lost?

Give standard reports 24 to 48 hours before treating a gap as real, since processing delays are normal. If Realtime and DebugView show nothing during that window, that is the signal something is actually broken rather than just processing.

Recommended

• Website optimisation checklist: your 2026 UK guide
• Best automation tools for digital marketing: 2026 UK guide
• Hiring an agency for email marketing: a UK SME guide
• Top 3 Ppc Agencies London Agencies 2026