Network Inspector monitors your tracking at the network level. Where DataLayer Guard checks the page (the DOM and any frontend JSON objects), Network Inspector checks the HTTP, XHR, and Fetch requests and WebSockets your website sends, including custom headers and endpoints. It verifies that data actually reached the server, not just that a button was clicked.
Like DataLayer Guard, Network Inspector uses scenarios to simulate full user journeys on the web, such as logging in, accepting cookies, or clicking through a form, using a WebKit-based browser engine. Scenarios for native apps are not supported in the same way.
- Why network-level monitoring?
- DataLayer Guard vs. Network Inspector
- What Network Inspector checks
- How it works
- Use cases
- Learn more
Why network-level monitoring?
In modern web architectures, the dataLayer doesn't always tell the whole story. Data can be corrupted in transit, blocked by browsers, or sent by legacy systems that bypass the DOM entirely. Network Inspector captures the "handshake" between the user's browser and your servers, so you see the interactions that standard analytics miss.
It's especially useful for high-stakes user journeys, such as car, furniture, or bathroom configurators and personalized product flows, which often break quietly in the data funnel.
DataLayer Guard vs. Network Inspector
Both tools validate your analytics, but they capture data at different points in the browser.
DataLayer Guard | Network Inspector | |
Data source | The page: the DOM and frontend JSON objects such as the dataLayer | The network: HTTP, XHR, and Fetch requests and WebSockets |
What it checks | Whether specific keys and values are present in the objects pushed to the dataLayer, e.g. event: "page_view" | The health of the communication: status codes, headers, and the payload sent to the server |
Best for | Validating your dataLayer and frontend tracking | Confirming data reaches its destination, server-side tracking, third-party pixels, and setups without a dataLayer |
What Network Inspector checks
Check | What it does |
Status codes | Confirms each request returns 200 OK or another expected status, and flags responses such as 404, 403, or 500 that front-end trackers never see |
Headers and metadata | Confirms that required HTTP headers, such as content-type, cache-control, or custom auth tokens, are present and correct |
Payload | Checks the data sent directly to the analytics endpoint, such as GA4 or Adobe, before the server processes it |
How it works
- Intercept: when a network request is triggered (via Fetch or XHR), Network Inspector clones it
- Check: it runs tests against the request URL, headers, and body
- Validate: it waits for the server's response code to confirm the request succeeded
- Report: if a request fails or a header is missing, the failure is logged in your dashboard right away
Use cases
- Server-side tracking: check that server-side requests fire with the correct authentication headers
- Third-party pixels: make sure pixels such as Meta, TikTok, or Bing don't just load on the page, but actually deliver data to their servers
- Legacy setups: capture hard-coded tracking calls directly from the network on sites without a central dataLayer
Learn more
DataLayer Guard
Monitoring via Page Scenarios: how to build scenarios- Network Inspector on code-cube.io
Questions about Network Inspector? Email support@code-cube.io.