Inspect every GA4 collect request a page sends

The DevTools check, automated

The classic way to confirm GA4 tracking is to open DevTools, go to the Network tab, filter for "collect" and read each request. The Network Requests Inspector does exactly that for every page you give it. It opens each URL in Microsoft Edge like a normal visitor and records every GA4 collect request the page actually sends, with its status and timing. It is read-only.

It uses a normal Edge user-agent rather than a "headless" one, because many containers deliberately exclude headless browser traffic, and a test that is excluded proves nothing.

Client-side and server-side hits

A hit is recognised as a GA4 collect request whether it goes straight to a Google host or to the brand's own domain through server-side GTM or GA4's first-party mode. Requests are matched by their GA4 signature, not only by domain, so first-party endpoints aren't missed.

Headers and payload, in full

Open a request to see everything DevTools would show: the request URL and method, status, remote address, the full request and response headers (cookies included), the query string and the raw payload. The initiator shows how the request was sent; a beacon is typical for hits fired as the page unloads.

One request, several events

gtag.js batches events: one request can carry a page_view, a form_start and a scroll event at once. The inspector splits the payload into its individual events, one per line, each with its own parameters. Parameter order and duplicates are kept exactly as sent. Custom parameters keep GA4's own prefixes: ep. for text values and epn. for numbers.

Read the payload like a debugger

Every key in the payload is shown with a short plain-language label beside it, so tid reads as Measurement ID and gcd as the encoded consent mode. You don't need to memorise GA4's wire format. When a hit looks wrong, these are the keys to read first:

• tid: the Measurement ID. In a multi-brand setup, a container copied from another brand often still sends to the original brand's property. The hit is delivered, to the wrong place.
• en: the event name, exactly as the spec defines it. generate_lead and Generate_Lead are two different events in GA4.
• cid and sid: the client and session ids. If they change between hits on the same page, something is resetting cookies.
• dl: the page location. Check that campaign parameters survive any redirect.
• gcd and gcs: the consent state the hit carries. A hit that says analytics storage was denied won't set or read cookies, and GA4 treats it differently.
• ep. and epn.: event parameters as text or as a number. A value or price sent as ep.value is text, and GA4 won't sum it.
• _dbg: debug mode. Useful in testing; on production it sends real visitors' hits to DebugView.

Server-side proxies and service workers

With GA4's first-party mode, or some server-side proxies, a service worker on the brand's domain can answer the browser's hit and forward it on. The row you see first is then the browser-to-worker leg, and it's marked as answered by a service worker. The worker's own onward request is listed separately when the browser exposes it. Read both legs before deciding a hit arrived: the first leg can succeed while the onward request fails.

Choose how long to listen

Each page is watched for 10 seconds by default. That covers page load and most on-load events. Lengthen it for pages with timers, delayed tags or scroll-triggered events that you trigger some other way. Free inspects one page per run; Premium can inspect several pages at once (three open at a time by default) and export the results.

Keep going

• Next: read delivery verdicts
• Find tags blocked by CSP
• Read form test results