Understanding request types and statuses in your logs

Every row in your request logs is one HTTP request that reached your tagging server. Left unlabeled, that would just be a wall of URLs and status codes. Measurebase classifies each request by what it actually is, so a real conversion, a piece of GTM plumbing and a scanner probing for an .env file don't all look the same in the table.

The request types

Every request falls into exactly one of these categories:

• Enhanced tracking script — a request for the Enhanced loader file itself
• Ad-block protected request — traffic relayed through Enhanced Ad Blocker Protection's masking
• Google Ads (ad-block protected) — the same masking, specifically for requests destined for Google's ad-serving domains
• GTM tracking script — a request for your GTM container's own script
• Google tag — a gtag.js-style hit sent directly to your server container
• GA4 — a Google Analytics 4 measurement request
• GTM preview mode — traffic generated while you're debugging in GTM's own Preview mode, not real visitor activity
• Service worker — a request originating from a browser service worker rather than a page load
• Other — everything that doesn't fire a real tag or collect real data: scanner and bot noise, crawler files like robots.txt and favicon.ico, vulnerability probes against paths like .env, and similar background traffic. Requests in this category are never billed and never counted as a real traffic source.

Status badges — and when a 400 isn't an error

Every request also gets a status badge based on its HTTP response code:

• Active (green) — any response under 300, a normal successful request
• Pending (amber) — a 429 (rate-limited), or a 400 Measurebase has confirmed is benign (see below)
• Error (red) — everything else

A non-2xx status doesn't always mean something went wrong. Measurebase recognizes several patterns where the request itself is fine and no real data was lost:

• GA4/gtag retries — a 400 immediately followed by a successful request for the same measurement ID is the browser retrying with a corrected payload, not a real failure. Measurebase correlates the two and marks the original 400 benign. If the same measurement ID is running at a healthy success rate overall, older unmatched 400s for it get cleared too, even outside the short correlation window.
• Google Ads relay redirects — a 3xx from the Ads conversion relay is the redirect completing as designed.
• The Enhanced Conversions service worker — a 304 is just the browser's own cache confirming nothing changed.
• Known bot/scanner probes — paths like /favicon.ico, .env, or wp-login.php are automated background noise, whatever status they return.
• GTM Preview traffic — never a real visitor's measurement, so no status code on it represents lost data.

Each of these gets flagged with a "NO DATA LOST" tag next to the badge, so it's clearly distinguished from a request that actually failed — no need to dig into a tooltip to find out.

Filtering by status

The status filter on your request logs gives you five views: All statuses, 2xx success, 3xx redirect, 4xx client error, and 5xx server error. If you're triaging real problems, start with 5xx — anything there is a genuine server-side failure, never a benign retry.