GTM tag fired but no data in GA4? Where it stops

"Tag fired" in Tag Manager's preview means only that Tag Manager ran the tag. The data can still stop later: the request never leaves the browser, it is blocked or fails, it goes to another property, it was sent without consent, GA4 filters it out, or reports have not processed it yet. Check each in order.

Why does Tag Manager say the tag fired when GA4 shows nothing?

Preview mode runs the version in your workspace, in your browser, with debug mode on. Visitors get the published version, in their own browsers with their own blockers and consent choices, and their data goes into standard reports, not DebugView. A tag can fire for you in preview and never fire, or never arrive, for anyone else.

Unpublished changes: preview runs the workspace; the live site runs the last published version. Publish, then test the live site without preview.
Debug traffic: GTM's preview marks GA4 requests as debug traffic, which DebugView shows. If the property's developer-traffic filter is active, debug traffic is kept out of reports.

Step 1: does the GA4 request leave the browser?

Open the live site with preview off, in a clean browser profile, and open DevTools → Network with Preserve log ticked. Filter on collect and look for requests to a Google Analytics host, or to your own tagging server. GA4 can batch events, so wait a few seconds or switch tabs before deciding none went out.

Many ad blockers and strict tracking-protection modes block Google Analytics; test without them.
If a consent banner appears, the result depends on your Consent Mode setup: in the basic setup nothing is sent until the visitor accepts. See Step 4 for the advanced setup.
No request on one page but requests on others points to a template without the tag manager snippet; the hub guide covers checking every template.

Step 2: is the request blocked or failing?

A request that leaves the browser can still fail. In the network panel, look at its status: a request straight to Google Analytics normally answers with no content (status 204). A blocked request or a network error means the data never reached Google, however often the tag fired.

Server-side tagging: your own tagging server can answer the browser normally (often 200, not 204) even after it has stopped forwarding to Google. A good status there proves only that your server received the request; check the server container's preview or logs.

Step 3: is it going to the right property?

Open the request and read its tid parameter: that is the measurement ID, G- followed by letters and numbers. It must match the web data stream of the GA4 property you are looking at. A copied container, an old ID, or a second tag can send everything to a property nobody opens.

A 204 proves Google received the request, not that the ID belongs to a property you can see.
With server-side tagging, the server container can change the measurement ID, so the browser's tid is not necessarily where the data ends up; check the server container's GA4 tag.

Step 4: was it sent without consent, or filtered out?

With Consent Mode in the advanced setup, a visitor who declines still sends requests, and they get a 204. GA4 uses them only for modelling: they never appear as events in Realtime, DebugView or reports. So test after accepting cookies. Then check whether a GA4 data filter drops what arrives.

Data filters (Admin → Data collection and modification → Data filters): an active internal-traffic filter removes visits from the IP addresses you defined; an active developer-traffic filter removes debug traffic, including preview; a web-hostname filter set to include only some hostnames drops data from a new domain.
Debug mode left on: if your published Google tag or GA4 event tag sets debug_mode at all, even to false (which Google says does not turn it off), every visitor counts as debug traffic, and an active developer-traffic filter removes all of it. Delete the field.

Step 5: has GA4 processed it yet?

Realtime shows events within minutes; standard reports can take 24 to 48 hours, according to Google, and may change while processing. So test in Realtime or DebugView first, after accepting cookies. An event that appears there but not yet in standard reports is usually still processing; check again after 24 to 48 hours.

The data arrives, so why is the report still empty?

Sometimes the event is in GA4 but the report you opened looks for something else. Event names are case-sensitive, and custom parameters only appear in reports once registered. Check the event's exact name in DebugView and compare it with the report's filter or the conversion you set up.

Event names are case-sensitive: Purchase and purchase are different events, and a report built on one stays empty if the tag sends the other.
Custom parameters appear in standard reports only after you register them as custom dimensions or metrics, and only for data received after you register them (allow up to 48 hours). Realtime and DebugView show them before that.

What does TagAudit's scan show?

TagAudit's free scan does part of Step 1 from the outside. For each page type it samples from your sitemap, it shows which GA4 events fire on page load, after the scan accepts cookies, where it can. It lists the GA4 measurement IDs it found. It cannot show whether a request succeeded, or anything that happens inside GA4.

Per page type: for up to 12 page types from your sitemap, the "Page types we sampled" rows of the coverage matrix show the GA4 events each page tried to send when loaded after the scan accepts cookies, where it can, for example page_view. If other tools sent traffic but GA4 did not, the cell is labelled "No traffic from this tool". If the page sent no tracking at all, it is labelled "Opened, nothing captured". A ✓ means a request was attempted, not that it succeeded. These are load-time events only; the scan does not interact with sampled pages, and without a usable sitemap there are no rows.
Measurement IDs: the Detected stack's Google Analytics 4 row lists, under "ID / evidence", every G- measurement ID it found in the page source or in a request address, so an ID found only in the source is listed too. Compare them with your property. If it finds more than one GA4 ID on the page you enter, it reports "Multiple GA4 measurement IDs found: …".
Server-side tagging: if the tag manager or GA4 loads or sends from your own domain at the standard paths, the Detected stack lists "Server-side GTM / custom tagging endpoint". Custom loader paths may not be recognised.
Status is not a firing check: in the Detected stack, the Status column can read "active" for a tool found only in the page source. To see what the page tried to send, use the "Page types we sampled" rows, where your site has a sitemap.

What can't this tell you?

A check in your own browser shows what leaves the browser and how the server answers. It cannot see what GA4 did with the data after accepting it: modelling, filters, thresholds, processing or your report settings. Those need access to the GA4 property. TagAudit's scan shows what the page tries to send, not how the server answers.

TagAudit's limits for this question:
- It does not show whether each GA4 request succeeded or failed, so Step 2 is a by-hand check.
- It does not connect to your GA4 property.
- It sees the version of the tag manager that the live site serves to visitors, not your workspace or preview.
- It does not read the debug-mode flag.
Not legal advice: a report is not a compliance certificate.

→ Check what your site sends